Lab Operational Since: 17 Years, 7 Months, 16 Days·Facility Status: Fully Operational & Accepting New Cases·
Lab Operational Since: 17 Years, 7 Months, 16 Days·Facility Status: Fully Operational & Accepting New Cases·
Lab Operational Since: 17 Years, 7 Months, 16 Days·Facility Status: Fully Operational & Accepting New Cases·
Enterprise Virtualization Recovery
Microsoft Hyper-V Data Recovery
We recover VHD/VHDX virtual disks from failed RAID arrays, repair broken checkpoint chains, reconstruct Cluster Shared Volumes, and extract VMs from corrupted Hyper-V hosts. Free evaluation. No data = no charge.
How Hyper-V Environments Fail and How We Recover Them
Microsoft Hyper-V stores virtual machines as VHD or VHDX files on NTFS or ReFS volumes, often backed by RAID arrays or SAN LUNs. When the underlying storage fails, the Hyper-V host loses access to the virtual disks and all VMs on that volume go offline. Recovery requires imaging the physical drives, reconstructing the RAID array offline, parsing the host filesystem, and extracting each .vhdx file individually.
VHDX replaced VHD in Windows Server 2012 as the default virtual disk format. It supports up to 64TB per file, carries a log region (1MB by default) for crash consistency, and can be either fixed-size or dynamically expanding. Checkpoints (formerly "snapshots") create .avhdx differencing disks that track block-level changes relative to a parent. Cluster Shared Volumes (CSV) extend the storage model to failover clusters, allowing multiple Hyper-V hosts to access the same LUN simultaneously.
Vhdx On-Disk Structure03/09
VHDX On-Disk Structure and Failure Points
VHDX begins with the 8-byte "vhdxfile" file type identifier at offset 0, followed by two header copies at 64KB and 128KB, a region table at 192KB, a 1MB log region at the 1MB offset, the BAT (Block Allocation Table), and a metadata region with parent locators. Storage-layer corruption of any of these renders the file unmountable, and recovery parses each structure directly from the raw image.
Understanding the VHDX binary layout is required for targeted recovery. The format was designed for resilience, but storage-layer failures can still render files unreadable.
VHDX Header and Metadata
The 8-byte "vhdxfile" file type identifier sits at offset 0; two header copies live at offsets 64KB and 128KB for redundancy
Region table at offset 192KB describes the location of the BAT (Block Allocation Table) and metadata regions within the file
BAT maps each virtual disk block to its physical offset in the VHDX file; for dynamic disks, unallocated blocks have a BAT entry state of PAYLOAD_BLOCK_NOT_PRESENT
Log region (1MB by default, at the 1MB offset after the headers and region table) records pending metadata updates; Hyper-V replays this log on mount to ensure consistency
Metadata region stores virtual disk size, logical/physical sector size, payload block size (configurable 1MB to 256MB, 32MB default), and parent locator for differencing disks
Differencing Disks
Each checkpoint creates an .avhdx file that becomes the active write target; the parent .vhdx becomes read-only
.avhdx files use the same VHDX format but with a parent locator in the metadata region pointing to the parent file by path and unique ID
Block-level change tracking: only modified blocks have BAT entries; reads for unmodified blocks are passed through to the parent
Merge operation (checkpoint deletion) copies changed blocks from the .avhdx into the parent; power loss during merge can leave both files in an inconsistent state
Deep checkpoint chains (5+ levels) increase fragmentation and I/O latency; failed merges at any level can strand the entire chain
The BAT holds two entry types for dynamic and differencing disks: payload BAT entries and sector bitmap BAT entries. Each payload entry carries one of three states. PAYLOAD_BLOCK_NOT_PRESENT means the block was never written and reads pass through to the parent (or return zeros for a base disk).
PAYLOAD_BLOCK_FULLY_PRESENT means every sector in the block lives in this file. PAYLOAD_BLOCK_PARTIALLY_PRESENT means only some sectors are present, and the associated sector bitmap block decides which sectors come from this file versus the parent. Misreading these states during extraction silently returns stale parent data, so we resolve every partially present block against its bitmap before writing output.
When a RAID failure corrupts the NTFS volume hosting the VHDX files, the Hyper-V host cannot read the VHDX headers, BAT, or log region. Standard Hyper-V tools (Inspect-VHD, Merge-VHD) require a mounted volume and operate strictly offline against an unattached disk chain. Running them against a live degraded array, or while the underlying storage is still failing, causes large-scale logical damage. Our approach bypasses the host entirely: we parse VHDX structures from the raw RAID image and extract virtual disks by resolving BAT entries against their sector bitmaps.
# Merge-VHD is an OFFLINE operation. The chain must be unattached,
# and it must run against verified copies, never the live array.
# Inspect the chain first, then merge a checkpoint into its parent:
Inspect-VHD -Path D:\copies\vm01\disk0.avhdx
Merge-VHD -Path D:\copies\vm01\disk0.avhdx -DestinationPath D:\copies\vm01\disk0.vhdx
Cluster Shared Volume Recovery04/09
Cluster Shared Volume Recovery
Cluster Shared Volumes let multiple Hyper-V hosts in a Windows failover cluster access the same volume simultaneously. CSV coordinates access through a metadata layer that assigns file ownership to specific nodes. When the underlying storage fails, the CSV coordination layer is irrelevant; recovery targets the NTFS or ReFS filesystem and the VHDX files directly from the raw array image.
NTFS underneath (direct I/O): CSV on NTFS uses standard NTFS on the SAN LUN or RAID volume. Each node performs direct I/O to the SAN for the files it owns, while the coordinator node owns metadata-changing operations. The actual file storage is plain NTFS, so once we have the raw RAID image we parse NTFS normally and follow each VHDX run list.
ReFS on Server 2016+ (redirected I/O): Windows Server 2016 and later support ReFS for CSV volumes, but ReFS on CSV runs in file-system redirected I/O mode, routing data through the coordinator node rather than direct SAN access. ReFS uses checksummed B+ tree metadata and allocator-based data placement, and ReFS block cloning accelerates checkpoint merges. Storage Spaces Direct (S2D) builds on this same ReFS block cloning. Our tooling parses both NTFS and ReFS volumes from raw images.
Redirected I/O fallback: When a CSV owner node loses direct SAN access, other nodes fall back to redirected I/O over the cluster network. If multiple nodes lose storage access simultaneously, all VMs on the CSV go offline. The data is still on the physical drives; the CSV coordination failure is a software problem, not a storage problem. A CSV failure does not mean the data is gone.
Hyper-V Replica Failure Scenarios05/09
Hyper-V Replica Failure Scenarios
Hyper-V Replica asynchronously copies VM changes to a secondary host on a default 5-minute cycle. Replica is availability, not a backup: it tracks the primary and replays the same corruption or deletion, and it can diverge if replication falls behind. When both sites suffer storage failures, we recover from whichever site holds the most recent consistent data.
Hyper-V Replica asynchronously replicates VM changes to a secondary host. Replica is not a backup; it creates a point-in-time copy that can diverge from the primary if replication falls behind, and it will faithfully replicate a logical corruption or an accidental deletion to the secondary. When both the primary and replica sites experience storage failures, we recover from whichever site has the most recent consistent data.
Primary Site Failure
Primary host RAID fails. Replica site has a copy that is up to the last replication cycle (default: 5 minutes). We recover from the replica VHDX files, which may be missing the most recent 5 minutes of writes.
Both Sites Failed
Both primary and replica storage failed (ransomware, site-wide power event, or cascading RAID failures). We image drives from both sites and compare the VHDX timestamps to determine which copy has the most recent consistent data. Partial recovery from both copies may yield a more complete dataset.
Methodology06/09
Recovery Methodology for IT Administrators
Every member drive and every CSV or SAN LUN is cloned through a write-blocked imager before anything is parsed. The array geometry is then reconstructed virtually in software against the image files, the host filesystem is parsed, and each VHDX is extracted by resolving its BAT. No vendor repair tool ever touches the live degraded array.
Step-by-step procedures for Hyper-V environment recovery. If you are evaluating our technical capability, this is how the work gets done.
Image first, against copies only. Clone every member drive and every CSV or SAN LUN through a hardware write-blocker (ddrescue, PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager) before any parse. Never run vendor repair (Merge-VHD, chkdsk, or a controller "rebuild") against the live degraded array. A rebuild pins every surviving member at close to 100% sustained read for 18 to 48 or more hours, and a marginal same-batch survivor can fail mechanically in that window; a survivor can also surface a latent unrecoverable read error, which a legacy controller treats as a second failure while modern PERC and MegaRAID puncture the stripe and continue. For irreplaceable, unbacked data on a degraded RAID 5 above 24TB we do not gamble on a live rebuild: each member is imaged member-by-member through a write-blocked interface first.
Reconstruct the array virtually. Parse the on-disk controller metadata from the image files and reconstruct stripe size, member order, and parity rotation in software, never against the live members.
Parse the host filesystem. Read the NTFS or ReFS volume from the reconstructed image and locate every .vhdx, .avhdx, .vmcx, and .vmrs file.
Extract and consolidate. Resolve each VHDX BAT against its sector bitmaps, walk the .avhdx parent locators in creation order, and consolidate the chain into a flat VHDX at the most recent consistent state.
1. Storage Layer Imaging
Each physical drive is imaged through PC-3000 Portable III or PC-3000 Express using SAS HBAs for SAS drives or SATA/NVMe adapters as appropriate. For drives with bad sectors, we configure head maps to skip damaged heads on initial passes and revisit them with aggressive retry parameters after all healthy data is captured. DeepSpar Disk Imager provides hardware-level timeout control for drives that lock up mid-read.
2. RAID Reconstruction
If the Hyper-V host uses a hardware RAID controller (Dell PERC, HP Smart Array, LSI MegaRAID), the structural metadata lives on the member drives, not in the controller NVRAM. PERC and MegaRAID write a SNIA DDF variant on the trailing sectors of each member; HP Smart Array P-series and E-series (Gen8 to Gen10) write a proprietary RIS (RAID Information Sector) at the start of each drive inside a hidden GPT Partition 9, while newer HPE MR-series controllers are rebranded Broadcom and use DDF on the trailing sectors. We parse that on-disk metadata from the drive images with array-aware forensic software and reconstruct stripe size, member ordering, parity rotation, and RAID level virtually, without needing the original controller hardware. For Storage Spaces Direct (S2D) or software RAID, we parse the Windows Storage Spaces metadata from the drive images.
3. NTFS/ReFS Parsing and VHDX Extraction
With the RAID image reconstructed, we parse the NTFS or ReFS volume to locate .vhdx, .avhdx, .vmcx (VM configuration), and .vmrs (runtime state) files. Each VHDX is extracted by reading its BAT and following the block offsets to their physical locations in the volume. For dynamically expanding disks, only allocated blocks are present in the file.
4. Checkpoint Consolidation
If the VM has checkpoints, we reconstruct the .avhdx chain by reading each differencing disk's parent locator metadata. Changed blocks from each .avhdx are applied in sequence to the base .vhdx. If a merge was in progress when the failure occurred, we determine the merge progress from the BAT state and complete the consolidation manually. The output is a single flat VHDX representing the VM at its most recent consistent state.
Hyper-V Terminology07/09
Hyper-V and VHDX Terminology
These terms describe the on-disk structures and operations that determine whether a failed Hyper-V environment is recoverable and how the work is scoped.
VHDX (Virtual Hard Disk v2)
The default Hyper-V virtual disk format since Windows Server 2012. The BAT (Block Allocation Table) maps virtual blocks to physical offsets, the payload block size is configurable from 1MB to 256MB (32MB default), the log region is 1MB by default, and the region table at 192KB locates the BAT and metadata.
AVHDX (differencing / checkpoint disk)
A differencing disk created when a checkpoint is taken. The .avhdx becomes the active write target and uses a parent locator in its metadata region to point at the parent .vhdx by path and unique ID. Only changed blocks carry payload BAT entries; everything else reads through to the parent.
Broken checkpoint merge chain
A merge consolidates an .avhdx into its parent. Merge-VHD is strictly an offline operation that requires the disk chain to be unattached, run against verified copies. A power loss mid-merge, or running Merge-VHD against a live degraded array, leaves both files inconsistent and can cause large-scale logical damage.
Cluster Shared Volume (CSV)
A volume that multiple failover-cluster nodes access at once. CSV on NTFS uses direct I/O to the SAN for data, with the coordinator node owning metadata changes. CSV on ReFS runs in redirected I/O mode, routing data through the coordinator node.
Hyper-V Replica
Asynchronous VM replication to a secondary host on a default 5-minute cycle. It is an availability feature, not a backup: it replays the same corruption or deletion to the replica and can diverge from the primary when replication falls behind.
Fixed vs dynamic vs differencing disks
A fixed VHDX preallocates its full size on creation. A dynamic VHDX grows on demand and marks unwritten blocks PAYLOAD_BLOCK_NOT_PRESENT. A differencing VHDX (.avhdx) stores only deltas relative to a parent and depends on the parent locator chain to read unchanged data.
Pricing08/09
Hyper-V Recovery Pricing
Hyper-V recovery follows the same transparent pricing model as every other service: per-drive imaging based on each drive's condition, plus a $400-$800 reconstruction fee that includes RAID rebuild, NTFS/ReFS parsing, and VHDX extraction. No data recovered means no charge.
Service Tier
Price Range (Per Drive)
Description
Logical / Firmware Imaging
$250-$900
Firmware module damage, SMART threshold failures, or filesystem corruption on individual array members.
Mechanical (Head Swap / Motor)
$1,200-$1,50050% deposit
Donor parts consumed during transplant. SAS drives require SAS-specific donors matched by model, firmware revision, and head count.
Reconstruction + VHDX Extraction
$400-$800per array
RAID reconstruction, NTFS/ReFS parsing, VHDX extraction, and checkpoint chain consolidation if applicable.
No Data = No Charge: If we recover nothing from your Hyper-V environment, you owe $0. Free evaluation, no obligation.
Enterprise competitors charge $5,000-$15,000 with opaque "emergency" surcharges. We publish our pricing because the work is the same regardless of what label gets put on the invoice.
Faq09/09
Hyper-V Recovery; Common Questions
What causes VHDX file corruption and can it be recovered?
VHDX files carry a dedicated log region (1MB by default, located at the 1MB offset after the headers and region table) for crash consistency. Power loss during a metadata commit can leave an incomplete log entry. If the log replay fails on Hyper-V startup, the VHDX becomes unmountable. Recovery involves parsing the VHDX header, BAT (Block Allocation Table), and log entries from the raw disk image, then reconstructing a consistent virtual disk from the committed log entries.
How do you recover data from a failed Cluster Shared Volume?
Cluster Shared Volumes (CSV) use NTFS on the underlying storage with a coordination layer across Windows failover cluster nodes. When the underlying RAID array or SAN LUN fails, the CSV goes offline and all VMs on that volume are stopped. Recovery does not depend on the cluster coordination metadata. We image the underlying physical drives, reconstruct the RAID array, parse the NTFS filesystem, and extract the .vhdx files for each VM.
Can you fix a broken Hyper-V checkpoint chain?
Yes. Hyper-V checkpoints create .avhdx (Auto VHDX) differencing disks. Each .avhdx contains a BAT (Block Allocation Table) mapping changed blocks relative to its parent. When a checkpoint merge fails or the chain references are corrupted, the VM cannot start. We read the BAT from each .avhdx, determine correct parent-child ordering, and manually consolidate the differencing blocks back into the base .vhdx.
My Hyper-V failed to merge a differencing disk. Can you complete the merge?
Yes. A failed merge leaves orphaned .avhdx files that Hyper-V no longer tracks in the VM configuration (.vmcx). We parse each differencing disk's Block Allocation Table to identify which sectors it owns, then merge them in creation-time sequence into the base VHDX. The result is a single consolidated virtual disk at the VM's most recent consistent state.
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.
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.
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 proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.
“Had a raid 0 array (windows storage pool) (failed 2tb Seagate, and a working 1tb wd blue) recovered last year, it was much cheaper than the $1500 to $3500 Canadian dollars i was quoted by a Canadian data recovery service. the price while expensive was a comparatively reasonable $900USD (about $1100 CAD at the time). they had very good communication with me about the status of my recovery and were extremely professional. the drive they sent back was Very well packaged. I would 100% have a drive recovered by them again if i ever needed to again.”
“HIGHLIGHT & CONCLUSION
******Overall I'm having a good experience with this store because they have great customer services, best third party replacement parts, justify price for those replacement parts, short estimate waiting time to fix the device, 1 year warranty, and good prediction of pricing and the device life conditions whether it can fix it or not.”
“Didn't *fix* my issue but a great experience. Shipped a drive from an old NAS whose board had failed. Rossmann Repair wanted to go straight for data extraction (~$600-900). Did some research on my own and discovered the file table was Linux based and asked if they could take a look. They said that their decision still stands and would only go straight for data recovery.”
“I've been following the YouTube tutorials since my family and I were in India on business. My son spilled Geteraid on my keyboard and my computer wouldn't come on after I opened it and cleaned it, laying it upside down for a week. To make the story short I took my computer to the shop while I'm in New York on business and did charged me $45.00 for a rush assessment.”
