More virtual machine losses trace back to snapshots than to any hardware fault. A running VM is the sum of a chain, not a single file — so one damaged link stops a machine whose base disk is perfectly intact. Here is how that happens, and how it is put back.
$ mdr diagnose /dev/vmfs → Host: VMware ESXi · VMFS · VMDK → Status: VM DELETED — removed from inventory → Client: confidential · Manchester M2 $ mdr engineer-working → Datastore: scanned · blocks intact → VMDK: rebuilt from datastore → Guest: NTFS mounted · files back $ mdr verify → ✓ virtual machine — 1.4 TB → ✓ SQL databases — restored → ✓ VM recovered — data back
Consolidation rewrites disk chains, and on a damaged datastore it can destroy the very chain a recovery would reassemble. If a VM will not start and the storage is suspect, leave the snapshots exactly as they are.
More virtual machine losses trace back to snapshots than to any hardware fault, and they are worth understanding before you need to.
A snapshot does not copy the machine. It freezes the base disk and starts writing every subsequent change to a delta file, then another delta on top of that, and so on. The running VM is the sum of the chain, not any single file — so a chain with one link missing or damaged is a machine that will not start, even though the base disk is perfectly intact.
Two things go wrong. Snapshots left running for months grow until the datastore fills, at which point everything on it stops. And consolidation — merging the deltas back down — is a heavy write operation that can fail partway, leaving a chain that is neither merged nor coherent. Doing that on a datastore already reporting errors is how a recoverable VM becomes a difficult one.
You cannot address the second until the first is readable, which is why these jobs run in that order.
Including environments nobody documented before the person who built them left.
VMware ESXi and vSphere — VMFS datastores, VMDK flat and delta files, snapshot chains and thin-provisioned disks, including datastores presented from a SAN that must be reconstructed first. Microsoft Hyper-V — VHD and VHDX, differencing disks, checkpoints and Cluster Shared Volumes.
Proxmox, XenServer and KVM — QCOW2 and raw images, LVM-backed guests and ZFS datasets. Recovered machines come back either as bootable disk images you can attach directly, or as extracted files where you would rather rebuild the VM cleanly — we will ask which suits before finishing.
Priced above array work because the recovery continues past the datastore.
Virtual machine recovery starts from £800 +VAT, confirmed after a free 48-hour diagnostic. Where the underlying array or SAN must be reconstructed first, that is quoted alongside — RAID and server from £500 +VAT, enterprise SAN from £1,250 +VAT. A 50% deposit applies where physical drive-level work is needed.
Tell us the hypervisor and version, how many machines are affected, whether snapshots were in use, and what has already been attempted — particularly any consolidation. NDAs are standard and invoicing is available.
Get the virtual disk files to us, and tell us the hypervisor, format and what happened. The diagnostic that follows costs nothing, and one figure goes in writing before any work begins.
Nothing starts until the virtual disk files — or the failed storage holding them — to us is on the bench. Pack it properly and put your contact details in with it. Tell us the hypervisor and disk format. The diagnostic that follows costs nothing, and one figure goes in writing before any work begins.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Not sure it is worth sending? Tell us about the hypervisor, disk format and fault, plus anything already attempted — an engineer reads every one of these and comes back with an honest view of the odds and a price band, before you post anything.
We’ll be in touch shortly. If it’s urgent, call 0161 871 0788.
The questions we’re asked most about recovering virtual machines.
Frequently, provided nothing further has been written. Delta files orphaned from their parents can be reassembled in the correct order. What makes it unrecoverable is running a consolidation on a datastore that is already faulty.
Because a snapshot writes every change to a growing delta file rather than the base disk. Left for months they expand until the datastore fills, and when it fills every machine on it stops at once.
Usually. Where the underlying array has failed it is imaged and reconstructed first, then the VMFS datastore rebuilt on the assembled volume so the virtual disks become visible again. Every VM on that datastore is recovered together.
Yes. Once the virtual disk is readable the guest file system is treated like any other — deleted files, damaged file systems and corrupt databases inside the VM are all recoverable in the usual way.
Either as bootable disk images you can attach directly, or as extracted files where you would rather rebuild the machine cleanly. We ask which suits before the work completes.
From £800 plus VAT after a free 48-hour diagnostic. Where the underlying array or SAN must be rebuilt first, that is quoted alongside — from £500 plus VAT for RAID and servers, from £1,250 for enterprise SAN.
A virtual disk that copies cleanly can still refuse to boot, so these are checked as guests rather than as files. Tell us the hypervisor, the version, and above all whether a snapshot consolidation has already been attempted.
From £500 +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.