VMware & Virtual Machine Data Recovery
Recovery across the storage layers under a VMware environment — physical media, RAID, the VMFS datastore, and the VMDK virtual disks and guest file systems inside them.
A VMware failure can originate at more than one layer: the physical drives, the RAID array underneath the host, the VMFS datastore itself, an individual VMDK virtual disk, or the guest operating system's own file system inside that virtual disk. DiskAnalyst identifies which layer has actually failed before attempting recovery, since a datastore-level fault and a guest-level fault call for different work.
Common Causes of Failure
Physical / RAID Layer Failure
The underlying drives or RAID array fails, taking the datastore built on top of it down with it.
VMFS Datastore Corruption
Metadata or partition-level corruption on the VMFS volume itself, independent of whether the drives underneath are healthy.
Deleted or Accidentally Removed VM
A virtual machine deleted or removed from inventory, where the underlying VMDK files have not yet been overwritten.
VMDK Corruption
An individual virtual disk file is damaged or inaccessible while the datastore around it is otherwise intact.
Guest File System Failure
The file system inside the VMDK itself (NTFS, EXT4 and similar) is corrupted, independent of the storage layers below it.
What We Handle
- ESXi hosts and VMFS datastores
- Deleted or accidentally removed virtual machines
- Failed or corrupted datastores
- RAID failure underneath a VMware host
- VMDK virtual disk corruption or inaccessible virtual disks
- Guest operating system file recovery from a recovered VMDK
Common Signs & Failure Scenarios
Our Recovery Approach
-
1
Identify the Failed Layer
We determine whether the fault sits at the physical/RAID, VMFS, VMDK or guest file-system layer before doing anything else.
-
2
Preserve the Underlying Media
If the physical layer is unstable, it is imaged first, exactly as with any other failing drive or array.
-
3
Reconstruct RAID Where Relevant
Where a RAID array sits underneath the datastore, it is reconstructed before the VMFS layer is addressed.
-
4
Recover the Datastore and VMDKs
VMFS structures are recovered and the individual VMDK virtual disk files are located and extracted.
-
5
Recover Guest Files
Files are recovered from the guest file system inside the recovered VMDK, whether or not the full VM can be restored to a bootable state.
Important: What Not To Do
- Do not attempt to rebuild, resignature or reformat a datastore before it has been assessed.
- Do not delete or resize existing VMDKs or snapshots while troubleshooting.
- Do not repeatedly power the host off and on if the underlying RAID array is degraded.
- Recovery cannot guarantee a bootable VM in every case — file-level recovery from the guest file system is often possible even when full VM restoration is not.
Devices & Configurations We Cover
Frequently Asked Questions
Often, yes, if the underlying VMDK files have not been overwritten since deletion — the sooner the datastore stops being written to, the better the chances.
We work with VMFS datastores and VMDK virtual disks across commonly encountered VMware environments. Bring the case in for assessment and we will confirm what your specific version and configuration involves.
No — we cannot guarantee a bootable VM in every case. What we can often do is recover files from the guest file system inside the virtual disk even when the VM itself cannot be fully restored.
That is treated as a server/RAID recovery first — see our Server Data Recovery page — with the VMFS datastore and VMDK layers recovered once the underlying array has been reconstructed.
No — recovery from a failed datastore or virtual disk is a diagnostic and extraction process, not an instant restore. Turnaround depends on the layer(s) affected and the extent of the damage.
Ready to Start Your Recovery Case?
Tell us what happened to your device and we'll advise on the right next step.
Submit a Case →