Specialist · VMware & virtual machines
When a VM dies, the fault could live in any of four layers: the RAID beneath, the VMFS datastore, the VMDK files, or the guest's own file system. Recovery only works bottom-up — rebuild each layer on images before touching the next — and no, you don't need the ESXi host, the vCenter, or a matching anything.
Talk it through with an engineer
01273 964902
| The situation | What it means | First move |
|---|---|---|
| VM deleted from the datastore | The VMDK's blocks persist on the VMFS volume until reallocated | Stop provisioning immediately |
| Cannot open the disk — parent has been modified | A snapshot-chain CID mismatch: child and base no longer agree | Don't force it — chains break |
| Datastore inaccessible after a RAID event | The storage layer failed; the VMFS on top is usually repairable | Bottom layer first |
| A backup job left a phantom locked snapshot | Delta files orphaned mid-consolidation | Common, and recoverable |
| Hyper-V VM dead after a checkpoint merge | A broken AVHDX chain — binary structures, not text | Verify parents before merging |
| The VMDK is back but Windows inside won't boot | Layer four: the guest file system needs its own repair | Half-done isn't done |
Your device is logged with its own case reference the moment it arrives. An engineer assesses the fault, confirms what's actually recoverable, and you get a fixed price in writing — no diagnosis fee, no obligation, and no paid work until you say go.
The physical storage is imaged and, where needed, the array reconstructed exactly as our server pages describe — every higher layer works from these read-only images.
The VMFS or NTFS datastore is parsed from the image, deleted and live VMDKs located, snapshot chains mapped — CIDs and parent links verified before anything is stitched.
Descriptors repaired, chains consolidated correctly, and the guest file system inside repaired last — the job signs off when the VM's data mounts, not when files merely exist.
Before you pay the recovery fee you approve a full listing of what came back. Your data returns on new media with free return postage, and the case only closes once you've confirmed everything opens on your side.
Why bottom-up isn't pedantry: a virtual machine's data crosses four ownership layers — physical blocks, VMFS, VMDK, guest file system — and a repair attempted at the wrong layer writes fiction into every layer above it. The professional sequence is boring and absolute: image, rebuild, parse, extract, repair, mount. In that order, every time, because it's the only order that can't destroy anything.
An admin's cleanup script took the wrong folder. Because the datastore was quiet all weekend, both VMDKs sat unlinked and whole; parsed out of the VMFS image on Monday, descriptors rebuilt, and both machines booted in a sandbox by Tuesday evening — payroll among them.
Frequently, yes — deleting a VM unlinks its files from the datastore's index while the blocks persist until new provisioning claims them. Freeze the datastore, image the storage, and the VMDKs are usually parseable out whole. Speed of freezing is the whole game.
It's VMware's snapshot chain failing a paternity test: the child delta's recorded parent ID no longer matches the base disk, usually after a partial consolidation or restore. The chain is repairable at descriptor level — forcing the IDs to match without understanding why is how intact chains become lost data.
No. Everything happens from images of the underlying storage on our bench — VMFS parsed, VMDKs extracted, guests repaired — with nothing booted on your infrastructure until you choose to. A dead host changes nothing about recoverability.
Same philosophy, different grammar: VHDX files with binary internal logs and AVHDX checkpoint chains whose parent links must be verified — with PowerShell, not a text editor — before any merge. The layers-first, images-only discipline is identical.
Every restart of a damaged device costs data. Open a case first — the diagnosis is free either way.