More virtual machine losses trace back to snapshots than to any hardware fault. A running VM is the sum of a chain rather than a single file, so one damaged link stops a machine whose base disk is completely intact. The usual sequence is a snapshot taken before an upgrade, left in place for months, growing until the datastore fills and everything stops at once. Recoverable, almost always — but not by deleting anything first.
$ cdr diagnose /dev/vmfs → Host: VMware ESXi · VMFS · VMDK → Status: VM DELETED — removed from inventory → Client: confidential · Cambridge CB2 $ cdr engineer-working → Datastore: scanned · blocks intact → VMDK: rebuilt from datastore → Guest: NTFS mounted · files back $ cdr verify → ✓ virtual machine — 1.4 TB → ✓ SQL databases — restored → ✓ VM recovered — data back
The pattern is so consistent it is worth stating before anything else.
Somebody takes a snapshot before an upgrade, intending to remove it afterwards. The upgrade goes fine, the snapshot is forgotten, and every subsequent write goes to a delta file rather than the base disk. Months pass. The delta grows until the datastore fills, and at that moment every virtual machine on it stops at once.
The instinct at that point is to delete a snapshot to free space. That is the single most damaging action available, because consolidating or deleting a snapshot requires free space to complete — and there is none, which is why everything stopped. An interrupted consolidation leaves the chain inconsistent and the machine unbootable.
Almost all of this is recoverable. The base disk is usually intact and the delta chain can be reassembled. But not after somebody has deleted links out of it.
Do not delete snapshots to free space. If the datastore is full, add capacity or move a machine off it. Deleting a snapshot mid-chain on a full datastore is how a recoverable situation becomes a genuine loss.
The physical storage failed and the datastore went with it. This is array recovery first and virtual machine work second — the layers are reconstructed in order from the disks upward.
The array is fine and the datastore's own structures are damaged. The VMDK or VHDX files are physically present and the map describing where they sit has been lost.
Storage and file system both healthy, and the virtual machine will not start because its delta chain is broken. The most common of the three by a wide margin.
Small technology companies here consolidate hard. A single host runs the domain controller, the file server, the build environment, the test estate and the application server, because that was entirely sensible when the company was eight people. When the datastore underneath goes, six logical machines go with it, and there is no fallback because the fallback was also a guest on that host.
Recovery means extracting the VMDK or VHDX files from the underlying volume and repairing them as guests rather than as flat files. That distinction is the whole job: a repaired guest boots and runs, whereas an extracted file merely exists.
Virtual machine recovery starts at £800 +VAT. Where the datastore sits on a failed array, array reconstruction and guest repair are quoted together as one figure rather than billed as two jobs.
Recovered machines are test-booted here before return wherever the licensing allows it, so what comes back is a machine that starts rather than a folder of files that might.
The classic snapshot problem. A delta grew until there was no space left. Do not delete a snapshot to make room — consolidation needs free space to complete and interrupting it breaks the chain. Add capacity or call us first.
Recoverable in most cases. An interrupted merge leaves parent and child inconsistent, and the chain can usually be reassembled from the surviving files. Change nothing else in the folder.
Yes, and it is the common case. The array is reconstructed, the datastore file system rebuilt, then the guest disks extracted and repaired. Quoted as one job.
Often recoverable if nothing has been written to the datastore since. Power the host down or take the datastore out of service immediately — a running host will reuse those blocks quickly.
They boot. Guest disks are repaired as machines and test-started here where licensing permits, because a VMDK that exists but will not start is not a recovery.
Send every disk in the pool. ZFS will not import with a vdev member missing, and partial sets are the most common reason these jobs stall. Do not attempt a forced import first.
From £800 +VAT. Tell us the hypervisor and version, how many guests are affected and whether snapshots were in use — and above all whether a consolidation has already been attempted, because that changes what is left to work with.