Skip to main contentSkip to navigation
Rossmann Repair Group
Lab Operational Since: 17 Years, 10 Months, 11 DaysFacility Status: Fully Operational & Accepting New Cases

Virtual Machine Data Recovery

When the physical storage beneath your VMs fails, the hypervisor cannot help you. RAID controller failures, SAN LUN corruption, and drive mechanical failures take entire datastores offline. We image the failed drives, reconstruct the storage array, parse the host filesystem, and extract your virtual disk files with their guest data intact.

All work is performed in-house at our Austin, TX lab using PC-3000 and DeepSpar Disk Imager. No data recovered means no charge.

Get a Free EvaluationNo Data, No Fee Guarantee
Author01/14
Louis Rossmann
Written by
Louis Rossmann
Founder & Chief Technician
Updated August 28, 2026
Quick Answer

Virtual machine data recovery extracts VMDK, VHDX, and qcow2 files from failed storage beneath VMware ESXi, Microsoft Hyper-V, and Proxmox VE environments. Drives are imaged write-blocked through PC-3000, the RAID array or SAN LUN is reconstructed offline, the host filesystem is parsed, and virtual disks are extracted with their snapshot chains consolidated back to a consistent state.

Featured Snippet Target02/14

How Does Virtual Machine Data Recovery Work?

Virtual machine data recovery images the failed physical drives write-blocked, reconstructs the RAID array or SAN LUN offline, parses the host filesystem (VMFS, NTFS, or ZFS), and extracts virtual disk container files with snapshot chains consolidated. The process addresses two distinct layers: the physical storage beneath the hypervisor and the virtual disk containers on that filesystem.

Virtual machine recovery is a two-layer problem: the physical storage holding the datastore, and the virtual disk container files stored on that filesystem. A hardware failure at the physical layer makes both layers inaccessible, but virtual disk data is typically intact within the container files once the underlying storage is reconstructed.

The first layer is the physical storage: RAID arrays, SAN LUNs, or standalone drives that hold the datastore. The second layer is the virtual disk container: VMDK, VHDX, qcow2, or raw files stored on the host filesystem.

  1. Isolate and image the physical drives using PC-3000 with sector-by-sector cloning and custom read timeouts to prevent degraded heads from further damaging platters.
  2. Reconstruct the RAID array offline by parsing controller metadata (PERC, Smart Array, LSI, mdadm superblocks, ZFS labels) from drive images. Determine stripe size, parity rotation, and member ordering without touching original hardware.
  3. Parse the host filesystem (VMFS5/6, NTFS, ReFS, ext4, XFS, ZFS) from the reconstructed array to locate the virtual disk container files and their metadata.
  4. Extract the virtual disks and consolidate any snapshot deltas back into the base disk, producing a single flat image representing the VM's last consistent state.
  5. Verify guest filesystem integrity by mounting the recovered virtual disk read-only and confirming NTFS, ext4, or XFS structures are intact.
Hypervisor-Specific Child Pages03/14

Which Hypervisor Platforms Do You Support?

We recover virtual machines from VMware ESXi, Microsoft Hyper-V, and Proxmox VE. Each platform stores virtual disks in a distinct format on a distinct host filesystem; recovery procedures differ at every layer from physical imaging through guest extraction. Dedicated recovery pages cover platform-specific metadata structures and failure modes.

We recover virtual machines from VMware ESXi (VMFS datastores, VMDK containers, vSAN disk groups), Microsoft Hyper-V (VHDX files, checkpoint chains, Cluster Shared Volumes), and Proxmox VE (ZFS zvols, LVM-thin pools, Ceph RBD images). Each platform stores virtual disks in a distinct format on a distinct host filesystem; recovery procedures differ at every layer from physical imaging through guest extraction.

VMware ESXi Recovery

VMFS datastore recovery, VMDK extraction, snapshot chain repair, vSAN reconstruction

Learn more
Hyper-V Recovery

VHD/VHDX recovery, checkpoint chain consolidation, Cluster Shared Volume reconstruction

Learn more
Proxmox VE Recovery

ZFS pool reconstruction, Ceph OSD recovery, qcow2/raw extraction, LXC container restoration

Learn more
VM Disk Format Recovery

VMDK split extents, VHDX differencing disks, qcow2 backing chains, VDI containers

Learn more
Virtual Disk Format Technical Section04/14

What Virtual Disk Formats Do You Recover?

We recover VMDK (VMware ESXi and Workstation), VHDX (Microsoft Hyper-V), qcow2 (KVM, Proxmox VE, and OpenStack), VDI (VirtualBox), and raw disk images. Each format has a distinct on-disk structure that determines what metadata must survive or be reconstructed for recovery to succeed.

We recover VMDK (VMware ESXi and Workstation), VHDX (Microsoft Hyper-V), qcow2 (KVM, Proxmox VE, and OpenStack), VDI (VirtualBox), and raw disk images. Each format has a distinct on-disk structure; the format determines what metadata must survive or be reconstructed for recovery to succeed. The underlying physical recovery process is the same regardless of container format.

VMDK Extent and Descriptor Recovery

A VMDK consists of two files: a text-based descriptor file (.vmdk) containing geometry, adapter type, and extent references, and a flat data file (-flat.vmdk) containing the raw virtual disk contents. Monolithic flat VMDKs store everything in a single extent. Split VMDKs fragment the data into 2GB extent files (-s001.vmdk through -sNNN.vmdk).

Snapshot chains add delta disks (-delta.vmdk on VMFS5, -sesparse.vmdk on VMFS6). Each delta contains a grain directory and grain tables mapping changed blocks relative to the parent. The descriptor's CID field must match the parentCID of each child delta.

When an ESXi host crashes during a "Delete All Snapshots" operation, orphaned deltas disconnect from the .vmsd file and the CID chain breaks. We reconstruct the chain by reading grain tables, determining the actual write sequence, and recalculating CID/parentCID values.

If the descriptor file is destroyed entirely, the flat file becomes headless. We locate the flat extent boundaries on the VMFS volume, calculate geometry (cylinders, heads, sectors) from the file size, and rebuild the descriptor manually.

VHDX Dynamic and Fixed Disk Recovery

VHDX replaced the legacy VHD format in Windows Server 2012. It supports virtual disks up to 64 TB and uses a structured layout: a file type identifier, two redundant header copies (at 64 KB and 128 KB offsets), a region table pointing to the BAT (Block Allocation Table) and metadata regions, and a replay log for crash consistency.

Fixed VHDX files pre-allocate all blocks at creation. Dynamic VHDX files allocate blocks on demand as the guest writes data. Dynamic disks are vulnerable to BAT corruption if the underlying storage disconnects mid-write, because the BAT update and the payload block write are separate I/O operations.

If the BAT points to an uninitialized block offset, the guest filesystem reads garbage. Hyper-V checkpoints create AVHDX differencing disks with their own BAT mapping changed blocks relative to the parent. A failed checkpoint merge leaves orphaned AVHDX files that the VM configuration (VMCX) no longer tracks. We parse each differencing disk's BAT, determine the correct parent-child ordering by creation timestamp, and consolidate the writes into a single base VHDX.

qcow2 Metadata and Cluster Reconstruction

qcow2 (QEMU Copy-On-Write version 2) uses a two-level reference table system: L1 entries point to L2 tables, and L2 entries point to data clusters. This indirection allows sparse allocation, internal snapshots, and backing file chains. A separate reference count table tracks cluster usage for copy-on-write operations.

Proxmox VE environments using cache=none skip the host page cache, sending writes directly to the storage backend. If the storage loses power during a metadata commit, the L1/L2 tables and reference counts can become inconsistent. This is a torn write: the data cluster was written but the L2 entry still points to the old location (or to nothing). Recovery works from a write-blocked image of the storage and parses whatever L1, L2, and refcount structures survived on it.

Backing file chains (used for Proxmox linked clones) add another failure dimension. If the base image is on a different storage backend than the overlay, a failure on either backend breaks the chain. Both the base and overlay must be recovered and reconnected for a complete VM image.

How Does VMDK Provisioning Mode Affect Recovery?

Eagerzeroedthick VMDKs pre-allocate the full extent and zero every block at creation, so the flat file's size on the VMFS volume equals the provisioned virtual disk size. Lazyzeroedthick allocates space at creation but defers zeroing until first write, leaving uninitialized regions that read as garbage if recovered naively. Thin provisioned VMDKs only allocate VMFS blocks as the guest writes; the on-disk flat file is sparse, and recovery depends on intact VMFS allocation metadata.

VMware exposes three VMDK provisioning modes on VMFS datastores. Each interacts differently with the underlying storage and produces different recovery profiles when the datastore fails or the VMDK descriptor is lost.

Eagerzeroedthick
Allocates and zeros every VMFS block at creation. There is no sparse allocation map to reconstruct and the full virtual disk size is known up front. We walk the VMFS pointer metadata to reassemble the extent in order.
Lazyzeroedthick (default thick mode)
Reserves VMFS blocks at creation but only zeros them on first guest write. Uninitialized regions read as whatever previously occupied that VMFS block. After a host filesystem failure, naive imaging tools cannot tell the difference between guest-application-written data and stale residue from a deleted VMDK that previously occupied the same region. We mount the recovered guest filesystem read-only and verify file integrity before declaring blocks valid.
Thin provisioned
Allocates VMFS blocks only on first guest write. Reported size on the datastore can be far smaller than provisioned virtual disk size. A damaged VMFS allocation layer leaves a fragmented set of allocated regions whose virtual offsets must be reconstructed by parsing guest filesystem signatures. Over-allocated thin pools that exhaust the underlying datastore also produce write failures that the guest sees as silent corruption.

For RAID-backed datastores, the provisioning mode determines how aggressively we image: thick modes can be cloned with standard sequential imaging; thin modes require sparse-aware imaging that preserves the VMFS allocation map so the on-disk extent layout can be parsed offline.

Ransomware Encrypted Virtual Environments05/14

Can Ransomware-Encrypted Virtual Machines Be Recovered?

Sometimes. Encryption coverage varies by ransomware family and by how the operator configured it, so recoverability is decided per case. We image the datastore write-blocked, map the encrypted regions of each virtual disk file by hex analysis, and extract whatever payload survived, without running any decryptor against a live system.

Sometimes. How much of each VMDK or VHDX file is actually enciphered varies by family and by configuration, so the first job is measuring that on a write-blocked image rather than assuming it.

Running untested decryptors on a live system risks further corruption of the VMFS heartbeat region or the VHDX replay log.

During complex server recovery incidents involving ransomware, we image the entire array write-blocked through PC-3000. Using hex analysis, we identify the exact encryption boundaries within each virtual disk file. The surviving, unencrypted data payload blocks are extracted from the orphaned flat files & reassembled into mountable guest filesystem images.

For dedicated ransomware recovery resources including LockBit & Ryuk-specific procedures, see our ransomware recovery service pages.

SAN-Backed Datastore Failures06/14

How Do You Recover SAN-Backed Datastores?

SAN-backed datastore recovery does not require the SAN controller when the array writes its geometry to the member drives. Individual SAS or SATA drives are pulled from the shelf and imaged directly, the RAID topology is reconstructed offline from that on-disk metadata, and the VMFS or NTFS filesystem is parsed from the reconstructed LUN to extract virtual disk container files.

When a SAN controller fails or multiple drives in a shelf fail simultaneously, every VM on every datastore hosted by that LUN goes offline. Recovery avoids the failed controller entirely; the on-disk metadata is all we need.

  1. Image individual SAS/SATA drives from the SAN shelf directly, reading independently of the failed LUN controller. Enterprise SAS members are imaged on SAS host bus adapters, and drives formatted at a non-standard sector size are transcoded to 512-byte blocks before anything else happens.
  2. Reconstruct the RAID topology from the metadata the array wrote to the member drives. The SAN controller hardware is not needed for the formats we can parse offline.
  3. Parse the host filesystem (VMFS, NTFS, or ZFS) on the reconstructed LUN to locate & extract the virtual disk container files.

For SAN environments using SSD caching tiers (read cache or write-back cache), the cache drive must also be imaged. Write-back cache drives may contain committed writes that never reached the capacity tier. Losing the cache drive in this scenario means losing those pending writes permanently.

SSD Cache Controller Failures07/14

How Do SSD Cache Controller Failures Affect VM Datastores?

SSD cache controller failures take entire VM datastores offline when write-back cache data not yet flushed to capacity drives becomes inaccessible. A cache SSD whose Flash Translation Layer is corrupted stops presenting its capacity and locks the host interface. PC-3000 SSD recovers the FTL via Technological Mode, rebuilding translation tables from surviving NAND page metadata.

vSAN and enterprise SAN environments use SSDs as read/write cache tiers. When the Flash Translation Layer on one of those cache SSDs is corrupted, the controller locks and write-back cache data not yet flushed to capacity drives becomes inaccessible until PC-3000 SSD interfaces with the locked controller via Technological Mode to rebuild the FTL from surviving NAND page metadata.

Phison S11 (PS3111) firmware corruption
A Phison S11 (PS3111) SATA controller whose FTL has been corrupted drops offline and stops presenting its capacity. We use PC-3000 SSD to inject a firmware loader into the controller's SRAM via Technological Mode, rebuilding the FTL from surviving NAND page metadata.
Silicon Motion SM2259XT firmware corruption
SM2259XT-based drives used in NAS & VM caching can suffer FTL table corruption that leaves the drive reporting the wrong capacity. A drive in that state is not reachable by recovery software running against the normal host interface.

What Happens When a Hyper-V Checkpoint Merge Fails?

When a Hyper-V checkpoint merge is interrupted by host shutdown, storage disconnection, or hypervisor crash, the AVHDX differencing disks are left orphaned and the parent VHDX is left in an indeterminate state. The VM configuration file (VMCX) still references the checkpoint chain, so simply re-attaching the parent VHDX produces inconsistent guest data. Recovery requires parsing each AVHDX BAT, ordering the deltas by creation timestamp, and consolidating the writes into a single base VHDX offline.

Hyper-V supports two virtual disk container formats. The legacy VHD format from Windows Server 2008 stores its 512-byte footer at the end of the file; corruption of those final sectors leaves Windows unable to mount the image even when most of the data is intact. VHDX, introduced with Windows Server 2012, stores two redundant 64 KB header copies at the 64 KB and 128 KB file offsets and can survive single-header corruption.

Legacy VHD: 2 TB ceiling and footer-only metadata
VHD files use a single footer structure that contains the disk geometry and type (fixed, dynamic, differencing). If that footer is zeroed by a truncation event or a partial copy, the image is unmountable. We extract the footer from a backup or rebuild it from the file size and known guest geometry before mounting. VHD also caps at 2040 GB; older Hyper-V environments that hit this limit often show silent guest filesystem corruption.
Interrupted checkpoint merge
Initiating a checkpoint deletion in Hyper-V Manager triggers a background merge that copies AVHDX delta blocks back into the parent VHDX. If the host loses power or the storage subsystem disconnects mid-merge, the AVHDX file remains on disk, the parent VHDX has been partially updated, and the VMCX configuration file sometimes still lists the checkpoint as active. Restarting Hyper-V in this state can corrupt the parent further. The safe procedure is to image both the parent and every orphaned AVHDX file write-blocked, then reconstruct the merge offline by replaying AVHDX BAT entries in chronological order.
Cluster Shared Volume (CSV) failures
CSVs allow multiple Hyper-V hosts to access the same NTFS or ReFS volume holding VHDX files. A coordinator-node failure during checkpoint operations can leave VHDX files in inconsistent states across the cluster. We image the underlying SAN LUN as a single block device, parse the CSV NTFS or ReFS structures offline, and extract each VHDX independently of cluster state.

For mixed-environment recoveries that include both Hyper-V and VMware hosts on shared server storage infrastructure, both hypervisor metadata layers are reconstructed from the same underlying drive images.

TRIM/UNMAP Warning08/14

Can Deleted VMs Be Recovered from SSD Datastores?

Deleted VM recovery from SSD-backed datastores is generally impossible once TRIM or UNMAP commands have executed, because the controller unmaps those blocks from the translation layer and garbage collection then erases the NAND pages holding them. VMFS6 enables UNMAP by default. Power down the storage immediately after accidental deletion to prevent garbage collection from running.

Recovery of deleted virtual machines from SSD-backed datastores is generally impossible if TRIM or UNMAP commands have already executed, because the controller unmaps those blocks from its translation layer and garbage collection erases the NAND pages that held them.

VMFS6 UNMAP
Enabled by default. ESXi periodically issues SCSI UNMAP commands to the SAN for deleted blocks. Once the SSD controller processes the UNMAP, garbage collection erases the NAND pages.

If you suspect a VM was accidentally deleted from an SSD-backed datastore, power down the storage immediately. Every second the storage remains online gives the controller more time to execute pending TRIM operations & run garbage collection.

Physical vs Logical Failure Domain Table09/14

What Are the Physical vs. Logical Failure Domains in VM Recovery?

VM recovery splits into two failure domains: physical and logical. Physical failures such as drive head crashes, PCB failures, and SSD controller lockups require write-blocked imaging before any logical work can begin. Logical failures such as VMFS corruption, VMDK descriptor loss, and broken snapshot chains require metadata reconstruction and snapshot chain consolidation on clean drive images.

VM recovery splits into two distinct failure domains that determine the recovery approach and cost. Physical failures include drive head crashes, PCB failures, and SSD controller lockups; these require write-blocked imaging. Logical failures include VMFS corruption, VMDK descriptor loss, and broken snapshot chains; these require metadata reconstruction and snapshot chain consolidation.

Unlike standard hard drive recovery, enterprise SAS drives add a hardware-level complication: non-standard sector sizes that require specialized transcoding before any logical parsing can begin.

DomainFailure ExamplesRecovery ApproachTools
Physical (Hardware)Drive head crash, motor seizure, PCB failure, SAS/SATA interface fault, SSD controller failureWrite-blocked imaging through PC-3000, head swaps in clean bench, firmware repairPC-3000, DeepSpar, 0.02µm ULPA clean bench
Logical (Software)VMFS corruption, VMDK descriptor loss, VHDX BAT damage, qcow2 L1/L2 table corruption, broken snapshot chainHost filesystem parsing, virtual disk metadata reconstruction, snapshot chain consolidationData Extractor Express RAID Edition, hex analysis, custom parsing tools

SAS Infrastructure and Non-Standard Sector Sizes

Some enterprise arrays format their SAS drives with 520-byte sectors instead of the standard 512 bytes, so every sector carries eight bytes beyond the 512 the filesystem expects.

Standard SATA imaging tools can't read 520-byte SAS sectors. We use SAS Host Bus Adapters to image these drives natively, then transcode the sectors back to 512-byte blocks. This sector transcoding is mandatory before offline RAID reconstruction & VMFS parsing can proceed.

RAID Warning10/14

Should You Rebuild a RAID Array Before VM Recovery?

No, not on degrading hardware. A rebuild pins every surviving member at close to 100% sustained read until it finishes, and a marginal same-batch survivor can fail mechanically under that load; losing a second member on a single-parity array drops it below tolerance and takes the VM data with it. For irreplaceable, unbacked data we image first instead of gambling on a live rebuild. Power down the server, label drives by bay position, and ship bare drives. Original drives are never written to.

No, not when the drives are mechanically failing. Rebuilding a degraded array on degrading hardware can cause complete data loss. The controller forces a full-surface read of every surviving member to recalculate parity, which pins them at sustained read until the rebuild finishes. If a marginal same-batch survivor fails mechanically under that load, a single-parity array loses its second member and drops below tolerance.

  • Power down the server immediately
  • Label each drive with its bay position (bay 0, bay 1, etc.)
  • Ship the bare drives to our Austin, TX lab. We don't need the server chassis or controller card.
  • We image each drive individually through PC-3000, replacing heads on failed members as needed
  • The array is reconstructed virtually from the images. Original drives are never written to.

Per-drive pricing for hard drive recovery starts at From $100. Head swaps on failed RAID members cost $1,200–$1,500 per drive plus donor. +$100 rush fee to move to the front of the queue.

SMR Warning for Virtualization11/14

Why Do SMR Drives Fail Under VM Workloads?

Shingled Magnetic Recording (SMR) drives fail under VM workloads because random writes require read-modify-write cycles across entire write bands, causing severe performance degradation. VM workloads produce high random I/O. RAID or ZFS pools built on SMR drives extend rebuild times from hours to days, increasing the probability of cascading failures on surviving members.

Shingled Magnetic Recording (SMR) drives overlap write tracks to increase density. Random writes require read-modify-write cycles across entire bands, which causes severe performance degradation under sustained random I/O. VM workloads produce high random I/O. If SMR drives were used in a RAID or ZFS pool hosting VMs, rebuild times extend from hours to days.

The extended stress on surviving members during a rebuild increases the probability of cascading failures.

Proxmox VE Storage Backends: ZFS, LVM-thin, and Ceph Recovery

Proxmox stores VM disks across three primary storage backends, each with distinct failure modes. ZFS pool recovery hinges on uberblock and metaslab integrity. LVM-thin recovery requires the metadata logical volume to be intact, since it tracks the chunk-allocation tree for every thin volume in the pool. Ceph RBD recovery extracts virtual disks object by object from individual OSD drives without requiring a surviving monitor quorum, by parsing each OSD's BlueStore key-value index offline.

Proxmox VE abstracts virtual disk storage behind a backend selector, but each backend produces fundamentally different on-disk structures and fundamentally different recovery workflows when storage fails.

ZFS (rpool, dpool, zvol-backed VMs)
Proxmox uses ZFS zvols (block devices carved from a ZFS pool) to back VM disks. Pool recovery requires intact uberblocks from at least one vdev label and intact metaslab allocation maps. Recovery imports the pool read-only into a separate analysis host and exports each zvol as a raw block device for guest-filesystem extraction.
LVM-thin pools
LVM-thin stores all chunk-allocation metadata in a small metadata logical volume separate from the data LV. If the metadata LV is corrupted or its checksum fails, every thin volume in the pool becomes inaccessible even when the data LV is fully intact. Recovery dumps the metadata LV via thin_dump, repairs the chunk tree using thin_repair against an offline copy, and rebuilds the thin volume mapping. Power loss during a thin volume snapshot create or merge is the most common failure trigger.
Ceph RBD (hyperconverged Proxmox clusters)
Ceph splits each RBD image into 4 MB objects distributed across OSDs (Object Storage Daemons) according to the CRUSH map. When the cluster loses monitor quorum or too many OSDs go offline simultaneously, Ceph refuses to serve I/O. We pull individual OSD drives, image them write-blocked, and parse each OSD's on-disk object directory (BlueStore key-value index) to extract every object belonging to the target RBD image. Object reassembly into a flat block device proceeds offline using the RBD header object.

Backing file chains used by Proxmox linked clones add another failure dimension across all three backends: if the base image and overlay reside on different storage backends, a failure on either backend breaks the chain and both halves must be recovered independently.

How Do NFS Datastore and NAS Volume Failures Affect VMs?

NAS appliances backing VM datastores over NFS fail in ways that present to the hypervisor as data loss but are actually transport-layer or volume-manager problems. NFS datastore stale handles after a NAS reboot leave VMs inaccessible until the export is remounted. Consumer-grade NAS volume managers stack a filesystem over LVM over mdadm, so a damaged volume is reconstructed layer by layer offline rather than through the NAS GUI.

Hosting production virtual machines on consumer or prosumer NAS appliances introduces failure modes that do not exist on dedicated SAN storage. The volume manager, network transport, and underlying RAID layer all contribute distinct failure paths.

NFS stale handle after NAS reboot or volume migration
ESXi caches NFS file handles for VMDK files. If the NAS reboots or the underlying volume is recreated, those handles become stale and the hypervisor reports the datastore as inaccessible even though the data on the NAS is intact. Forcing a VM power-on against a stale handle can corrupt the VMDK descriptor. Recovery requires unmounting the datastore cleanly, re-imaging the underlying NAS volume, and re-importing the VMs against fresh handles.
Synology SHR and QNAP QTS volume layouts
Synology SHR layers Btrfs over LVM over mdadm, while QNAP QTS layers ext4 over LVM over mdadm. When one of those volumes will not come back through the appliance, we pull the bare drives, image each member, reconstruct the mdadm RAID, parse the LVM layer offline, and extract the VM disk container files from the recovered Btrfs or ext4 filesystem. See our NAS data recovery page for vendor-specific volume layouts.

Enterprise Virtualization Admin: Engagement, RTO/RPO, Chain of Custody

Enterprise VM recovery ships bare drives only, requires a mutual NDA before drives leave the customer site, and logs a chain-of-custody entry at every internal transfer. All work is performed in-house at our Austin, TX lab; drives never leave for sublet recovery. Turnaround is set by drive condition, and cases needing donor parts follow the turnaround published in the pricing table.

Production VM recovery for virtualization administrators is a different engagement shape from end-user recovery. The work requires a written failure narrative before drives ship, NDA coverage on the VM images themselves (not just the contract), and a documented chain of custody that survives a downstream compliance audit. If your compliance program mandates a vendor with specific regulatory certifications, confirm with your auditor before shipping; our process is appropriate for standard corporate confidentiality and most attorney engagements, but it is not a substitute for a certification you are contractually obligated to use.

RPO Boundaries by Logical Failure Class

These classes cover failures where the drives themselves still read. Turnaround for every class is the turnaround published against its tier in the pricing table below. A simultaneous logical-plus-physical failure (head crash on one member of a RAID 5 with VMFS corruption on the surviving members) follows the slower of the two timelines because imaging must complete before metadata work begins.

Failure ClassRPO BoundaryDriver
VMFS metadata corruption (intact drives)Last completed VMFS journal commit before crashVMFS heartbeat region and file metadata parsing
Broken VMDK snapshot chainLast consistent delta with valid CID lineageGrain directory and CID/parentCID reconstruction
Hyper-V interrupted checkpoint mergeLast AVHDX delta with intact BATBAT replay and VMCX timestamp correlation

Rush queueing moves a case ahead of standard work but cannot shorten the physical imaging clock. A 4 TB drive with head damage images at the read rate the surviving heads can sustain; there is no shortcut. +$100 rush fee to move to the front of the queue.

Chain of Custody Documentation

Every drive that arrives at the Austin, TX lab is logged at receipt with shipping label imagery, serial number capture, and external photographs documenting physical condition. Each internal transfer between imaging station, clean bench, reconstruction workstation, and return shipment is logged against the case.

The chain-of-custody log is provided with the recovered data. The log is sufficient for routine corporate compliance review and most legal hold engagements; it is not a forensic chain of custody appropriate for criminal evidence handling, which requires a separately scoped forensic engagement.

NDA Coverage for Sensitive VM Images

We sign mutual NDAs before drives leave the customer site. The NDA covers the contents of the VM images, not only the contractual relationship; engineers handling the images do so under the same NDA scope. Single-location, in-house policy means images are not transferred to partner facilities, off-shore engineers, or cloud analysis pipelines.

If the dataset includes sensitive material, brief us in writing before drives ship so handling can be scoped against the relevant data-handling requirements. Requests for baseline NDA templates or redlines can be routed to help@rossmanngroup.com.

We do not perform decryption work against customer encryption layers; recovery returns the data in the same encrypted state it left the source, with the file system intact and the customer-managed key still required for guest access.

Engineer Engagement Protocol

Production incidents are best opened with a written failure narrative covering hypervisor and version, host filesystem (VMFS5/6, ReFS, NTFS, ZFS, Btrfs), storage backend (direct-attached, SAS shelf, SAN LUN, NFS, iSCSI, vSAN, Ceph RBD), the sequence of events that preceded loss, and any actions taken since (rebuild attempts, consolidation retries, forced unmounts). Send the narrative before the drives. A single thirty-minute call before shipping prevents a multi-day reconstruction in the wrong direction.

For multi-host or cluster failures, include the shared-storage topology and the inventory of which drives came from which bay in which shelf; bay position is required for RAID reconstruction on controllers that do not embed member ordering in the on-disk metadata. For deeper context on the underlying RAID mechanics, see our RAID data recovery and server data recovery workflow pages.

Direct Engineer Access for VM Recoveries

VMware ESXi and Hyper-V customers speak to the engineer running the recovery, not a sales relay. The technician parsing the VMFS metadata, walking VMDK descriptor chains across snapshot deltas, or rebuilding a corrupted VHDX log is the same person on the call thread and email exchange. Status updates cite actual work performed: members imaged, snapshot generations linked, partition tables reconstructed, parity rotation detected. The written failure narrative described above goes to that engineer; nothing is filtered through an account manager.

Pricing12/14

How Much Does Virtual Machine Data Recovery Cost?

Virtual machine recovery is priced per drive, not per VM. Each drive in the datastore follows one of five published tiers based on its physical condition: $100 for simple copies through $2,000 for platter damage. A three-drive RAID 5 with one failed mechanical member is billed as two tier-1 images plus one tier-4 head swap. No data recovered means no charge.

Virtual machine recovery pricing is based on each drive's physical condition. Per-drive pricing follows the same five published tiers used for all drive recoveries, from From $100 to $2,000. Multi-drive arrays involve additional reconstruction work to detect RAID parameters, extract virtual disks, & consolidate snapshots. No data recovered means no charge. +$100 rush fee to move to the front of the queue. Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.

  1. Low complexity

    Simple Copy

    Your drive works, you just need the data moved off it

    Functional drive; data transfer to new media

    Rush available: +$100

    $100

    3-5 business days

  2. Low complexity

    File System Recovery

    Your drive isn't recognized by your computer, but it's not making unusual sounds

    File system corruption. Accessible with professional recovery software but not by the OS

    Starting price; final depends on complexity

    From $250

    2-4 weeks

  3. Medium complexity

    Firmware Repair

    Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond

    Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access

    CMR drive: $600. SMR drive: $900.

    $600–$900

    3-6 weeks

  4. High complexity

    Most Common

    Head Swap

    Bench diagnosis found the read/write heads have to be replaced. Clicking can also come from firmware, the preamp, or the spindle

    Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench

    50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.

    50% deposit required

    $1,200–$1,500

    4-8 weeks

  5. High complexity

    Surface / Platter Damage

    Your drive was dropped, has visible damage, or a head crash scraped the platters

    Platter scoring or contamination. Requires platter cleaning and head swap

    50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.

    50% deposit required

    $2,000

    4-8 weeks

Hardware Repair vs. Software Locks

Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.

No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.

Rush fee
+$100 rush fee to move to the front of the queue
Donor drives
Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
Target drive
The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.

The prices above are for standard hard drives, which covers most jobs. Helium-sealed drives (for example WD or HGST Ultrastar He and Seagate Exos X) must be resealed and refilled with helium in-house after the chamber is opened, so they price higher, in the $200–$5,000+ range. See helium drive pricing.

Most enterprise ESXi, Hyper-V, & Proxmox VE datastores now sit on SSD or NVMe-backed storage, not spinning disk. When a SATA SSD-backed array member fails, that drive is billed against the SATA SSD tiers below, from From $200 for a working drive that just needs the data imaged off it through controller, firmware, & NAND-swap work, rather than the HDD tiers above. A mixed array with both mechanical & solid-state members is priced per drive on whichever table matches each member.

  1. Low complexity

    Simple Copy

    Your drive works, you just need the data moved off it

    Functional drive; data transfer to new media

    Rush available: +$100

    $200

    3-5 business days

  2. Low complexity

    File System Recovery

    Your drive isn't showing up, but it's not physically damaged

    File system corruption. Visible to recovery software but not to OS

    Starting price; final depends on complexity

    From $250

    2-4 weeks

  3. Medium complexity

    Circuit Board Repair

    Your drive won't power on or has shorted components

    PCB issues: failed voltage regulators, dead PMICs, shorted capacitors

    May require a donor drive (additional cost)

    $450–$600

    3-6 weeks

  4. Medium complexity

    Most Common

    Firmware Recovery

    Your drive is detected but shows the wrong name, wrong size, or no data

    Firmware corruption: ROM, modules, or system files corrupted

    Price depends on extent of bad areas in NAND

    $600–$900

    3-6 weeks

  5. High complexity

    PCB / NAND Swap

    Your drive's circuit board is severely damaged and requires NAND chip transplant to a donor PCB

    NAND swap onto donor PCB. Precision microsoldering and BGA rework required

    50% deposit required; donor drive cost additional

    50% deposit required

    $1,200–$1,500

    4-8 weeks

Hardware Repair vs. Software Locks

Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.

No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. NAND swap requires a 50% deposit because donor parts are consumed in the attempt.

Rush fee
+$100 rush fee to move to the front of the queue
Donor drives
A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.
Target drive
The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. All prices are plus applicable tax.

Data Recovery Standards & Verification

Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.

Localized Clean Zone

Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.

Transparent History

Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.

Media Coverage

Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.

Aligned Incentives

Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.

LR

Technical Oversight

Louis Rossmann

Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.

We believe in showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.

See the particle counter test at the bench
Reviews13/14
Faq14/14

Virtual Machine Recovery FAQ

Which virtual disk formats can you recover?
We recover VMDK (VMware ESXi and Workstation), VHD and VHDX (Microsoft Hyper-V), QCOW2 (KVM, Proxmox VE, OpenStack), VDI (VirtualBox), and raw disk images. The virtual disk format determines the metadata structures we parse, but the underlying physical recovery process is the same: image the failed storage, reconstruct the array or volume, then extract the VM disk files from the host filesystem.
What causes a VMDK CID mismatch and can you fix it?
A Content ID (CID) mismatch occurs when a VMware snapshot chain breaks. This typically happens if the ESXi host crashes or loses storage connectivity during a snapshot commit, causing the parentCID of the delta disk to lose synchronization with the base flat file. We read the grain directory and grain tables from each delta, verify the actual data lineage, and reconstruct the descriptor file with correct CID/parentCID references.
Can you recover a dynamically expanding VHDX that became corrupted?
Yes. Dynamic VHDX files store data in blocks mapped by a Block Allocation Table (BAT). Power loss or storage disconnection can corrupt the VHDX headers, the BAT, or the log entries. We image the underlying storage write-blocked and do every extraction attempt against that image; the original disk is never written to.
How do you handle qcow2 corruption on Proxmox VE?
Proxmox stores KVM virtual machine disks as qcow2 files on ZFS, LVM-thin, or Ceph storage backends. Power loss during write operations with cache=none can produce torn writes that leave the L1/L2 mapping tables and the reference count table inconsistent. We image the storage write-blocked and parse the surviving qcow2 metadata from that image.
Do I need to send the entire server or just the drives?
Send the drives. We do not need the server chassis, controller card, or cabling. For RAID arrays, label each drive with its slot position (bay 0, bay 1, etc.) before removing them. We extract RAID metadata (DDF, PERC, Smart Array, mdadm superblocks, ZFS labels) from the drives themselves and reconstruct the array offline using Data Extractor Express RAID Edition.
Can deleted VMs be recovered from SSD-backed datastores?
It depends on whether TRIM/UNMAP was active. VMFS6 enables automatic UNMAP by default. If the SAN or local SSD controller has already executed TRIM on the blocks that held the deleted virtual disk, the controller marks those blocks as no longer needed and garbage collection erases the NAND pages. Recovery is not possible. If TRIM was disabled or has not yet executed, recovery is still feasible. Power down the storage immediately to prevent garbage collection.
How much does virtual machine data recovery cost?
Pricing depends on the physical condition of the drives hosting the datastore. Per-drive pricing starts at $100 for simple copies, From $250 for file system recovery, $600–$900 for firmware repair, $1,200–$1,500 for head swaps, and $2,000 for platter damage. These are the same five published tiers we use for all drive recoveries. Multi-drive RAID arrays involve additional reconstruction work. No data recovered means no charge. +$100 rush fee to move to the front of the queue.
How does Phison S11 firmware corruption affect virtual machine cache drives?
A cache SSD built on the Phison S11 (PS3111) SATA controller stops presenting its capacity once its Flash Translation Layer is corrupted. We use PC-3000 SSD to interface with the controller via Technological Mode, load custom microcode into the controller's SRAM, & rebuild the translation tables to extract pending cache writes.
Can you recover VMDKs from SAS drives formatted with 520-byte sectors?
Yes. Some enterprise arrays format SAS drives with 520-byte sectors instead of the standard 512 bytes. Standard recovery software can't read non-standard sector sizes. We image the drives on SAS-capable imaging hardware, transcode the sectors back to 512-byte blocks, & reconstruct the controller metadata offline to extract the VMFS datastore.
How long does virtual machine recovery take for a production workload?
Turnaround depends on drive count, physical condition, and array complexity, and follows the turnaround published against each tier in the pricing table on this page. A single-drive qcow2 extraction with no mechanical damage is the fastest case. A multi-drive RAID 5 or RAID 6 array with one or more failed members requiring head swaps takes longer, driven by donor drive sourcing and sector-by-sector imaging time. vSAN and multi-node cluster reconstructions extend further. +$100 rush fee to move to the front of the queue. A rush case moves to the front of the queue ahead of standard cases.
Do you sign NDAs and provide chain-of-custody documentation?
Yes. We sign mutual NDAs before any drives arrive and provide chain-of-custody logs tracking every transfer between shipping, imaging, reconstruction, and return shipment. All work is performed in-house at our Austin, TX lab; drives are never sublet or shipped to partner facilities. If your compliance framework requires a specifically certified data recovery vendor, confirm with your auditor before sending drives. For standard corporate confidentiality needs, our NDA and single-facility policy are sufficient.
Can you recover VMware vSAN when a disk group fails?
Yes. vSAN disk groups pair one cache-tier SSD with one or more capacity-tier drives. When the cache SSD fails, every capacity drive in that group goes offline because vSAN cannot flush pending writes. We image the failed cache SSD via PC-3000 SSD where the controller family is supported, then image each capacity drive independently. What can be pulled back out of the imaged disk group is scoped per case.
Can you recover a single array hosting Windows, Linux, and BSD VMs together?
Yes. Once the physical array is imaged and the host filesystem (VMFS, NTFS, ZFS, or ext4) is parsed, each virtual disk container file is extracted independently. The guest operating system inside the VMDK, VHDX, or qcow2 file has no bearing on our ability to extract the container. After extraction, we verify guest filesystem integrity by mounting the recovered virtual disk read-only against NTFS, ReFS, ext4, XFS, Btrfs, ZFS, or UFS drivers. Mixed-guest arrays do not carry a pricing premium; the per-drive tier structure is unchanged.
Our Fault Tolerance VMs require eagerzeroedthick. Does that change recovery?
It simplifies part of it. Eagerzeroedthick VMDKs pre-allocate and zero every block at creation, so there is no thin-provisioned sparse allocation map to reconstruct and the full virtual disk size is known up front. We still walk the VMFS pointer metadata to reassemble the extent in order rather than carving by file size alone.
Our NFS datastore went inaccessible after the NAS rebooted. The data is still on the NAS. What now?
Do not force a VM power-on against the inaccessible datastore. ESXi caches NFS file handles and a forced operation against a stale handle can corrupt the VMDK descriptor and snapshot chain. Unmount the datastore cleanly from every host, verify the NFS export and underlying volume are healthy on the NAS side, and remount. If the NAS volume itself was recreated or its UUID changed, the file handles will not refresh and the datastore must be re-registered. If a forced power-on already occurred and the VMDK is now showing CID mismatches or descriptor errors, image the underlying NAS volume offline and recover the VMs through descriptor reconstruction.
Can you recover a Hyper-V VM whose Live Migration was interrupted halfway?
Yes. An interrupted Live Migration leaves the VHDX in an indeterminate state: part of the memory and disk delta has transferred to the destination host but the VM is no longer cleanly owned by either side. The source VHDX may be locked by the source Hyper-V service, and the destination may have a partial copy. We image both copies of the VHDX write-blocked, compare the two against the VMCX configuration timestamps, identify the most recent consistent state, and reconstruct the guest filesystem from whichever copy preserves filesystem journal consistency.
What RTO and RPO should I expect on a VMFS or Hyper-V emergency recovery?
Recovery Time Objective and Recovery Point Objective are dictated by the failure type, not by a marketing SLA. On a logical-only failure (intact drives, corrupted VMFS heartbeat, broken VMDK snapshot chain, qcow2 L1/L2 damage) imaging completes before metadata reconstruction begins, and the RPO is whatever the guest filesystem journal preserved at the moment of failure. A multi-drive RAID 5/6 or vSAN failure with one or more mechanical members takes longer because donor drives must be sourced and platter imaging is sector-by-sector at a fixed read rate. Every case follows the turnaround published against its tier in the pricing table on this page. A SAN shelf with simultaneous head crashes on multiple members extends further. Rush queueing moves a case to the front but does not change the physical imaging clock; a 1 TB degraded drive still needs hours to image regardless of priority. Provide a written failure description before shipping so we can pre-stage donor inventory.
Our ESXi host shows orphaned VMDK files with no VM registered. Can you recover them?
Yes. An orphaned VMDK is a flat extent and descriptor pair that the inventory database no longer references, either because the VM was removed without deleting the files, the .vmx was lost, or a failed cluster operation desynchronized the inventory from the datastore. The data is intact on the VMFS volume. We parse the VMFS metadata offline to enumerate every flat extent, pair each flat with the descriptor that names it in its extent description, walk any surviving snapshot chain by reading parentCID values, and produce a mountable virtual disk. If the descriptor was lost entirely, virtual disk geometry is reconstructed from the flat file size and the guest filesystem header. Do not attempt to import an orphaned VMDK directly into a running ESXi inventory; if the CID chain is broken, the import will write a new descriptor and break the lineage required for clean recovery.
How do you handle a corrupted ESXi snapshot chain when consolidation has failed repeatedly?
Failed consolidation in ESXi leaves the VM with a chain of delta disks (-000001.vmdk, -000002.vmdk) that the Snapshot Manager cannot collapse. Causes include a stuck VMFS lock on the base flat file, an exhausted datastore with no room for the merge, or a sesparse delta whose grain table was partially overwritten by a crash. Running another consolidate from vSphere against a damaged chain frequently extends the corruption. We image the entire chain write-blocked from the datastore, walk the grain directories of every delta in order, and rebuild a single consolidated flat file offline. The original chain is preserved untouched so multiple consolidation passes can be attempted against different chronological orderings if the first replay shows guest filesystem inconsistency.
Our Ceph cluster lost monitor quorum. Can we recover RBD images from the OSD drives directly?
Yes. Ceph RBD images are sharded into 4 MB objects distributed across OSDs according to the CRUSH map. When monitor quorum is lost, the cluster refuses I/O, but the underlying object data remains on each OSD drive. We pull the OSD drives, image each one write-blocked, parse the BlueStore key-value index on each drive to enumerate every object, and reassemble RBD images by reading the RBD header object. The CRUSH map is reconstructed from the OSD metadata if no surviving copy exists. Recovery does not require a working monitor.

No Data, No Fee

Guarantee

2.49M+

Subscribers

4.9

1,837+ Google Reviews

Since 2008

Established

Repairs on Video

Full Transparency

As Featured In

BBC News
CBC News
ABC Australia
Wall Street Journal
Business Insider
Vice
Fast Company
404 Media

Related services

Related Recovery Services

RAID Data Recovery

RAID 0, 1, 5, 6, 10, 50, 60 array reconstruction from failed controllers and degraded arrays

NAS Data Recovery

Synology, QNAP, TrueNAS, Buffalo NAS recovery from failed pools and degraded volumes

Server Data Recovery

Dell PowerEdge, HP ProLiant, Supermicro server recovery from failed RAID arrays

Hard Drive Data Recovery

Clicking, beeping, dead HDDs. 5 published pricing tiers, from $100

SSD Data Recovery

NVMe, M.2, SATA solid state drive recovery from controller and firmware failures

Database Recovery

SQL Server, Exchange, MySQL, Oracle, PostgreSQL, MongoDB, and QuickBooks files after the storage layer is imaged

SQL Server MDF Recovery

MDF and NDF page repair, suspect mode, and error 5171, 823, and 824 handling

MySQL and MariaDB Recovery

InnoDB tablespace work on ibdata1, per-table .ibd files, and redo logs

PostgreSQL Cluster Recovery

WAL segment reconstruction, pg_control repair, and TOAST table extraction

Ready to recover your virtual machines?

Free evaluation. No data = no charge. Ship your drives from anywhere in the U.S.

Start a CaseServer Recovery Overview
(512) 212-9111Mon-Fri 10am-6pm CT
No diagnostic fee
No data, no fee
4.9 stars, 1,837+ reviews
4.9★ · 1,837+ Google reviews
Call NowEmail Us