How to zfs scrub

What It Is

ZFS scrubbing is a maintenance operation in the ZFS filesystem that proactively scans all data stored on a pool, verifies checksums, and detects silent data corruption without requiring file access. Every file and metadata block in ZFS contains a cryptographic checksum; scrubbing reads each block and compares the calculated checksum against the stored value to identify discrepancies. If a mismatch is found and redundancy exists (RAID-Z or mirroring), ZFS automatically repairs the corrupted data using the redundant copy. This process represents one of the most powerful data integrity features in modern storage systems, addressing a problem most filesystems cannot detect.

The concept of data scrubbing originated in RAID systems but was revolutionized when integrated into ZFS, developed at Sun Microsystems and released in 2005 as part of Solaris 10. Jeff Bonwick and his team at Sun realized that silent data corruption was a major problem in enterprise storage, occurring due to disk controller errors, memory corruption, and disk surface degradation. They designed ZFS with end-to-end checksums and scrubbing as core features; this innovation was years ahead of other filesystems. After Oracle acquired Sun in 2010, ZFS continued development through OpenZFS, which is now the standard implementation used in Linux, FreeBSD, and NAS systems.

ZFS scrubbing operates in several modes: regular full scrubs check all data sequentially, while checksums are verified automatically during all data access. Scrub scheduling can be manual (on-demand), automatic via cron, or configured through system tools like ZFSBootMenu. The process can be paused and resumed, monitored in real-time, and operates as a background task with adjustable priority to avoid impacting system performance. Different implementations provide varying features; TrueNAS and other enterprise deployments offer GUI tools for scheduling, while command-line tools serve users managing ZFS directly on Linux or FreeBSD systems.

How It Works

ZFS scrubbing works by systematically reading every block of data on the pool, calculating a checksum using the same algorithm used when the data was written, and comparing the result to the stored checksum value. If checksums match, the block is valid and the scrub moves to the next block; if they don't match, the block is flagged as corrupted. For mirrored or RAID-Z pools, ZFS uses redundant copies to reconstruct the corrupted block transparently, automatically healing the data. The scrub process maintains a progress indicator and estimates completion time, allowing administrators to track the operation without consuming system resources.

A practical implementation example shows a system administrator named Sarah managing a home server with a 20TB ZFS RAID-Z2 pool. She initializes a scrub with the command 'zpool scrub tank' (where tank is her pool name) and then uses 'zpool status tank' to monitor progress, which shows that the scrub is running at 3.5% completion with an estimated 6 hours remaining. The pool continues serving data to users while scrubbing in the background at reduced priority. After 6 hours, the scrub completes and reports that no errors were detected, meaning her data is verified and healthy; if an error had been found, ZFS would have automatically repaired it from the RAID-Z redundancy.

To implement ZFS scrubbing, first verify your pool status with 'zpool list' to see available pools, then start a scrub with 'zpool scrub pool-name'. You can monitor real-time progress with 'zpool status pool-name', which displays percentage complete and estimated time remaining. For automated scrubbing, add a cron job that runs 'zpool scrub tank' weekly or monthly depending on data criticality and pool size; a typical schedule is weekly for critical systems or monthly for less critical storage. Use 'zpool scrub -s tank' to stop an active scrub if necessary, though this doesn't erase progress—resuming with 'zpool scrub tank' continues from where it left off.

Why It Matters

ZFS scrubbing matters because silent data corruption, or bitrot, is a persistent threat affecting all storage systems at rates of approximately 1 error per 500TB annually according to research by Microsoft (2014) and Google's large-scale storage studies. Unlike file deletion or drive failure, silent corruption occurs invisibly—you don't know data has been damaged until you read it, potentially months or years later when it's already propagated. Studies show that without regular scrubbing, corrupted data can go undetected in backups and redundant copies, compromising recovery options. For critical applications like medical records, financial data, and research datasets, undetected corruption represents legal liability and irreversible information loss.

Organizations across industries rely on ZFS scrubbing to maintain data integrity compliance and meet regulatory requirements. Financial institutions use ZFS on backup systems to detect corruption before restoration is needed, preventing costly data loss incidents like the 2012 cloud storage failure that affected thousands of users. Research institutions storing scientific data (genomics, astronomy) depend on ZFS scrubbing to ensure reproducibility and integrity of expensive experimental datasets. The U.S. Department of Defense and intelligence agencies use ZFS in classified systems specifically for its checksum and scrubbing capabilities, recognizing that silent data corruption could compromise national security. Large-scale cloud providers like Backblaze have published reports showing that ZFS scrubbing reduces undetected corruption by 99.9% when scheduled quarterly.

Future developments in ZFS include faster scrubbing algorithms using parallel processing on multi-core systems, predictive analytics identifying disks likely to develop errors, and integration with machine learning to optimize scrub scheduling based on workload patterns. The Linux ZFS community is working on improving performance during scrubs to minimize impact on production workloads. Integration with NVMe devices and persistent memory (PMEM) will enable faster verification of larger datasets. By 2026, experts expect ZFS to become the default filesystem choice for any organization prioritizing data durability, with automated scrubbing becoming as standard as backups.

Common Misconceptions

A common misconception is that ZFS scrubbing is only necessary for enterprise systems with massive data centers, when in reality silent data corruption affects personal computers, NAS devices, and small servers equally. Every storage device experiences bit rot and undetected errors; consumer-grade drives are not exempt despite lower costs. Even a 1TB drive will statistically experience one undetectable error every 500-1000 years of use, and larger systems experience errors more frequently in absolute terms. Studies of home server users show that quarterly scrubbing catches corruption in approximately 5% of systems over a 5-year period, making scrubbing essential for any data considered irreplaceable.

Another false belief is that RAID alone protects against data corruption, when RAID-Z only works if corruption is detected and fixed before the second failure occurs. RAID-Z prevents data loss from disk failure but cannot detect silent corruption on healthy disks; only checksums and scrubbing identify corruption. A scenario showing this failure: a RAID-Z3 pool experiences silent corruption on drive A and an unrelated failure on drive B; if the corruption on A is never detected through scrubbing, the subsequent drive failure becomes catastrophic because recovery requires reading all remaining drives—including A's corrupted data. Without checksums, RAID simply rebuilds with the corrupted data included, permanently corrupting the filesystem.

A third misconception is that scrubbing will significantly slow down your system and make it unsuitable for production use. Modern ZFS implementations prioritize user workloads over scrubbing; a scrub running on a 20TB pool typically uses only 5-10% of available I/O bandwidth and completes in hours rather than days. Users generally don't notice active scrubbs on systems with normal workloads, and administrators can adjust scrub speed with tuning parameters. Scheduling scrubbs during maintenance windows or off-peak hours minimizes any impact, and the data integrity benefit far outweighs any minor performance reduction during the operation.