Understanding zpool scrub and Data Integrity in Linux

The zpool scrub operation is an essential maintenance task within OpenZFS on Linux, serving as the primary defense against silent data corruption, bit rot, and undetected drive degradation. This article details the mechanics of the scrub command, explains how it leverages checksumming and pool redundancy to verify and repair stored data, and outlines best practices for running scrubs to guarantee long-term data reliability without degrading system performance.

What Is a zpool scrub?

A scrub is a proactive background verification process that reads every active data block, snapshot, and piece of metadata across a ZFS storage pool. Unlike traditional filesystem check utilities (such as fsck), which only inspect filesystem metadata while the pool is offline, zpool scrub operates entirely online while reads and writes continue normally.

Protection Against Silent Data Corruption

Storage media inevitably suffers from bit rot—phenomena such as magnetic degradation, cosmic rays, firmware bugs, or controller faults that alter data bits on disk without triggering an input/output (I/O) error. Traditional Linux filesystems (like ext4 or XFS) trust that the underlying hardware will report read errors. When a drive returns corrupted bits without reporting an error, standard filesystems pass that bad data to applications undetected.

ZFS bypasses hardware trust through end-to-end cryptographic checksums. Every block written to a pool has its checksum stored in its parent block pointer. During a zpool scrub, the system:

1. Reads every allocated block from the physical drives.
2. Recomputes the checksum of the data read.
3. Compares the result against the expected checksum recorded in the parent block.

Automatic Self-Healing

Detecting corruption is only the first stage of the process. If a pool is configured with redundancy—such as mirrored drives (RAID-1 style) or RAIDZ arrays (RAID-5/6 equivalent)—zpool scrub automatically repairs the damaged data.

When a checksum mismatch is detected on a specific drive, ZFS issues a read to the redundant mirror or calculates the correct data using the parity blocks in a RAIDZ configuration. Once the pristine copy is retrieved, ZFS writes the correct data back to the disk containing the corrupted block. This self-healing process occurs without administrator intervention, ensuring that minor bit-flips do not accumulate into unrecoverable array failures over time.

Scrubbing vs. Resilvering

While both operations verify and repair data, their triggers and scopes differ:

• Resilver: Initiated automatically when a faulted drive is replaced. It focuses on copying and calculating data needed to bring the newly added drive up to parity with the rest of the pool.
• Scrub: Initiated manually or via a scheduled timer across all existing, healthy drives. It validates all current data across the entire pool, ensuring that latent read errors are not hiding in rarely accessed cold storage.

Scheduling Best Practices

Running a scrub generates substantial read I/O across all disks. However, ZFS assigns scrub operations a lower scheduling priority than real-time application I/O, minimizing the impact on active workloads.

For standard Linux production environments, recommended scheduling includes:

• Enterprise-grade SAS/SATA/NVMe drives: Run zpool scrub once a month.
• Consumer-grade drives: Run zpool scrub once every one to two weeks.

Most modern Linux distributions running OpenZFS automatically install systemd timers or cron scripts (often located in /etc/cron.d/zfsutils-linux) that automate monthly scrubs for all discovered pools. System administrators should monitor pool health after scrubs complete by regularly inspecting the output of zpool status.