3. What operating system was the VM hosting?
This is critical in as much as during a scan for the VMDK markers are necessary in order to find a particular VMDK. The scan can be tuned to a particular operating system and will help optimize the possibility of recovery when the technician is aware of what file system is being housed on the VMDK
4. How long ago was the VM deleted?
This is extremely important as I have received many quote requests as well as calls for the recovery of deleted data only to find out that the data was deleted over six months ago. On a busy server, even on a home personal computer the longer the time between deletion and recovery the more remote the chances of recovery. When a file is deleted the area of the storage device that the file occupied is now available for new files and therefore the overwriting of the original data.
5. Did you try and recreate the VM?
This does not happen too often as the technicians usually know that doing so will not only overwrite the original file, but can also destroy any supporting files that may be part of the VM.
6. Has the server that the VM was stored on been used?
I have worked with some very smart technicians that once they realized the VM had been deleted they will immediately shutdown the server and allow no access to it. This practice minimizes the possibility of overwriting the original VMDK and therefore corrupting the file.
7. How busy is the server the VM is stored on? (User, traffic, VMs)?
Once again, on a very busy server that has been left up and running the possibility of VMDK overwrite and corruption increase exponentially. The more traffic, the more use, the higher probability that the VMDK will be rendered either unrecoverable of so corrupt the data useless.
8. Is the VM stored on a RAIDed server?
Although this particular set of knowledge does not directly affect a deleted VM, it is pertinent when making an evaluation of the recovery. There are times when a RAID 5 will bring a stale drive back online and corrupt the file system. This can look like files have been deleted if the corruption is extensive. When I hear RAID then I start asking questions about the health of the RAID and if they have had any recent updates, rebuilds, maintenance on the array.
9. How large is the VM?
VMFS is a file system that is what is referred to as ‘segmented’. The storage area is broken down into segment’s each with its set of meta data that allows for locale type block management. What this basically means is that if a segment is only 200 gigabytes is size and the VM is 500 GB and stored as thick provision then the data will span at least three storage segments. Normal forensic methods cannot be used when trying to piece together a segmented VM and an intimate knowledge of VMFS is necessary in order to build a usable VM.
10. How much total storage is the VM residing on?
In other words, is this a 10 terabyte RAID 5 with a deleted 200 GB VM? A forensic scan, even across fiber hardware, will take a very long time when the scan must look at 10 terabytes worth of storage. The rule is the smaller the total storage in comparison to the VM offers a better chance of recovery.
11. In the even the VM cannot be forensically restored, what are the file types that are in the VM, and what is their approximate sizes?
This is the last ditch effort question. When there are no markers that indicate the smallest hint of a VM then the next step is to go after the files stored within the VM. As an example, if this particular VM housed and Exchange server then we would be looking for ‘edb’ file type markers. If this were a database application using SQL Server then we would scan for ‘mdf’, ‘ndf’, and ‘ldf’ file types. This methodology has on more than one occasion saved a client’s data, especially when the VM is ‘thick’ provision.
12. Is the server still online and in use where the VM is stored?
This is actually a loaded question. I have had VMs stored on a server that had multiple stores with the VM and auxiliary storage spread across each store. I have had VMS where the file system VM was stored on one store, but all of the data was stored on another store. This particular scenario has cost a client their data as they were adamant that the data was on the store where the VM was and not on another store. It wasn’t, but the client is always right. This question gives you knowledge as to how the technician thinks, the possibility of recovery, where to look for a forensic scan etc. etc. ad nauseam. Part of a recovery is evaluating your client and how much you can and cannot trust what they tell you.
I guess this about covers it. There are other questions that can be asked but these twelve have been my staple for many years. They give you a good foundation on how to recover the data as well as the direction to follow in your data recovery efforts.
For those technicians who tackle a deleted VMWare VMDK recovery in any form I take my hat off to you.
I have been down the road enough to know that it is a precarious and windy avenue we tread when trying to piece together a deleted VM.