A virtual machine can vanish in a way a physical one never could — a datastore that won’t mount, a VMDK that won’t open, a snapshot chain that broke, a VM deleted with one wrong click. But because a VM is really just a set of large files on storage, the data is usually still there, waiting to be extracted and repaired. We recover VMware, Hyper-V and other virtual machines for businesses across the UK, with priority handling and NDAs as standard. Disks or images by courier.
Which is why a ‘lost’ VM is usually recoverable — the container is intact underneath, even when the hypervisor can’t open it.
It’s the key to why VM recovery so often succeeds. A virtual machine isn’t a mysterious object — it’s a set of large files sitting on storage: a virtual disk (a VMDK on VMware, a VHDX on Hyper-V) that contains a complete file system, plus configuration and any snapshot files. When a VM ‘disappears’, those files are usually still on the datastore; it’s the hypervisor’s ability to read or assemble them that has broken, not the data itself.
So recovery works from the storage up: reconstruct the datastore if it’s damaged, locate the virtual disk files, repair the container and stitch any broken snapshot chain back together, then open the file system inside the VM and recover its contents — right down to the databases it was running. It’s layered work, but the layers are well understood, and the data is usually recoverable even when the VM won’t boot.
The datastore won’t mount. A corrupt VMFS datastore, or one showing as unmounted or needing a resignature, hides every VM on it — even though the VMDKs are intact underneath. This is one of the most common, and most recoverable, situations.
A corrupt virtual disk. A VMDK or VHDX that won’t open after a storage failure, a crash or a dirty shutdown — the container header or descriptor is damaged but the data inside is largely intact.
A broken snapshot chain. Snapshots that grew out of control and filled the datastore, a failed consolidation, or a missing delta file — leaving the VM unable to assemble its current state from the chain.
A deleted VM. A virtual machine removed from disk, or a VMDK deleted by mistake — usually recoverable if the datastore hasn’t been overwritten since.
The underlying storage failed. A failed RAID array, server or SAN beneath the datastore — recovered by reconstructing the storage first, then the VMs on it.
Guest corruption. The VM boots but its own file system or applications are corrupt — a recovery inside the guest, just as on a physical machine.
Don’t resignature or force-mount a VMFS datastore repeatedly, or run datastore ‘repair’, before it’s been imaged — you can overwrite the structures needed to recover the VMs. Don’t consolidate or delete snapshots when the chain is already broken; a failed consolidation can lose the current state entirely. Don’t delete files you think are ‘orphaned’ from a datastore — a stray delta or descriptor may be exactly what’s needed. Don’t let the underlying RAID rebuild if the storage failed. And don’t keep powering a VM on and off in the hope it recovers — if the guest is writing on each boot, it can overwrite recoverable data. Capture the environment, stop, and have the storage imaged first.
Where the underlying storage has failed, we reconstruct it first — imaging the disks and rebuilding the RAID and datastore offline, exactly as for any array. With the datastore readable, we locate and extract the virtual disk files, repair damaged VMDK or VHDX containers, and rebuild broken snapshot chains to reassemble the VM’s correct state. Then we open the file system inside the virtual disk and recover its data, repairing any databases or applications within as needed. Everything is done from images, never the live datastore, so each step — datastore, container, snapshots, guest — can be verified and reworked without risk to the originals.
We recover across the major virtualisation platforms — VMware ESXi and vSphere (VMFS datastores, VMDK disks), Microsoft Hyper-V (VHD and VHDX), Proxmox, Citrix / XenServer and Oracle VirtualBox — including thin- and thick-provisioned disks, snapshots and linked clones. And because VMs sit on top of physical storage, we recover the whole stack when needed: the RAID, the server or SAN beneath the datastore, and the databases inside each guest. Whatever level the failure is at, we can work back to your data.
It starts with a free assessment: we evaluate the datastore and virtual disks, establish what can be recovered and repaired, and give you a fixed written quote before any chargeable work. Because a lost VM often means a stopped service, a priority and emergency service is available, with NDAs and confidential handling as standard. Pricing is per case, reflecting the layers involved. We can work from the disks, from images you provide — for businesses right across the UK and Ireland.
Usually not. A VMFS datastore that won’t mount, or shows as needing a resignature, hides the VMs on it — but the VMDK files are almost always intact underneath. We image the storage, reconstruct the datastore offline, and extract the virtual machines. The important thing is not to force-mount, resignature or ‘repair’ the datastore repeatedly before it’s imaged, as that can overwrite what’s needed.
Usually, yes. A virtual disk that won’t open after a crash or storage failure typically has a damaged header, descriptor or snapshot link, while the data inside is largely intact. We repair the container and, where a snapshot chain is broken, rebuild it to reassemble the correct state — then recover the file system and data inside.
Often, yes. A failed consolidation or a broken snapshot chain leaves the VM unable to assemble its current state, but the delta and base files usually still hold the data. We stitch the chain back together from the available files and recover the VM. Don’t attempt further consolidations or delete any ‘orphaned’ snapshot files in the meantime, as those may be essential.
Usually, if you act quickly. A deleted VM or VMDK is generally recoverable as long as the datastore hasn’t been overwritten since — so stop creating or powering on VMs on that datastore, and get it imaged. The sooner it’s captured, the better the chance of a complete recovery.
Yes. Once the VM is recovered we open the file system inside it and recover its contents, including SQL, Exchange or other databases — repairing them to a consistent, mountable state where needed. We recover the whole thing, from the datastore down to the records inside the guest.
Yes. Our lab is in Belfast, but VM recovery is done by courier or from images you send us, so we work with businesses right across the UK and Ireland. Send the disks in by insured courier, or we can work from an image of the storage — with NDAs and priority handling as standard, wherever you are.
Capture the environment, stop, and get in touch. We’ll assess the datastore and virtual disks, work out what can be recovered, and give you an honest, fixed quote before any chargeable work — priority and emergency service available, NDA as standard.