Windows Server Recovery

ReFS File System Data Recovery

We recover data from corrupted ReFS volumes on Windows Server 2012 R2 through Server 2025. B+ tree metadata reconstruction, Storage Spaces Direct cluster failures, Hyper-V VHDX extraction, and deduplication-aware recovery. ReFS recovery is one part of our enterprise server data recovery work: when the volume sits on a failed Storage Spaces pool, we reconstruct the pool geometry from each drive's metadata partition first, then parse the ReFS metadata. Free evaluation. No data = no charge.

FREE ESTIMATE Mail-In Service

Author01/14

Written by

Louis Rossmann

Founder & Chief Technician

Updated June 2026

16 min read

Overview02/14

How ReFS Volumes Fail and How We Recover Them

ReFS stores all metadata in B+ trees under an allocate-on-write model, so a corrupted root object table or unreadable checkpoint area leaves the volume mounting as RAW. The data stays on disk. We image the members write-blocked, then parse surviving historical metadata pages offline to rebuild the directory tree.

ReFS (Resilient File System) is Microsoft's B+ tree-based filesystem designed for Windows Server environments. Unlike NTFS, which uses a flat Master File Table (MFT) for metadata, ReFS stores all metadata in B+ trees and uses an allocate-on-write model: metadata updates are written to new disk locations rather than overwriting existing data.

When the root B+ tree node corrupts or the checkpoint area (superblock) becomes unreadable, Windows cannot mount the volume and displays it as RAW. Recovery requires parsing the B+ tree structures offline, locating historical metadata checkpoints preserved by the allocate-on-write design, and reconstructing the directory hierarchy from surviving tree nodes.

ReFS was introduced in Windows Server 2012 and has gone through several on-disk format versions (1.2 through 3.7+). Each version changes the internal B+ tree layout, page sizes, and metadata structures.

Server 2016 introduced ReFS 3.1 with block cloning support. Server 2019 updated ReFS to newer 3.x versions with improved tiering and deduplication integration. A recovery tool built for ReFS 1.2 cannot parse a 3.x volume; the metadata format is not backward compatible. Our parsing handles all production ReFS versions.

ReFS On-Disk Architecture03/14

ReFS On-Disk Architecture

Understanding the ReFS on-disk format is necessary for targeted recovery. ReFS differs from NTFS in every structural dimension.

B+ Trees and the Object Table

ReFS organizes all metadata into B+ trees. The root of the filesystem is the object table, a B+ tree whose keys are object IDs and whose values are table descriptors pointing to other B+ trees
Each directory is a B+ tree. Each file's extent map is a B+ tree. The entire metadata hierarchy is trees pointing to trees
If the root object table node is damaged, the entire volume is unmountable. Recovery requires locating a previous version of the root node from the checkpoint area or scanning for orphaned B+ tree nodes on disk

Allocate-on-Write Model

When ReFS updates metadata, it writes the new version to a different location on disk and then atomically updates the parent pointer. The old version remains at its original location until the space is reclaimed
This means metadata updates do not overwrite prior versions immediately. After a corruption event, historical metadata snapshots often survive on disk
Recovery exploits this: we scan for B+ tree pages at historical offsets, compare page sequence numbers, and reconstruct the directory tree from the most recent consistent set of pages

Checkpoint Area (Superblock)

ReFS maintains two checkpoint areas at fixed offsets on the volume. Each checkpoint stores a pointer to the current root of the object table and a sequence number
Windows alternates between the two checkpoints on each metadata flush. If one is corrupted, the other may still be valid (one transaction behind)
If both checkpoints are damaged, we locate the object table root by scanning for B+ tree page signatures across the volume surface

Container Table and Extents

ReFS tracks free space and allocated extents through a container table (also a B+ tree). Containers are large fixed bands (roughly 64 MiB in ReFS 3.x); 64 KB is the cluster size, not the container size
File data extents are referenced through the file's extent B+ tree, which maps logical file offsets to physical container numbers
For recovery, we parse the container table to resolve file extent references. If the container table is corrupted, we reconstruct extent maps from individual file B+ tree nodes

Failure Scenarios04/14

Common ReFS Failure Scenarios

Most ReFS losses trace to four causes: a RAW volume from a damaged checkpoint or root object table, a Storage Spaces pool that dropped below its resiliency floor, S2D quorum loss across cluster nodes, or chkdsk damage. The drives still hold the data; the volume just cannot be parsed by the host.

ReFS does not use NTFS-style chkdsk to repair these conditions. It handles corruption online by salvaging: when no alternate Storage Spaces copy exists, ReFS removes the corrupt data from the namespace to keep the volume mounted, which is permanent loss.

The ReFS scrubber only auto-repairs latent corruption when an alternate copy exists on a Storage Spaces mirror or parity space. With no alternate copy, the salvage path discards the affected references and the data has to be parsed back out offline.

Volume Shows as RAW

The most common ReFS failure. Windows cannot parse the checkpoint area or root object table, so it presents the volume as RAW in Disk Management. Causes include power loss during a metadata flush, firmware bugs in the storage controller, or bad sectors at the checkpoint offsets.

Storage Spaces Pool Failure

Storage Spaces (non-Direct) pools lose redundancy when more disks fail than the resiliency type allows (one for single parity or two-way mirror, two for dual parity). When the pool goes offline, all ReFS volumes on it become inaccessible. Recovery requires reconstructing the Storage Spaces virtual disk layout from the pool metadata database before parsing ReFS.

Storage Spaces Direct S2D Quorum Loss

S2D requires a majority of cluster nodes to maintain quorum. If two of three nodes fail simultaneously, the cluster loses quorum and all cluster shared volumes go offline. The data remains on the physical drives in each node. Recovery involves imaging drives from all nodes and reassembling the S2D pool geometry from each node's metadata partition.

Chkdsk Damage

Running chkdsk /f or chkdsk /r on a corrupted ReFS volume can make recovery harder. Chkdskis an NTFS repair tool; ReFS does not use NTFS-style chkdsk and running it on a corrupted ReFS volume can trigger online salvage, which discards corrupted data references rather than preserving the historical metadata that allocate-on-write had left on disk. Contact us before running chkdsk on any ReFS volume that contains data you need.

Hyper-V Host Crash

When a Hyper-V host crashes with VMs running, the ReFS volume may have uncommitted metadata for in-flight VHDX writes. The volume itself usually recovers on reboot (ReFS is designed for this), but if the crash was caused by a hardware failure (dead controller, failing drive), the combination of ReFS metadata damage and partial VHDX writes creates a two-layer recovery problem.

Deduplication Corruption

Windows Server deduplication on ReFS (introduced in Server version 1709, included in the LTSC track starting with Server 2019) creates chunk stores that replace inline file data with references. If the chunk store B+ tree or the reparse point data is corrupted, deduplicated files become unreadable even though the raw chunks exist on disk. Recovery requires reconstructing the dedup mapping table.

ReFS vs NTFS05/14

ReFS vs NTFS: Why Recovery Requires Different Tools

NTFS keeps metadata in the Master File Table, a flat record array at a fixed offset, so NTFS tools parse the MFT directly. ReFS keeps metadata in B+ trees under allocate-on-write, with no MFT to read. A tool built for NTFS records cannot walk ReFS trees, so ReFS needs a separate parser.

Attribute	NTFS	ReFS
Metadata structure	Master File Table (MFT): flat record array at a fixed offset	B+ trees: hierarchical, self-balancing, rooted in the object table
Update model	In-place updates with journaling ($LogFile)	Allocate-on-write for metadata; old pages preserved until space reclaimed
Checksums	None (relies on hardware or Storage Spaces for integrity)	CRC-64 on metadata pages; optional CRC-64 on data blocks (integrity streams)
Recovery advantage	MFT backup ($MFTMirr) provides a partial copy of the first MFT records	Historical checkpoints from AoW; dual checkpoint areas; B+ tree page scanning
Max volume size	256 TB (practical)	35 PB (practical, Windows-supported); designed for hyper-converged multi-petabyte storage

Most data recovery software and even many professional recovery labs do not support ReFS parsing. The tools that handle NTFS MFT reconstruction cannot parse ReFS B+ trees. This is why ReFS recovery is a specialized service.

Storage Spaces Direct06/14

Storage Spaces Direct S2D Recovery

S2D pools local drives from multiple cluster nodes into one software-defined layer with ReFS on top. When quorum is lost or too many nodes drop at once, the cluster shared volumes go offline while the data stays on the physical drives. We image every member, then reconstruct the pool geometry and ReFS volumes from the images.

Image every surviving member write-blocked before allowing any S2D rebuild to start. Reading parity slabs across the remaining members during a rebuild exposes the array to an unrecoverable read error: consumer-class drives are rated near one URE per 10^14 bits read, roughly 12.5 TB, so a degraded multi-terabyte pool is likely to hit one mid-rebuild and drop the operation.

SMR drives in the capacity tier add a second hazard; they stall during the sustained sequential writes a rebuild generates, the controller reads the 30-to-60 second pause as a dead drive, and the member gets ejected, which can cascade into pool collapse. We image the members first so the rebuild runs against copies, never the originals.

Storage Spaces Direct is Microsoft's hyper-converged infrastructure (HCI) solution. It pools local storage from multiple cluster nodes into a single software-defined storage layer. ReFS is the recommended filesystem for S2D cluster shared volumes (CSVs) in production configurations.

S2D Pool Geometry

S2D creates a storage pool from all eligible drives across cluster nodes. The pool is divided into slabs, and data is distributed across nodes according to the resiliency type (mirror, parity, or mirror-accelerated parity).

Each node stores a copy of the pool metadata database in a hidden partition on every pool drive. This metadata database describes the slab-to-node mapping, virtual disk layout, and resiliency configuration. Recovery starts by reading this metadata from each node's drives to reconstruct the virtual disk geometry.

Cluster Quorum Failure

A three-node S2D cluster requires at least two nodes to maintain quorum. If two nodes fail simultaneously (power event, network partition, cascading hardware failure), the cluster loses quorum and all CSVs go offline.

The data is intact on the physical drives, but the cluster refuses to bring the storage online without quorum. We bypass the cluster layer entirely: image all drives from all nodes, reconstruct the pool metadata, assemble the virtual disks from the raw images, and parse the ReFS volumes directly.

Cache Tier and Capacity Tier

S2D uses a tiered storage model: NVMe or SSD drives serve as a cache tier, and HDDs serve as the capacity tier. Data is destaged from cache to capacity asynchronously. If a node fails during destaging, some data exists only in the cache tier on that node's SSDs. Recovery must account for both tiers: we image cache-tier SSDs and capacity-tier HDDs from every node, then reconstruct the complete virtual disk including data that had not yet been destaged.

Methodology07/14

Recovery Methodology

Image every drive write-blocked. Every drive in the server or S2D cluster is imaged through PC-3000 with write-blocking; slow or unstable members are imaged on DeepSpar Disk Imager so a timing-out drive does not stall the read. SAS drives (standard in Dell PowerEdge and HP ProLiant servers) are imaged via SAS HBAs. NVMe cache-tier drives are imaged through NVMe-to-PCIe adapters. For drives with bad sectors, we capture healthy sectors first using head maps, then retry damaged areas with aggressive read parameters. This stage produces a sector image of each member and touches no original drive after the copy.
Reconstruct the storage pool in software. For Storage Spaces or S2D configurations, array-aware forensic software parses the Storage Spaces metadata database from the hidden partition on each pool drive image. This database describes the virtual disk layout: which slabs on which physical drives compose each virtual disk, and what resiliency type (mirror, parity) protects each virtual disk. We reassemble the virtual disks virtually from the raw drive images using the parsed metadata, never against the live members.
Parse the ReFS B+ trees. With the virtual disk (or raw volume for non-pooled configurations) assembled from the images, we parse the ReFS metadata. First, read the two checkpoint areas at fixed offsets. If a valid checkpoint exists, follow the root pointer to the object table B+ tree. If both checkpoints are damaged, scan the volume for B+ tree page signatures (magic number + page header structure) and rebuild the object table from discovered pages, sorted by page sequence number to select the most recent consistent set.
Extract files and verify checksums. Directory entries are resolved from the directory B+ trees. File data extents are mapped from the file extent B+ trees through the container table. Files are extracted to target media with full path preservation. For volumes with integrity streams, we verify each block's CRC-64 checksum during extraction and flag any blocks with checksum mismatches.

Server Build Differences08/14

Does ReFS Recovery Differ Across Windows Server 2016, 2019, and 2022?

The forensic core is the same across builds: ReFS uses metadata checksums (integrity streams) to detect corruption and writes metadata allocate-on-write, so historical pages survive on disk. What changes is the on-disk format version and which features (ReFS deduplication, mirror-accelerated parity) are layered on top.

Microsoft documents that ReFS detects corruption through integrity streams that checksum metadata, and that allocate-on-write writes updated metadata to new disk locations rather than overwriting the old pages. Those two properties hold on Server 2016, 2019, and 2022, and they are what make offline ReFS recovery possible at all: the historical metadata pages are still on the platter until the container space is reclaimed.

The integrity-stream and allocate-on-write behavior is documented; the ability to roll back to a prior consistent set of those pages is our lab's independent forensic work parsing the raw image, not a native ReFS rollback command.

Server 2016

Shipped ReFS 3.x with block cloning and integrity streams. No in-box ReFS deduplication. Recovery parses the object table, checkpoint areas, and container table the same way; we read the two checkpoint areas, follow the root pointer, and fall back to B+ tree page scanning by sequence number when both checkpoints are damaged.

Server 2019 LTSC

First LTSC build to include ReFS Data Deduplication and tighter Storage Spaces Direct tiering integration. A 2019 volume can carry a chunk store under System Volume Information, so recovery is two-pass: parse the ReFS B+ trees, then resolve reparse points into the chunk store containers. A 2016-only ReFS parser misses the dedup layer.

Server 2022 / 2025

Newer 3.x on-disk format revisions and broader mirror-accelerated parity use on S2D. A parser built only for an older ReFS revision cannot walk these trees; the page header and container layout changed across versions. We detect the format version from the volume superblock structures before selecting the parse path.

The practical recovery consequence is the parse path, not the principle. We identify the on-disk format revision from the volume structures, then walk the object table and container table for that revision. Allocate-on-write and metadata checksums give us the same historical-page recovery surface on every build; the dedup chunk store and the resiliency layout are what we add or drop depending on which Server version wrote the volume.

Pool Metadata Reconstruction09/14

How Do You Reconstruct S2D Virtual Disks When the Storage Pool Metadata Is Partially Corrupt?

Storage Spaces keeps its pool metadata database in a hidden partition on every pool drive, so the slab-to-virtual-disk geometry is replicated across members. When one copy is corrupt, we parse the surviving copies from the drive images and rebuild the geometry. The original controller is not required.

Image every surviving member write-blocked before any rebuild. A degraded parity space has to read parity slabs across the remaining members, and consumer-class drives are rated near one unrecoverable read error per 10^14 bits read, roughly 12.5 TB. On a multi-terabyte pool a degraded rebuild is likely to hit a URE mid-pass and abort, so we image first and let the reconstruction run against the copies.

SMR capacity-tier members add the second hazard: the sustained sequential writes of a rebuild fill their CMR cache zone, the 30-to-60 second reshingling pause reads as a dead drive, and the member is ejected, which can cascade the pool offline.

The pool metadata database describes the slab-to-virtual-disk mapping, the resiliency type per virtual disk, and the column and interleave layout. Because Storage Spaces writes that database to a hidden partition on each pool drive, partial corruption on one member rarely destroys the geometry: the same descriptors usually survive on the other members. We image each drive with PC-3000 hardware (DeepSpar Disk Imager for slow or unstable members), then parse the metadata partitions from the images.

Read every surviving metadata copy. Parse the hidden pool-metadata partition from each drive image and cross-check the slab maps, virtual-disk records, and resiliency descriptors across members to identify which copies are internally consistent.
Rebuild the slab-to-virtual-disk geometry. Reconstruct which slabs on which physical drives compose each virtual disk, the column count, interleave size, and parity layout, using the consistent metadata copies to fill gaps left by the corrupt copy.
Assemble the virtual disks in software. We reassemble the virtual disks with Data Extractor Express RAID Edition (the ACE Lab RAID/array tool that runs on the PC-3000 Express) from the raw drive images, never the live members. The original Storage Spaces controller or HBA is not needed; the geometry lives on the disks, not in the card.
Parse ReFS from the assembled virtual disk. With the virtual disk assembled from images, parse the ReFS checkpoint areas and object table B+ tree as for any ReFS volume, falling back to B+ tree page scanning by sequence number when the checkpoints are damaged.

NVMe Cache Tier10/14

What Happens When an NVMe S2D Cache Drive Drops Off the Bus Mid-Destage?

S2D destages writes from the NVMe cache tier to the capacity HDDs asynchronously. If the NVMe member drops off the PCIe bus mid-destage, uncommitted writes including in-flight ReFS metadata are lost, leaving incomplete B+ tree writes on the capacity tier. We image both tiers and select the most recent consistent set of metadata pages.

The cache tier absorbs incoming writes and destages them to the capacity HDDs in the background. When an NVMe cache member disappears from the PCIe bus during a destage, the writes that were still in flight, including ReFS metadata updates, never reach the capacity tier.

The result on the capacity HDDs is a partial set of B+ tree writes: some metadata pages reflect the newest transaction, others stop one or more transactions behind. This is exactly the situation allocate-on-write is built to survive, because the prior consistent pages were not overwritten.

Image the NVMe cache member. We image the NVMe SSD with PC-3000 SSD in sector-imaging mode through an NVMe-to-PCIe adapter, capturing whatever the device still returns. This is a read-only sector copy, not a controller-level repair.
Image the capacity HDDs. Capacity-tier HDDs are imaged with PC-3000 hardware, and slow or unstable members are imaged on DeepSpar Disk Imager so a timing-out drive does not stall the read.
Reassemble the virtual disk in software. We reconstruct the S2D virtual disk from the raw images with Data Extractor Express RAID Edition, applying any cache-tier writes that did complete before the drop, then hand the assembled volume to the ReFS parser.
Select the consistent metadata generation. We parse the ReFS object table and container table, compare B+ tree page sequence numbers, and select the most recent consistent set of metadata pages, discarding the half-written pages from the interrupted destage rather than trusting a torn newest write.

Imaging and reconstruction are separate stages here. PC-3000 SSD and DeepSpar read sectors off the members; the virtual-disk reassembly and the ReFS B+ tree parse are software steps run against the image files, never against the live drives. That separation is what lets us choose the last consistent metadata generation instead of inheriting the torn state the live cluster was left in.

Hyper-V VHDX & SQL11/14

Hyper-V VHDX and SQL Database Extraction

Hyper-V VMs and SQL Server databases are files on the ReFS volume: VHDX disk images for virtual machines, .mdf and .ldf files for databases. Once we rebuild the ReFS directory tree, we extract those files, verify their internal structures, and confirm the guest filesystem or database header is intact before handing them back.

VHDX Recovery

Hyper-V stores virtual machine disks as VHDX files on the host ReFS volume. Microsoft recommends ReFS for Hyper-V storage because ReFS block cloning enables instant VM checkpoint creation. After extracting VHDX files from the reconstructed ReFS directory tree, we verify the VHDX header, BAT (block allocation table), and metadata region. If the VHDX is intact, we mount the virtual disk and confirm the guest filesystem (NTFS, ext4, XFS) is accessible. For dynamic VHDX files, we also verify the parent locator chain for differencing disks used by VM checkpoints.

SQL Server Database Extraction

SQL Server databases on ReFS volumes consist of .mdf (primary data) and .ldf (transaction log) files. After extracting these files from the reconstructed ReFS tree, we verify the database header page (page 0) for consistency, check the boot page (page 9) for database metadata, and attempt to bring the database online in a recovery instance. For databases with torn pages (common after a crash), we run DBCC CHECKDB to assess damage scope before attempting repair.

ReFS Deduplication Recovery12/14

ReFS Deduplication Recovery

Windows Server Data Deduplication is a post-process layer that sits beside ReFS, not inside it. Files are written normally, then the dedup service replaces them with reparse points that reference unique chunks held in container files under System Volume Information. Recovery parses those chunk store containers and resolves each reparse point back to its file.

Windows Server version 1709 introduced deduplication support on ReFS volumes, included in the LTSC track starting with Server 2019. Deduplication on ReFS uses a post-process model: files are initially written normally, and the deduplication service runs in the background to identify duplicate chunks, store them in a chunk store, and replace the original file data with reparse points referencing the chunk store.

Chunk store corruption: The chunk store is a set of container files stored in a hidden System Volume Information directory. Each chunk is identified by a hash. If the chunk store containers or the chunk store index are corrupted, deduplicated files become unreadable because the reparse points cannot resolve to valid chunk data.
Reparse point damage: Deduplicated files use NTFS reparse points (even on ReFS) to redirect reads to the chunk store. If the reparse point metadata in a file's B+ tree node is damaged, the file appears as zero-length or fails to open with an I/O error. We reconstruct the reparse point data from the chunk store index by matching file chunk hashes.
Recovery approach: We parse the chunk store containers, rebuild the chunk index, and resolve reparse points for each deduplicated file. Files that were not yet processed by the dedup service retain their original inline data and are recovered normally through the ReFS B+ tree.

The dedup chunk store is its own on-disk subsystem, separate from the ReFS metadata trees. Windows Data Deduplication stores the unique chunks as an organized series of container files inside the hidden System Volume Information folder, and the optimized files on the volume become reparse points that index into those containers.

That separation drives the recovery order: we reconstruct the ReFS volume first, locate the chunk store containers under System Volume Information, then rebuild the chunk-to-reparse-point mapping and resolve each deduplicated file back to its full content.

Files the dedup service had not yet optimized still carry their inline data on the ReFS volume and come back normally through the B+ tree parse, so a partially optimized volume splits into two recovery paths: inline files resolved directly, optimized files resolved through the chunk store. We do not run the dedup chunk store through the ReFS checkpoint logic; it is a Data Deduplication structure, parsed on its own terms.

Chunk store: The on-disk repository that holds the unique data chunks produced by Windows Data Deduplication. It lives as container files in the System Volume Information folder and is a separate subsystem from the ReFS metadata B+ trees.
Reparse point: The pointer the dedup service writes in place of an optimized file's data. Reading the file follows the reparse point into the chunk store; if the reparse data is damaged, the file opens as zero-length or returns an I/O error until the mapping is rebuilt.
Chunk store container: One of the container files that physically stores the deduplicated chunks under System Volume Information. Recovery parses these containers directly from the reconstructed ReFS tree to resolve every chunk a reparse point references.

Pricing13/14

ReFS Recovery Pricing

Same transparent model: per-drive imaging based on each drive's condition, plus a volume reconstruction fee covering ReFS metadata parsing, B+ tree reconstruction, and file extraction. No data recovered means no charge.

Service Tier	Price Range (Per Drive)	Description
Logical / Firmware Imaging	$250-$900	Firmware faults, SMART threshold failures, or filesystem corruption on individual pool members.
Mechanical (Head Swap / Motor)	$1,200-$1,50050% deposit	Donor parts required. SAS drives in enterprise servers require SAS-specific donors.
ReFS Volume Reconstruction	Custom Quoteper volume	ReFS metadata parsing, B+ tree reconstruction, file extraction. Includes Storage Spaces pool assembly if applicable.

No Data = No Charge: If we recover nothing from your ReFS volume, you owe $0. Free evaluation, no obligation.

Before sending drives: do not run chkdsk on the ReFS volume. ReFS does not use NTFS-style chkdsk; running chkdsk can trigger online salvage that discards corrupted data references instead of preserving the historical metadata that allocate-on-write had left on disk.

Faq14/14

ReFS Recovery; Common Questions

My Windows Server shows a ReFS volume as RAW. Can you recover the data?

Yes. A ReFS volume appearing as RAW in Disk Management means Windows cannot parse the ReFS metadata structures. This typically happens when the root B+ tree node is corrupted or the superblock (checkpoint area) is damaged. We image the drives and parse the ReFS metadata offline, using historical checkpoints preserved by ReFS allocate-on-write behavior to reconstruct the directory tree.

Can you recover data from a failed Storage Spaces Direct (S2D) cluster?

Yes. S2D distributes data across cluster nodes using ReFS on virtual disks backed by a storage pool. When cluster quorum is lost or a majority of nodes fail simultaneously, the virtual disks go offline. We image the physical drives from each node, reconstruct the Storage Spaces pool geometry from the metadata database stored in a hidden partition on each pool drive, and parse the ReFS volumes from the reconstructed virtual disks.

Is ReFS recovery different from NTFS recovery?

Fundamentally different. NTFS stores metadata in the Master File Table (MFT), a flat record array at a fixed location on the volume. ReFS stores metadata in B+ trees using an allocate-on-write model. When NTFS metadata corrupts, we parse the MFT directly. When ReFS metadata corrupts, we parse B+ tree nodes and can fall back to historical metadata checkpoints that were never overwritten. Different tools, different data structures, different recovery workflow.

My ReFS volume had integrity streams enabled. Does that help recovery?

Integrity streams add CRC-64 checksums to data blocks, which helps verify recovered data is intact. If the volume was a mirror with integrity streams, ReFS auto-repairs corrupted blocks from the mirror copy during normal operation. For recovery, integrity stream checksums let us confirm which blocks are valid and which are damaged. They do not repair data on their own once the volume is unmountable.

Can you extract Hyper-V virtual machines from a corrupted ReFS volume?

Yes. Hyper-V stores VM disks as VHDX files on the host filesystem. Once we reconstruct the ReFS directory tree, we extract the VHDX files and verify their internal block allocation table and metadata regions. If the VHDX files are intact, we mount them to confirm the guest OS filesystem is accessible. If the VHDX is partially corrupt, we extract what is recoverable from the guest filesystem.

How is ReFS recovery priced?

Per-drive imaging based on each drive's condition, plus a volume reconstruction fee covering ReFS metadata parsing, B+ tree reconstruction, and file extraction. For Storage Spaces Direct clusters with many nodes, the total scales with drive count. If we recover nothing, you pay $0.

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

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.

Validated Clean Zone

Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.

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.

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.

See our clean bench validation data and particle test video

Related services