ReFS (Resilient File System)

The Wikipedia ReFS documentation captures the project’s identity: “Resilient File System (ReFS), codenamed ‘Protogon’, is a Microsoft proprietary file system introduced with Windows Server 2012 with the intent of becoming the ‘next generation’ file system after NTFS. ReFS was designed to overcome problems that had become significant over the years since NTFS was conceived, relating to changes in data storage requirements.”¹ The “Protogon” codename predates the public ReFS branding and occasionally appears in older Microsoft engineering materials.

The Microsoft design goals

The Microsoft Learn ReFS overview states the design objectives: ReFS “is a modern file system developed by Microsoft to maximize data availability, scale efficiently to large data sets across diverse workloads, and provide data integrity with resiliency to corruption.”² These three goals (availability, scale, integrity) reflect specific gaps in NTFS that grew more significant as storage requirements evolved:

• Availability: NTFS volumes can require offline chkdsk for repair, producing downtime on large volumes.
• Scale: NTFS has architectural limits that don’t fit petabyte-scale enterprise deployments.
• Integrity: NTFS verifies metadata via $LogFile but doesn’t checksum file data; silent corruption is undetected.

The version progression

ReFS has shipped in increasing capability across multiple Windows Server releases:

• Windows Server 2012 / 2012 R2: initial release with basic resilience features and Storage Spaces integration.
• Windows Server 2016: ReFS 3.x introduced; significant enhancements for Hyper-V and backup workloads.
• Windows Server 2019: ReFS 3.4 with block cloning for efficient virtual disk operations.
• Windows Server 2022: further reliability and performance improvements.
• Windows Server 2025: latest release with continued enhancements.
• Windows 11 / Windows 10 Pro for Workstations: ReFS support exists but is limited compared to Server editions.

The NTFS-foundation framing

The Microsoft B8 blog (the original “Building the next generation file system for Windows” announcement) captures the design approach: “ReFS, (which stands for Resilient File System), is built on the foundations of NTFS, so it maintains crucial compatibility while at the same time it has been architected and engineered for a new generation of storage technologies and scenarios. In Windows 8, ReFS will be introduced only as part of Windows Server 8, which is the same approach we have used for each and every file system introduction. Of course at the application level, ReFS stored data will be accessible from clients just as NTFS data would be.”³ The “built on NTFS foundations” framing is important: ReFS isn’t a clean-slate redesign like ZFS; it’s a deliberate evolution that preserves application compatibility.

The “App Compatibility” subset

The Microsoft Compatibility Cookbook captures the explicit design decision: “App Compatibility: To maximize AppCompat, ReFS supports a subset of NTFS features plus Win32 APIs that are widely adopted.” Microsoft chose explicit feature subset compatibility over a clean redesign; applications that work on NTFS work on ReFS for the most common scenarios. The trade-off is that ReFS doesn’t include all NTFS features; the omitted features (file-level compression, file-level encryption via EFS, etc.) reflect explicit choices about what fits ReFS’s workload focus vs what doesn’t.

Position in the file system landscape

ReFS occupies a specific niche in Microsoft’s file system lineup:

• NTFS: default for Windows desktop/laptop, system boot drive, general-purpose use.
• ReFS: Windows Server with Storage Spaces, Hyper-V VM storage, file servers with very large volumes, backup targets.
• FAT32 / exFAT: external/removable media for cross-platform compatibility.
• UDF: optical media.

The positioning reflects Microsoft’s view that no single file system optimally serves all workloads; ReFS was designed for specific server workloads rather than as a universal NTFS replacement.

ReFS’s relationship to NTFS is more nuanced than a simple “successor” framing suggests. Some NTFS features were preserved, others changed, and others removed entirely.⁴

What ReFS inherits from NTFS

The Microsoft B8 blog documents the inherited features: “ReFS inherits the features and semantics from NTFS including BitLocker encryption, access-control lists for security, USN journal, change notifications, symbolic links, junction points, mount points, reparse points, volume snapshots, file IDs, and oplocks.” This 11-feature inheritance list ensures ReFS is genuinely usable in Windows environments:

• BitLocker encryption: volume-level encryption works the same on ReFS as NTFS.
• Access-control lists (ACLs): security descriptors and permission inheritance are identical.
• USN journal: change tracking continues to work for backup tools and indexing services.
• Change notifications: applications watching for file system changes work normally.
• Symbolic links, junction points, mount points, reparse points: the various Windows reparse mechanisms all function.
• Volume snapshots (VSS): Volume Shadow Copy works on ReFS volumes.
• File IDs: the unique identifier mechanism applications use is preserved.
• oplocks: opportunistic locking for file sharing works as expected.

What ReFS adds beyond NTFS

The Microsoft Learn ReFS overview lists ReFS’s distinctive features: integrity streams, Storage Spaces integration, salvaging data, and proactive error correction. Additional features beyond the four flagship items:

• Allocation-on-write metadata: metadata updates use copy-on-write semantics; the on-disk format is always consistent.
• Block cloning: efficient virtual disk operations and incremental backup acceleration.
• Sparse VDL (valid data length): efficient zero-fill for VM disk creation.
• Online repair: chkdsk-equivalent operations happen online; no volume downtime.
• No defragmentation needed: ReFS’s metadata architecture doesn’t require traditional defragmentation.

What ReFS removes from NTFS

Several NTFS features are not present in ReFS:

• File-level compression: NTFS’s per-file compression isn’t supported.
• File-level encryption (EFS): Encrypting File System per-file encryption isn’t available; BitLocker volume-level encryption is.
• Hard links: initially absent; some support added in newer versions but not full NTFS-equivalent.
• Object IDs: not implemented.
• Named streams: alternate data streams aren’t supported.
• Short 8.3 filenames: the legacy DOS-compatible naming isn’t included.
• Sparse files: in some implementations; the support has evolved across versions.
• Quotas: initially absent; partial support added in later versions.

The boot drive limitation

ReFS cannot be used as the Windows boot drive. The system volume must be NTFS; ReFS volumes can be data drives, Hyper-V storage, or backup targets but never the OS install location. This limitation reflects the boot loader’s specific dependencies; the Windows Boot Manager loads from NTFS, and the chain of dependencies through Windows startup hasn’t been ported to ReFS. Practical implication: any Windows system using ReFS will have at least two file systems (NTFS for system, ReFS for data).

The “not a direct replacement” position

The Nakivo ReFS comparison captures the practical positioning: “The 3.4 version of ReFS has advantages in some aspects but is not a direct replacement for NTFS.” The recommended use cases are specific:

• File servers with extra-large volumes and files.
• Volumes storing Hyper-V virtual machines.
• Windows Server deployments rather than Windows workstations.
• Storage Spaces and Storage Spaces Direct integrations.

Integrity streams are ReFS’s central data integrity mechanism. The implementation conceptually parallels ZFS checksums but with Microsoft-specific design choices.

The Microsoft canonical feature description

The Microsoft Learn ReFS overview describes the integrity feature: “Integrity-streams – ReFS uses checksums for metadata and optionally for file data, giving ReFS the ability to reliably detect corruptions. Storage Spaces integration – When used with a mirror or parity space, ReFS can automatically repair detected corruptions using the alternate copy of the data provided by Storage Spaces. Repair processes are both localized to the area of corruption and performed online, requiring no volume downtime. Salvaging data – If a volume becomes corrupted and an alternate copy of the corrupted data doesn’t exist, ReFS removes the corrupt data from the namespace. ReFS keeps the volume online while it handles most non-correctable corruptions, but there are rare cases that require ReFS to take the volume offline.”⁵

The metadata-always vs data-optional design

ReFS’s checksum strategy differs subtly from ZFS:

• Metadata: always checksummed. Every metadata block has a checksum; integrity is non-negotiable for metadata.
• File data: checksummed only for files with the integrity stream attribute set.
• Per-file enablement: the FILE_ATTRIBUTE_INTEGRITY_STREAM attribute can be set on individual files.
• Directory inheritance: setting the integrity property on a directory causes new files to inherit it.
• Default behavior: file data is not checksummed by default; users must explicitly enable it.

This per-file opt-in design differs from ZFS’s checksum-everything default; the rationale is that file data checksumming has measurable performance impact, and Microsoft chose to make it user-configurable rather than universally on.

The data integrity scanner (scrubber)

The Microsoft Compatibility Cookbook describes the proactive verification: “Proactive Error Identification: The integrity capabilities of ReFS are leveraged by a data integrity scanner (a ‘scrubber’) that periodically scans the volume, attempts to identify latent corruption, and then proactively triggers a repair of that corrupt data.”⁶ The scrubber is the ReFS equivalent of ZFS’s zpool scrub:

• Runs periodically in the background.
• Reads metadata and integrity-stream-protected file data.
• Verifies checksums against stored values.
• Triggers repair via Storage Spaces redundancy when corruption is detected.
• Operates online without affecting user workloads significantly.

The auto-correcting read

When ReFS reads data with integrity streams enabled and detects a checksum mismatch:

1. ReFS recognizes the corruption from the checksum failure.
2. If Storage Spaces has redundancy (mirror or parity), ReFS requests the data again.
3. Storage Spaces provides the alternate copy from the redundant location.
4. ReFS verifies the alternate copy’s checksum.
5. If the alternate copy is valid, ReFS returns it to the application.
6. ReFS rewrites the corrupt copy in the original location to repair it.
7. The repair is logged for audit purposes.

The process happens transparently from the application’s perspective; corrupted data is replaced with valid data without the application observing the corruption.

The “salvaging data” semantics

When corruption is detected but no redundant copy is available (no Storage Spaces redundancy, or both copies are corrupt), ReFS uses “salvaging” semantics:

• The corrupt data is removed from the namespace (the file becomes inaccessible).
• The volume remains online.
• Other (non-corrupted) files continue to be accessible.
• An event is logged identifying the lost data.

The salvaging design prioritizes overall volume availability over preserving individual files; a corrupted file is sacrificed rather than risk taking the entire volume offline.

ReFS and Storage Spaces were designed together; the integration is what enables ReFS’s self-healing capability. Understanding the design intent clarifies when ReFS is and isn’t the right choice.

The co-design intent

The Microsoft B8 blog captures the deliberate co-design: ReFS is designed to “Provide a full end-to-end resiliency architecture when used in conjunction with the Storage Spaces feature, which was co-designed and built in conjunction with ReFS.” Storage Spaces is Microsoft’s software-defined storage layer that provides:

• Pool-based storage: aggregating multiple physical disks into pools.
• Virtual disks (Storage Spaces) with resiliency: Simple, Two-way Mirror, Three-way Mirror, Parity.
• Tiering: mixing SSDs and HDDs in the same pool with hot data on SSDs.
• Cluster integration: Storage Spaces Direct for cluster-shared volumes.

Volume management on Storage Spaces is similar in concept to ZFS’s pool architecture; the ReFS-on-Storage-Spaces combination provides analogous capability to ZFS’s integrated pool + file system.

The recommended workloads

The Nakivo ReFS guide lists recommended use cases: “To take advantage of Microsoft ReFS, it is recommended that you use this server file system in the following scenarios: Building a file server with support of extra-large volume size and file size. Creating volumes to store Hyper-V virtual machines. Opt for ReFS on Windows servers rather than on Windows workstations. ReFS is preferred if you use Storage Spaces and Storage Space Direct on your server.”⁷ Specific workload alignment:

• Hyper-V VM storage: block cloning makes VM disk operations efficient; integrity streams protect against silent corruption.
• Backup targets: block cloning accelerates incremental backup operations like Veeam Fast Cloning.
• Storage Spaces / Storage Spaces Direct: the integration provides self-healing.
• Exchange Server 2019 databases and logs: Microsoft recommends ReFS for these specifically.
• File servers with very large volumes: the scalability features benefit large deployments.

The block cloning capability

ReFS 3.4 introduced block cloning, which is similar in concept to Btrfs reflinks. The Nakivo documentation captures the use case: “Windows Server 2019 ReFS includes the block cloning technology. This allows for pointer references to blocks that would otherwise have to be moved around.” Practical applications:

• Hyper-V VM checkpoint creation: instant rather than copy-based.
• Veeam-style backup: incremental backup operations skip data movement.
• VM cloning: new VMs created from templates without data duplication.
• Fast file copy: copy operations on supporting tools use block cloning.

Storage Spaces resiliency types

ReFS works with multiple Storage Spaces resiliency configurations:

• Simple: no redundancy; ReFS can detect corruption but not repair it.
• Two-way Mirror: data stored twice; survives 1 disk failure; ReFS self-heals from the redundant copy.
• Three-way Mirror: data stored three times; survives 2 disk failures; higher resilience.
• Parity: data stored with parity blocks; survives 1 (single parity) or 2 (dual parity) disk failures.
• Mirror-Accelerated Parity: writes to fast mirror tier, then moved to parity tier.

The combination of ReFS integrity streams + Storage Spaces redundancy is what produces the self-healing behavior; without redundancy, ReFS detects but can’t repair corruption.

When NOT to use ReFS

Despite the resilience features, ReFS isn’t always the right choice:

• Boot drives: NTFS is required for the system volume.
• General-purpose desktop/laptop use: the missing features (file compression, EFS) make NTFS better.
• Cross-platform compatibility: ReFS is Windows-only; cross-OS scenarios need NTFS or exFAT.
• Small file servers without Storage Spaces: without redundancy, ReFS’s resilience benefit is limited.
• Workloads needing NTFS-specific features: applications relying on alternate data streams, EFS, or compression need NTFS.

ReFS recovery has its own characteristics that differ from NTFS recovery. The newer file system, narrower deployment, and Server-focused use case all shape the recovery landscape.

What ReFS makes irrelevant

Like ZFS and Btrfs, ReFS’s allocation-on-write design eliminates several traditional concerns:

• Crash recovery: the on-disk format is always consistent; crashes don’t produce corrupted file system metadata.
• Offline chkdsk: ReFS doesn’t need offline volume scanning; repair is online.
• Bit rot for protected files: integrity streams plus Storage Spaces redundancy means silent corruption is detected and repaired automatically.
• Defragmentation: not needed due to the metadata architecture.

ReFSUtil: the Microsoft salvage tool

The Wikipedia ReFS documentation describes the recovery utility: “Microsoft Windows and Windows Server include ReFSUtil, a command-line utility that can be used to diagnose heavily damaged ReFS volumes, identify remaining files, and copy those files to a new location.” ReFSUtil is the official Microsoft tool for severe ReFS recovery scenarios. Specific usage:

• ReFSUtil salvage: identifies recoverable files on a damaged volume and extracts them.
• Runs against the damaged volume in read-only mode.
• Outputs salvaged files to a different volume (NTFS or ReFS).
• Provides logs identifying what was recoverable and what wasn’t.

The third-party recovery gap

Third-party recovery tools have historically had limited ReFS support compared to NTFS:

• Most consumer recovery software handles NTFS extensively but ReFS poorly or not at all.
• Specialized recovery vendors (R-Studio, DMDE, Disk Drill Pro) have varying levels of ReFS support.
• The relatively newer file system and Server-focused deployment limit the development of consumer ReFS recovery tools.
• Volume mounting is often the simplest first attempt; if Windows can mount the volume even with degraded performance, files can typically be copied off normally.

Storage Spaces complications

Recovery from ReFS volumes on Storage Spaces adds layers:

• The Storage Pool must be intact; Storage Spaces metadata damage affects all volumes in the pool.
• Disk failures within the pool’s redundancy are handled automatically by Storage Spaces; ReFS sees a healthy underlying storage layer.
• Disk failures beyond redundancy produce volume failure.
• Imported pools (moved between systems) require Storage Spaces metadata to be intact.

Mounting recovery options

For ReFS volumes that mount but show issues:

• Run the data integrity scanner explicitly via PowerShell (Repair-FileIntegrity).
• Check for Storage Spaces issues if the underlying storage is Storage Spaces.
• Examine the Windows Event Log for ReFS-specific events.
• For non-mounting volumes, ReFSUtil salvage is the primary path.

Backup as primary protection

Given the limited consumer recovery tooling, comprehensive backups are even more important for ReFS than for NTFS. Strategies:

• Volume Shadow Copy (VSS): works on ReFS; provides point-in-time snapshots.
• Native Windows Backup: handles ReFS volumes.
• Veeam Backup & Replication: deeply integrated with ReFS via block cloning.
• System State + File backup: standard Windows Server backup approach.
• Off-site replication: Storage Replica or third-party tools for site-level protection.

For severe scenarios, professional services with Windows Server and ReFS expertise are appropriate; the file system’s specialized workload focus means recovery work is typically server-class. Cleanroom recovery applies for physical drive damage; the ReFS-specific work happens after physical access is restored.