It is never a question of if, but when, something on a computer system fails. Either from poor programming, faulty hardware, or an outside occurrence such as a power loss, there is always the lingering possibility that data is going to be lost. This outlook, philosophy if you will, is the mantra of those who chant ‘backup’, or ‘cloud’ and remains even more so today the safest and most reliable method for ensuring an intact data architecture.
With that being said it is also true that the virtual machine (VM) environment, although much more reliable than before, still offers a higher degree of failure since not only is your data affected by the mechanics of the virtual machine interface, but the host system brings its own set of hurdles that must be overcome on a day in and day out basis. When either of these systems fails, it is usually during a time when the most valuable of data is being accessed. This is not coincidence but in a leaving and breathing data center the most critical data is always the most recent. These failures normally occur during a write operation and will either forgo the write altogether or, even more devastating, write data that is corrupted. Many modern VM handlers are well aware of the no write type of scenario and are prepared for a data rollback in order to stabilize the work environment. However, it is the bad write that causes the VM problems and in the worst scenario will corrupt not only the offending write, but other data on the VM. Signs of this would be an unmountable VM, or a slow and steady loss of data within the working VM. In either case, the following steps should be taken in order to minimize the damage.
Isolate the VHD:
There is an old saying that a doctor makes a poor patient, in this case using the standard VM repair tools in order to recover a sick VM can sometimes make matters worse. Always shutdown the VM if you can, and copy the file, as well as any support files into another folder. Never, ever work on live data, always work on a copy.
Deleted VHD:
If the VM has been deleted then download VHD Finder and scan the host drive. If the header information for the drive is intact then the software will find it. Mark the sector offset and then recreate the VHD using a third part imager.
Fixed VHD:
If the format of the VM is fixed then after using VHD Finder and locating the VM offset, use a piece of commercial grade data recovery software to mount the VHD and then recover the files that have been corrupted, and or lost. Our own Recover It All Now, can be used to scan the drive and mount a deleted fixed size VM.
Dynamic VHD:
This is a file that for all practical purposes is compressed. Microsoft uses their own VHD API to address this type of file and that can only be done after the file is mounted. There are data recovery tools that will mount a dynamic VHD but that is beyond the scope of this article.
These are just a few methods for aiding the panicked administrator in recovering a corrupt VHD, or a corrupt file within a lost VHD.
The key to a safe recovery is to always work on a backup of the VHD, never live data. If you have any questions please feel free to leave them in the blog and I will try my best to answer them.
