VMware VMDK Won't Mount or VMFS Datastore Offline? We Recover It.
UK virtualisation data recovery specialists since 2002. VMDK file recovery, VMFS datastore repair, vSAN object reconstruction, ESXi snapshot consolidation failures. Emergency business turnaround. No-fix-no-fee.
What this means and what to do next
VMware virtual machine recovery is a different discipline from physical disk recovery. The underlying storage may be perfectly healthy — a working SAN, a working vSAN, a working local RAID — but a single VMDK file has become corrupt, or the VMFS datastore presents but its files do not mount, or a snapshot chain has broken during consolidation and now the descriptor file points to a snapshot that no longer exists. The data is still there. The challenge is reaching it without VMware's own tools rewriting the descriptor metadata that points to it.
Data Clinic recovers VMware virtual disks across all common scenarios: corrupt VMDK descriptor files, missing flat or sparse files, broken snapshot chains, VMFS datastores that present empty after a power event, vSAN objects that fail to reassemble after host loss, and accidentally deleted VMs where the datastore still holds the original VMDK extents. We work at the VMFS metadata level and at the underlying NTFS, ext4 or XFS guest filesystem level — recovery typically delivers individual files inside the VM rather than just the VMDK as a blob.
The single most important fact about VMware recovery is that the natural diagnostic actions in vCenter — running storage views, attempting to consolidate snapshots, browsing the datastore, attempting to register a missing VM — can each modify the on-disk state in ways that reduce what is recoverable. If a VM has stopped working and you do not know exactly why, the safest action is to take the host out of the cluster, snapshot the SAN LUN at the array level, and ship us the snapshot or the disks rather than continue diagnostics in vCenter.
The common VMware data loss scenarios — and what they mean for recovery
1. Snapshot consolidation failed and the VM won't start. Symptom: VM disk descriptor points to a .vmdk that no longer exists, or to a snapshot extent that consolidation has half-deleted. The flat VMDK is still on the datastore but is missing the delta chain. Recovery: we reconstruct the snapshot chain from the surviving deltas and the base disk, then merge them in the correct order — VMware's own consolidate operation cannot do this once it has failed midway. The recovered VMDK opens cleanly on any ESXi host.
2. VMFS datastore disappeared or shows empty after a power event. Symptom: the LUN presents to ESXi, but the datastore is unmounted or shows no files. This usually indicates VMFS metadata corruption — the volume header is intact but the directory structures are damaged. Recovery: we image the LUN, parse VMFS at the binary level (we have parsers for VMFS3, VMFS5, VMFS6), and extract every VMDK regardless of whether the directory entries are still valid. We deliver the VMDKs back as files, ready to be registered on a working ESXi host.
3. VMDK descriptor file is corrupt or missing but the flat file is intact. Symptom: the .vmdk descriptor (small text file) is zero bytes or missing, but the -flat.vmdk (the actual data) is on the datastore at the expected size. Recovery: we rebuild the descriptor from the flat file's size and geometry, validate it against the guest filesystem inside, and deliver the VM ready to register. This is the most common quick-win VMware case and one we handle almost daily.
4. Accidentally deleted VM or formatted datastore. Symptom: someone removed a VM from inventory with 'Delete from Disk', or ran a quick-format on the datastore from a Windows host. The VMDKs are gone from the directory listing. Recovery: VMFS marks the blocks as free but does not zero them, so the VMDK extents are still on the LUN. We image the LUN and carve the VMDK extents based on the VMFS block size and the guest filesystem signatures. Recovery success depends on how much new data has been written since the deletion — call before using the datastore further.
5. vSAN object loss after multiple host or disk-group failure. Symptom: vSAN object becomes unhealthy or unrecoverable after a maintenance window or hardware failure that exceeded the cluster's fault tolerance. Recovery: vSAN distributes VMDK components across hosts; we image every cache and capacity disk in every host, reassemble the object layout from the vSAN metadata, and extract the VMDK. vSAN recovery is significantly more complex than single-host VMFS recovery — engage us early and avoid resyncing the cluster.
How Data Clinic recovers data from a failed VMware environment
Most VMware recoveries do not require us to take physical possession of the storage hardware. The fastest first step is usually a SAN-level snapshot of the affected LUN — we provide an FTP or SFTP target and you upload the snapshot to us. We then mount the snapshot as a read-only volume, perform the VMFS analysis and VMDK extraction, and deliver the recovered VMs back to you the same way. For vSAN failures, or where the storage is local SAS/SATA on the ESXi host, we ship the disks back the same day they arrive at our Bury lab and image them on PC-3000.
Recovery work happens at the VMFS layer (using our own parsers — not vmkfstools, which writes), then at the guest filesystem layer (NTFS for Windows VMs, ext4/XFS for Linux VMs). For each VM we report on the integrity of the guest OS, the application data within it (SQL Server databases, Exchange stores, NoSQL data files), and the boot configuration. The output is a set of VMDK files that register cleanly on a working ESXi host, plus a structured report on what was recovered and any limitations.
For business-critical recoveries we offer a phased delivery: we identify the highest-priority VMs in the first hours of work and deliver those first so production can resume, then continue with the remaining VMs in parallel. More about our RAID and virtualisation recovery service →.
Get a free initial diagnosis in 60 seconds
Use the diagnostic tool below to record the VMware error messages, the VMDK type (thick/thin/EZT), and the underlying storage layout (single host, vSAN, or external array). The more detail you give, the faster we can quote.
What our customers say
"Three years of family photos on a drive that suddenly failed. Data Clinic collected next day, kept me updated through the cleanroom work, and got everything back. Worth every penny."
"Honest, fixed-price, no-fix-no-fee. Quoted by another lab at three times the price. Recovered 100% of my files."
"Reasonable cost, clear communication, and they were straight with me about what was recoverable and what wasn't. Recommended."
Frequently asked questions
Can you recover a VMDK after we ran 'Consolidate' and it failed?
In most cases yes. A failed consolidation leaves the snapshot chain in an inconsistent state — usually the base disk is intact and one or more delta files are partially merged. We reconstruct the correct chain order, validate each delta against the base, and produce a clean VMDK that opens on a working ESXi host. Critical: do not try Consolidate a second time or delete any of the delta files until we have analysed the state.
Our VMFS datastore shows 0 bytes used but the VMs were definitely there yesterday. Recoverable?
Very likely yes, provided you have not written anything to the datastore since. VMFS metadata corruption that hides the directory tree does not erase the underlying VMDK extents. We image the LUN, parse the VMFS at the binary level, and carve out the VMDKs by their guest filesystem signatures. Stop using the datastore immediately.
We have vSphere replication / vSAN / Veeam backups. Should we restore from those or recover the originals?
Restore from backup first to get the business operational. Send us the originals in parallel — recovered originals can fill the gap between the last successful backup and the failure, which is often where the most important changes live. We commonly deliver 'forward-deltas' that customers replay onto their restored systems.
How long does VMware recovery take?
Typical case: 3–5 working days from receipt of the storage or SAN snapshot to delivery of the recovered VMDKs. Simple descriptor reconstruction can be next-day. vSAN recoveries with multiple host failures are usually 5–10 days because of the number of disks to image. Emergency service is available at a premium for production outages.
Can you do this work without sending hardware off-site?
For VMFS / VMDK cases on a SAN: yes, via SAN-level LUN snapshot uploaded to us over SFTP. For vSAN or local-storage cases: no, we need the physical disks. We can dispatch an engineer to site to image on the customer's premises if removal from a data centre is not permitted, but the lab work is faster and cheaper.
Will you give us a report we can submit to insurance or audit?
Yes. We provide a written technical report detailing the storage hardware, the failure mode, the recovery actions taken, the integrity of the recovered data, and any data that could not be recovered. The report is suitable for insurance claims, supplier disputes, ICO incident records, and internal post-mortems.