ReFS (Resilient File System) is a Microsoft file system designed for data integrity, availability and scale, introduced with Windows Server 2012 as a successor to NTFS for specific storage roles. Among Windows storage and file systems, it focuses on detecting and repairing corruption automatically, supporting very large volumes and accelerating virtualization and developer workloads, rather than on the broad feature set that general-purpose volumes need.
ReFS is mainly used on Windows Server for Hyper-V hosts, backup repositories and Storage Spaces Direct, and on Windows 11 as the file system behind Dev Drive. It does not replace NTFS on the system drive of a typical desktop, and an existing NTFS volume cannot be converted to ReFS without reformatting.
How ReFS protects data integrity
ReFS stores its metadata in B+ trees and never overwrites metadata in place. Instead it uses an allocate-on-write approach: changed metadata is written to a new location and pointers are updated only after the write completes, so a power failure cannot leave the structure half updated. This is why ReFS volumes do not need an offline consistency check.
All metadata carries 64-bit checksums, and file data can be protected too when integrity streams are enabled. On every read, ReFS verifies the checksum. If the data is damaged and the volume sits on a mirrored or parity Storage Spaces pool, ReFS reads the good copy, returns it to the application and repairs the bad copy automatically.
On a single disk without redundancy, ReFS can still detect corruption but cannot repair it. In that case it removes the damaged data from the namespace through a process called salvage, keeping the rest of the volume online instead of taking it offline for repair.
Key features and parameters
Beyond integrity, ReFS adds several features that matter in specialized workloads. The table below summarizes them with their practical effect.
| Feature | What it does | Practical effect |
|---|---|---|
| Integrity streams | Checksums on file data, not only metadata | Silent corruption is detected on read |
| Block cloning | Copies data by remapping clusters | Near-instant VHDX merges and file copies |
| Sparse VDL | Zeroes files without writing zeros | Fixed-size virtual disks are created in seconds |
| Mirror-accelerated parity | Combines mirror and parity tiers | Efficient capacity with fast writes |
| Proactive error correction | Scrubber checks data in the background | Corruption is found before it is needed |
| Deduplication and compression | Removes duplicate blocks on newer servers | Lower capacity use for backup data |
Supported cluster sizes are 4 KB and 64 KB. The 4 KB size suits most workloads, while 64 KB clusters are common for large sequential files such as backups and virtual disks. The theoretical maximum volume size is measured in petabytes, well beyond the size of any single Windows volume in typical use.
ReFS compared with NTFS
ReFS is not a superset of NTFS. It deliberately drops several NTFS features to keep the design simpler and more robust, so choosing between them depends on which features the workload requires.
| Capability | ReFS | NTFS |
|---|---|---|
| Data checksums | Yes, with integrity streams | No |
| Automatic repair | Yes, with Storage Spaces redundancy | No, needs chkdsk |
| Boot volume for Windows | Not supported in general use | Yes |
| Encrypting File System | No | Yes |
| Disk quotas | No | Yes |
| BitLocker | Yes | Yes |
| Block cloning | Yes | No |
| Removable media | Not supported | Supported |
NTFS remains the default general-purpose file system for system drives, user data and most applications. ReFS is the better choice when integrity and virtualization performance outweigh the need for features such as EFS, quotas or booting.
Where ReFS is used and how to choose it
ReFS is available for creation on Windows Server and on Windows 11 Pro for Workstations and Enterprise editions, while other client editions can read and write existing ReFS volumes but create them only as Dev Drives. The decision table below summarizes typical choices.
| Workload | Recommended file system | Reason |
|---|---|---|
| Hyper-V virtual machine storage | ReFS | Block cloning speeds checkpoints and merges |
| Backup repository | ReFS with 64 KB clusters | Fast synthetic full backups through cloning |
| Storage Spaces Direct | ReFS | Integrity with automatic repair from copies |
| Developer source and build files | ReFS as a Dev Drive | Better performance for build workloads |
| Windows system drive | NTFS | ReFS boot is not supported in general use |
| General file server with quotas | NTFS | Quotas and EFS require NTFS |
Backup software often relies on block cloning to build synthetic full backups. Instead of copying terabytes of unchanged blocks, the software references existing clusters, which reduces both time and capacity use.
Limitations and common mistakes
The most frequent error is to expect self-healing on a single disk. ReFS repairs data only when a redundant copy exists, so a standalone ReFS volume still requires regular backups.
- ReFS version upgrades are one-way: a volume mounted by a newer Windows release may become unreadable on older releases.
- Integrity streams add overhead for some database workloads, which often manage their own checksums.
- Applications that depend on NTFS features, such as hard-coded short names or transactional NTFS, may fail on ReFS.
- Converting in place is impossible; moving to ReFS means backing up, reformatting and restoring.
In everyday language
ReFS is a way for Windows to organize data on a disk while constantly checking it for damage. Each piece of information carries a small fingerprint, and Windows compares it every time the data is read.
If a fingerprint does not match and a second copy exists on another disk, ReFS quietly fixes the broken copy, like a librarian who replaces a damaged page from a spare edition. The key point is that ReFS shines on servers with redundant disks, while ordinary computers keep using NTFS.
Seen in the real world
A mid-sized hosting provider runs three Hyper-V hosts with Storage Spaces Direct and a three-way mirror formatted as ReFS. The volume holds about 240 virtual machines and receives nightly backups.
During a routine scrub, ReFS detects a corrupted block in a virtual disk caused by a failing SSD. It reads the healthy copy from another node, rewrites the bad block and logs the event, while the virtual machine keeps running without interruption. The administrators replace the SSD the next morning.
The same provider stores backups on a separate ReFS volume with 64 KB clusters. Because block cloning lets the backup software assemble weekly synthetic full backups from existing blocks, the weekly job finishes in about one hour instead of most of the night.