DTI Data Recovery receives several requests for data recovery quotes each and every day. Many times the quotes are self-explanatory and we can offer an accurate solution as well as an upfront price for almost any recovery. With that being said, there are times when a more complex solution is necessary and some additional information is needed in order to offer an accurate quote and estimate the possibility of recovery. One of these instances is the deletion of data, any data. The possibility of recovery hinges on so many factors that a phone conversation is normally necessary in order to gather more information and make sure that the Deleted VMWare VMDK can be recovered.
Some of the most complex situations when dealing with deleted data involves virtual technology. Although this technology has been a real life safer when it comes to optimizing hardware resources it is a real nightmare when it comes to unraveling the mystery that involves a deleted VMWare VMDK. That being said, I received a request for a deleted VMWare VMDK recovery quote recently. The person inquiring could not be contacted by phone so I could not speak to them. The description of the problem was so vague that I decided to send a list of questions that would enable me to make an educated and informed assessment of the recovery as well as the pricing for that recovery. The following are those questions and the reasons why they were asked. The questions were designed for a VMWare server.
1. What version of ESXi are you running on the server?
This is important in as much as some of the older versions of ESXi had file size limitations. In addition there are some utility functions for more recent versions that do not exist on the older versions of the operating system. These types of version discrepancies can and do affect the possibility of recovery.
2. Was the VM set up as thick or thin provision?
When a VKDK file is deleted then the storage map for that particular file is destroyed. There are times when a low level forensic scan is necessary to try and piece together the file. If the original VMDK is ‘thin’ provision then that means the file is compressed and allocated on an as needed basis. Thin provision can be difficult to recover if the actual block map for the file has been destroyed due to a deletion. Whereas ‘thick’ provision allocates the full size of the VMDL and can be treated like any other operating system partition.
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.