A NAS can remain accessible even when zpool status begins to report read or checksum errors. Before concluding that a disk is dead, run a scrub on the good pool. This check reads the blocks from the pool and verifies their checksums.
On a server that hosts VMs, backups, or shares, I would choose a quiet I/O window. A scrub engages the disks, and ZFS refuses to perform one at the same time as a resilver. The goal is to ascertain whether the pool remains healthy, not to issue a command to make an alert disappear.
Before the scrub, confirm the pool name
Start by checking the current status. Do not invent the pool name from a mount or a disk seen in lsblk. The command zpool list provides the imported pools, then zpool status -v displays their status and known errors.
sudo zpool list
sudo zpool status -v tankReplace tank with the name returned by your machine. In the output, look at the line scan, the overall state of the pool, and the READ, WRITE, and CKSUM counters of the vdevs. The -v variant can also list the affected files when ZFS knows their path.
A pool already in resilver reconstructs an added or replaced disk. Wait for this operation before requesting a scrub: OpenZFS allows only one operation of this type at a time. If the disks are serving a database or highly demanding VMs, postpone the check rather than create an I/O saturation during the day.
Start the scrub during a quiet period
The following command starts a normal scrub on tank:
sudo zpool scrub tankThe scrub goes through the data and checks the checksums. On a mirror, a RAIDZ, or a dRAID, ZFS can repair damaged blocks if it has a valid copy. An isolated disk or corruption without a replica remains an incident to be handled with a backup or hardware replacement.
The command returns almost immediately. This is normal: the work continues in the background. If the load becomes cumbersome, OpenZFS allows you to pause the scrub and resume it later with the same command.
sudo zpool scrub -p tank
sudo zpool scrub tankAvoid zpool scrub -a for an initial check. This option starts, pauses, or stops the operation on all pools and can heavily load a machine that hosts several.
Monitor progress and read errors
Restart zpool status during the scrub:
sudo zpool status tank
sudo zpool status -v tankThe line scan indicates the start of the operation, the volume scanned, the progress, the speed, and a remaining estimate. Progress greater than 100% may appear on an active pool, as data changes during reading.
At the end, recheck the disk counters and the detailed list. A clean result looks like a scrub finished with 0 errors. Repaired errors still deserve a check of the disk history, cables, and controller. Kernel messages are often helpful at this stage: the guide dmesg on Linux shows how to isolate storage warnings.
- Increasing READ or WRITE: check the disk, cable, and controller before another heavy operation.
- Increasing CKSUM: look for a transfer or read error, even if ZFS has repaired the blocks thanks to a healthy copy.
- Files listed after the scrub: restore them from a verified backup, then replace the faulty hardware if errors persist.
After a permanent error, go beyond simple checks
A scrub validates the observable integrity of the pool at a given moment. It does not replace an off-NAS backup, and it does not turn an unstable disk into a reliable disk. If zpool status -v tank continues to list errors after the scan is complete, first copy the still-readable data to a healthy destination.
The documentation OpenZFS on zpool scrub states that checksum checks go through all blocks and that automatic repairs require a valid redundant copy. For a pool without redundancy, the reasonable decision remains to restore from a backup and replace the faulty medium.