ReFS File System Data Recovery

You chose ReFS for a reason. The Resilient File System was Microsoft’s answer to NTFS’s vulnerabilities — automatic integrity checksums, self-healing on Storage Spaces mirrors, copy-on-write metadata updates, immunity to the corruption modes that have haunted NTFS for thirty years. It was supposed to be the file system you didn’t have to worry about.

And then the volume came up RAW.

Or PowerShell told you “the volume repair was not successful.” Or refsutil salvage returned “No valid superblock.” Or your Hyper-V cluster lost a host and the VHDX files were gone. Or you ran a recovery utility that errored out partway through a 25TB scan. Or one of your administrators deleted the wrong iSCSI target file and tens of terabytes of production data vanished.

This page is for the IT pro who trusted ReFS and is now learning, the hard way, that “resilient” does not mean “invulnerable.” Microsoft Support has run out of suggestions. The repair commands have failed. Consumer recovery software couldn’t finish the scan, or finished it and produced unusable garbage. Now you need someone who actually recovers data from failed ReFS volumes for a living.

The ReFS Failure Scenarios We Actually See

ReFS is more fault-tolerant than NTFS — until it isn’t. When ReFS does fail, it tends to fail differently than NTFS, in ways that the standard Microsoft toolchain often can’t recover. The scenarios we see most often:

Storage Spaces pool corruption

ReFS on top of Storage Spaces is one of the most common failure patterns we work on. A pool that operated normally for years — sometimes through multiple Windows updates and reboots — suddenly comes up with the volume showing as RAW in Disk Management. The drive letter still appears, but the volume is inaccessible. Event Viewer logs entries like “The file system detected a checksum error and was not able to correct it” and “Volume X: is formatted as ReFS but ReFS is unable to mount it.”

Customers often report this happens after a reboot, an unexpected shutdown, a Windows feature update, or sometimes for no apparent reason at all. The pool’s individual drives are reported healthy. Storage Spaces sees the pool. ReFS just can’t mount the volume on top of it.

“The volume repair was not successful”

You ran Repair-Volume -DriveLetter X -OfflineScanAndFix in PowerShell, hoping ReFS could repair itself. PowerShell came back with “The volume repair was not successful.” You tried Repair-Volume -Scan. Same result. You may have tried refsutil salvage in its various forms (with -D for diagnose, -QS for quick scan, full salvage with -x). One of them errored out with “No valid superblock,” “data integrity checksum error,” or “The file system structure on the disk is corrupt and unusable.”

At this point, Microsoft’s official toolchain has signaled that it can’t help. ReFS volumes, unlike NTFS, can’t be chkdsk-ed — the standard “well, let’s run chkdsk and see what happens” path is closed. Most people we hear from at this stage have spent hours or days exhausting every Microsoft-provided option before searching for a recovery service.

Hyper-V VHDX files vanished from ReFS volumes

The Hyper-V on ReFS combination was Microsoft’s recommended configuration for years — ReFS’s block cloning made checkpoint operations dramatically faster, and Hyper-V was a primary marketing case for ReFS adoption. Then the ReFS volume hosting the VHDX files corrupted, or an administrator deleted the wrong directory, or a script malfunction removed VHDX files that were supposed to be archived.

The Hyper-V error message in this scenario: “The absolute path is valid for the Hard Disk Image pool, but references a file that does not exist.” The virtual machines won’t start because their disks are gone. If those VHDX files held production workloads — domain controllers, SQL Server, Exchange, business-critical applications — the problem just became an emergency.

iSCSI target files deleted (accidentally or otherwise)

On a Windows Server hosting iSCSI targets, the target itself is a file on the host file system — typically a .vhd or .vhdx sitting on an ReFS volume. To the host server, it’s just a large file. To the client systems consuming the iSCSI target, it’s an entire disk volume.

When that file gets deleted — by an administrator who didn’t realize what they were deleting, by a malicious actor, by a script gone wrong, by a “cleanup” of “old” files — every client connected to that iSCSI target loses its disk. The hosting ReFS volume itself is fine. The single file that contained terabytes of data is gone.

Deleted Storage Spaces virtual disks

An administrator opens Server Manager or PowerShell, intending to manage a different virtual disk, and removes the wrong one. The Storage Spaces virtual disk that held a critical ReFS volume is destroyed. The underlying physical drives still hold the data — Storage Spaces deletion doesn’t wipe drive contents — but the metadata that tells Windows how to reassemble the virtual disk is gone.

This is one of the most painful scenarios we work on because it’s almost always entirely preventable, but once it’s happened, recovery requires reconstructing the Storage Spaces layout from the surviving metadata on the physical drives.

“ReFS volume not accessible” after unexpected restart

A power event, a forced reboot during heavy I/O, a Windows update that didn’t go cleanly — and the next time the system comes up, the ReFS volume isn’t accessible. Right-clicking shows “the volume repair was not successful.” Disk Management may show the volume as RAW, or may show it as ReFS with a question mark over its status.

The ReFS integrity stream is supposed to prevent this. When it doesn’t, the resulting failure mode is often worse than NTFS would produce in the same scenario, because the standard NTFS recovery toolchain doesn’t work on ReFS.

Veeam Backup repository on ReFS won’t mount

ReFS block cloning was Veeam’s selling point for the ReFS-on-Storage-Spaces configuration — synthetic fulls and forever-forward incremental backups were dramatically faster on ReFS than NTFS. When the backup repository’s ReFS volume fails, multiple weeks or months of backup data become inaccessible at exactly the moment you might need them most.

Drives reporting healthy but ReFS won’t mount

Every drive in the Storage Spaces pool reports healthy in SMART. The pool shows healthy in Storage Spaces. ReFS still won’t mount the volume on top of them. This is the scenario where customers are most confused — because everything Microsoft’s diagnostics report is normal, but the data is still inaccessible.

Why Standard ReFS Recovery Tools Often Fail

If you’ve tried to recover an ReFS volume yourself, you’ve probably noticed something: the tooling is dramatically worse than what exists for NTFS. There are reasons for that.

ReFS isn’t chkdsk-able. By design. Microsoft’s position is that ReFS’s integrity streams and self-healing make chkdsk unnecessary. When the integrity streams fail (and they do), there’s no equivalent repair tool — only refsutil salvage, which is more of a data-extraction utility than a repair tool, and which fails outright on many real-world corruption scenarios.

The on-disk format is less documented than NTFS. Microsoft has never published the ReFS on-disk format. Third-party recovery tool developers have had to reverse-engineer it from observation, and even after years of work, the major commercial recovery tools handle ReFS less completely than they handle NTFS. The “ReFS support” advertised by consumer recovery software is often partial — it can find some files but rarely reconstructs the full directory structure or recovers file metadata accurately.

ReFS volumes are usually huge. The customer running ReFS chose it because they had a lot of data — multi-terabyte volumes are typical, double-digit terabytes are common. Consumer recovery software that “supports ReFS” often fails partway through scanning a large volume, or completes a scan and produces a flat dump of recovered files with no useful directory structure. The Microsoft Q&A thread you may have read where someone tried to recover a 25TB ReFS pool with R-Studio gives you a sense of what this looks like in practice.

Storage Spaces adds a second layer of complexity. When ReFS is sitting on top of Storage Spaces (which it typically is), recovery requires reconstructing the Storage Spaces layout first — figuring out the slab layout, the resiliency tier, the column count, the interleave — before the ReFS volume can even be examined. Most recovery tools handle either ReFS or Storage Spaces, not both together.

What Causes ReFS Volumes to Fail

ReFS was designed to be resilient to scenarios that destroy NTFS volumes — silent corruption, partial writes, single-disk failures in a redundant pool. The failure modes we see, in our actual case data:

Hardware failure that exceeds ReFS’s resilience design. ReFS on a two-way Storage Spaces mirror can tolerate one drive failure. ReFS on a parity pool can tolerate one drive’s worth of failure. When multiple drives fail, or when one drive’s failure pattern affects the wrong sectors at the wrong time, ReFS’s resilience runs out. The integrity streams report errors. The volume goes RAW. Microsoft’s tools can’t recover it.

Power events affecting multiple drives simultaneously. A power surge, lightning strike, or UPS failure can affect all the drives in a Storage Spaces pool at the same time — bypassing the resilience that’s predicated on independent drive failures. ReFS may detect inconsistencies in the integrity checks across multiple drives and report the volume as corrupt rather than risk presenting inconsistent data.

Firmware updates or controller changes. Updating storage controller firmware, replacing a host bus adapter, or changing how drives are presented to Windows can produce situations where Storage Spaces sees its drives but doesn’t recognize the pool correctly. ReFS sitting on top can’t mount what it can’t find.

Windows updates that affect Storage Spaces or ReFS. Multiple Windows Server updates over the years have caused issues for Storage Spaces or ReFS volumes — sometimes immediately, sometimes after subsequent reboots. The integrity stream catches inconsistencies and marks the volume as unmountable to prevent further damage.

Accidental deletion of pool members, virtual disks, or iSCSI target files. Administrators removing the wrong drives from a pool, deleting the wrong virtual disk in Storage Spaces, or deleting the file that backs an iSCSI target. These are recoverable — the data on the underlying drives doesn’t disappear when the configuration is deleted — but recovery requires reconstructing the configuration from what’s left.

Deliberate destruction. Disgruntled employees, departing administrators, or attackers with sufficient privileges can delete virtual disks, drop iSCSI target files, or wipe configuration metadata. These scenarios are recoverable in many cases because the underlying data takes longer to be overwritten than the configuration metadata does to be removed. The window for recovery is short, but it exists.

Bugs and edge cases. ReFS is a complex file system, and complex file systems have bugs. Microsoft has documented and fixed many over the years; some remain. The “ReFS volume unexpectedly RAW after reboot” scenario that appears in many Microsoft forum threads doesn’t have a clean root-cause explanation in every case.

How Professional ReFS Recovery Works

The recovery process for failed ReFS volumes shares the fundamentals of our other recovery work, with ReFS-specific tooling and process applied throughout.

1. Free consultation to scope the case. We need to understand the specific configuration — ReFS on what kind of underlying storage (Storage Spaces, hardware RAID, single disk), what version of Windows Server, what version of ReFS (1.2 vs 3.x, which matters for recovery), what failure mode triggered the issue, and what’s already been tried. This determines the engagement structure and projected scope.

2. Forensic imaging of every drive before any recovery is attempted. Each physical drive in the underlying storage — whether it’s a Storage Spaces pool, a hardware RAID array, or a single disk — is connected through a hardware write-blocker and imaged bit-for-bit. The original drives are never modified. Every subsequent recovery attempt happens against the images, so any attempt that doesn’t succeed can be rolled back without harm to the original media.

3. Reconstruction of the underlying storage layer. For Storage Spaces on ReFS, we reconstruct the Storage Spaces virtual disk layout from the metadata on the surviving drives — slab placement, resiliency configuration, column geometry — to assemble what ReFS was sitting on top of. For ReFS on hardware RAID, we reconstruct the RAID using our proprietary tool Hombre. The output is a logical volume that ReFS can be examined against.

4. ReFS metadata extraction and reconstruction. Our tooling parses the ReFS on-disk structures directly — the B+ trees that hold file system metadata, the integrity streams, the embedded file allocation information. When the standard metadata is damaged, we work from what’s available, supplementing with file-signature-based extraction for files whose metadata records have been lost entirely.

5. File extraction even from incomplete metadata. Where the file allocation tables are intact, we extract files with full original paths and metadata. Where metadata is damaged, we use file signatures (recognizing JPGs, DOCX files, PDFs, VHDX files, SQL databases, and many other formats by their byte patterns) to recover the file content even without the original directory structure.

6. Special handling for VHDX, iSCSI target files, and other container formats. When the ReFS volume held virtual machine disks or iSCSI target files, we don’t just recover those container files — we can also recover data from inside them, parsing the NTFS volumes embedded within the recovered VHDX/VHD files to extract the specific files the customer needs.

7. Data delivered on new media. Recovered data comes back on healthy drives — never back to the source storage, which has demonstrated it can’t be trusted with critical data going forward.

What to Do Right Now If Your ReFS Volume Failed

The path forward depends on how much you’ve already tried.

If you haven’t tried anything yet: stop here. Don’t run refsutil salvage. Don’t run Repair-Volume. Don’t accept any prompts to format or reinitialize the volume. Don’t reboot the system repeatedly hoping the issue clears. ReFS failures rarely resolve themselves, and the standard Microsoft tools often make things worse on a volume that’s beyond their ability to repair.

If you’ve tried Microsoft’s official tools and they failed: you’re in the population we work with most often. The failure of refsutil salvage or Repair-Volume doesn’t mean recovery is impossible — it means recovery requires tooling beyond what Microsoft provides. Stop the experimentation, document what you’ve tried, and contact us before attempting more.

If you’ve tried consumer recovery software: stop running additional tools. Each one stresses the underlying storage further and may overwrite recovery-relevant metadata. Document which tools you ran, what they returned, and whether any of them wrote anything back to the source drives.

If you suspect deliberate deletion of virtual disks or iSCSI target files: time is critical. The underlying data persists longer than the configuration metadata, but only if nothing writes to those sectors. Quiesce I/O to the host immediately — stop services, disable scheduled tasks, prevent users from writing to the volume — and contact us. The window for recovery is hours to days, not weeks.

If drives are showing physical symptoms: If any drives in the Storage Spaces pool are clicking, beeping, grinding, or running unusually hot, power off the system immediately. Mechanical failure compounds rapidly under load, and a drive that arrives at a recovery lab while still partially functional is far more recoverable than one that’s been run until it fully fails.

Document everything you can:

• Windows Server version and edition
• Storage configuration (Storage Spaces, hardware RAID, single disk; resiliency tier; column count if Storage Spaces)
• ReFS version (visible in PowerShell with Get-Volume)
• Approximate volume size and free space at time of failure
• What was happening when the failure was first noticed
• What error messages Windows, ReFS, or Event Viewer reported
• What recovery commands or tools have been run, in what order, with what results
• Whether any drives have shown physical distress signs

The more you can tell us up front, the faster the consultation moves and the more accurately we can scope the work.

ReFS Versions and What They Mean for Recovery

ReFS has gone through multiple revisions, and the version matters for recovery.

ReFS 1.1 and 1.2 — original Windows Server 2012 / 2012 R2 / Windows 8.1 versions. Older systems still in production sometimes run these. Recovery tooling for these versions is mature; the on-disk format is well-understood.

ReFS 3.0, 3.1, 3.2 — Windows Server 2016 and onward. Added block cloning (the feature Veeam adopted aggressively), additional integrity options, and some structural changes. The dominant version we see in failed-volume cases.

ReFS 3.4, 3.5, 3.7 — Windows Server 2019/2022/2025 versions. Recent additions include integrity scrubbing, file system trimming improvements, and various performance optimizations. Recovery for the newest versions sometimes requires Microsoft-specific tooling that may or may not be available depending on the failure mode.

If you don’t know your ReFS version, run Get-Volume | Format-List in PowerShell on the host. The output includes the file system version.

Frequently Asked Questions

Microsoft Support told me my ReFS volume can’t be recovered. Is that true?
Microsoft Support, in our experience, gives accurate guidance about what their tools can recover — which is often limited for ReFS. “Can’t be recovered with Microsoft tools” doesn’t mean “can’t be recovered at all.” A meaningful percentage of our ReFS recovery work involves cases where Microsoft Support told the customer to restore from backup.

I ran refsutil salvage and it failed. Can you still recover the data?
Usually yes. refsutil salvage failing doesn’t mean the data is gone — it means Microsoft’s tool couldn’t extract it given the corruption pattern. Professional recovery uses different tooling that handles failure modes refsutil can’t.

What about ReFS volumes that have been reformatted?
Reformatting destroys the original ReFS metadata but doesn’t immediately overwrite the underlying data. If nothing has been written to the volume since the reformat, recovery of significant data is often possible — though it requires file-signature-based extraction rather than directory-structure-based recovery.

Can you recover an ReFS volume where the Storage Spaces pool was deleted?
Yes, in most cases. Storage Spaces deletion removes the pool’s configuration but doesn’t erase the data on the underlying drives. We reconstruct the pool configuration from the surviving on-disk metadata, then extract the ReFS volume from the reconstructed pool.

What if my ReFS volume held VHDX files for Hyper-V virtual machines?
We recover both the VHDX files themselves and, if needed, individual files from inside them. The VHDX is just a large container file on the ReFS volume; once we recover the container, we can mount it and extract whatever the virtual machine held.

One of my administrators deleted an iSCSI target file. Is that recoverable?
Usually yes, if you act quickly. The file’s data sectors aren’t immediately reused after deletion — they wait until something else needs to write to those sectors. Quiesce writes to the host volume immediately and contact us. The faster we can image the drives, the more recoverable data we’ll find.

How much does ReFS recovery cost?
Every case starts with a free consultation. ReFS recovery is more specialized than typical NTFS work, and the cost scales with the size of the volume, the complexity of the underlying storage layer, and the severity of the corruption. For larger enterprise cases, we provide a clear upfront quote based on projected engineering hours, machine hours, and data transfer time. We never bill for cases we can’t solve.

What about ReFS on Windows 11 (not Windows Server)?
Microsoft has been testing ReFS as an option on Windows 11 Insider builds and may eventually offer it for desktop use. We can recover from any ReFS volume regardless of the host operating system version — the file system structure is what matters, not whether it’s running on Windows Server or Windows 11.

Should I switch back to NTFS after this experience?
That’s a decision for your team to make based on your reliability requirements. ReFS still offers meaningful advantages for the workloads it was designed for. The lesson from a recovery situation isn’t necessarily “ReFS bad” — it’s “even resilient file systems need backups.” We see customers continue using ReFS after recovery, just with more robust backup strategies than they had before.

The Bottom Line

ReFS is genuinely more resilient than NTFS in most scenarios. When it does fail, it fails in ways that the standard Microsoft toolchain often can’t recover from — and that consumer recovery software handles poorly. The result is an unusually large gap between “Microsoft’s tools failed” and “the data is actually unrecoverable.” Most cases we work on fall into that gap.

If your ReFS volume has failed, your administrators have exhausted their options, and the data matters, we offer a free consultation to walk through your specific situation and tell you honestly what’s possible.