Context
ZFS scrub and resilver both examine storage, but they answer different operational questions. A scrub verifies allocated data against checksums and repairs damage where a valid redundant copy is available. A resilver reconstructs data needed by a replacement or returning device. Neither is a substitute for an independently recoverable backup.
Start with pool identity and status
Record pool name, topology, device identities, redundancy, current state, error counts, active scan, and recent device changes. Use stable device identity rather than assuming a path such as /dev/sdb always refers to the same physical disk.
Read the installed OpenZFS documentation and feature support before using advanced scan options. A flag in newer upstream documentation may not exist in the distribution's deployed version. Basic status evidence is more useful than a command that was never compatible with the actual host.
Understand detection and repair separately
Checksums let ZFS detect that a block differs from its expected contents. Repair requires an appropriate valid copy. A nonredundant pool can detect corruption without being able to reconstruct the lost data.
A mirror or RAIDZ layout improves opportunities for repair, but it does not mean every combination of failures is recoverable. Inspect the actual topology and affected devices. Several unreadable copies of the same block can leave an unrecoverable error even when the pool still serves other data.
Distinguish corrected read problems from permanent data errors. Preserve zpool status evidence before clearing historical counters. A reset counter is not evidence that the underlying cable, controller, drive, or media problem has been corrected.
Plan scan work around degraded capacity
A scrub can reveal latent problems before a later device failure removes redundancy. A resilver restores the intended replica or parity coverage after an appropriate device operation. Both consume I/O and should be observed alongside application latency and device health.
When a pool is degraded, identify the failed component and supported replacement procedure before starting unrelated maintenance. Confirm backups and recovery access. Replacing the wrong similarly named device can reduce the remaining protection.
Do not infer a completion deadline from the first progress estimate. Scan speed changes with workload, data layout, and device behavior. Track progress, errors, and useful application work over time, and escalate a stalled or repeatedly failing operation using the captured evidence.
An illustrative checksum investigation
A monthly scrub reports corrected checksum errors on one member of a mirror. The application reads normally, so the team considers the problem harmless. Subsequent evidence shows the same device path accumulating errors during ordinary activity.
The storage owner preserves status and hardware evidence, identifies the underlying component, and follows a controlled replacement procedure. A later scan and application validation support the repair. The original corrected blocks were evidence that redundancy helped, not proof that the hardware no longer required attention.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Corrected checksum errors | Redundancy supplied valid data | Device and path error trend |
| Permanent errors reported | Some data lacks a valid copy | Affected files and backup recovery |
| Resilver active after replacement | Redundancy being reconstructed | Progress and remaining device health |
| Scrub completes without new errors | Checked allocation passed this scan | Ongoing monitoring and restore test |
A focused operator exercise
Build a disposable redundant pool with known test files and independently recorded checksums. Exercise the supported device-replacement process and observe resilver state. Run a scrub afterward and compare status and application data with the initial manifest.
Rehearse restoration of one file from an independent backup, including access to required encryption keys. Record what the scan established and what the restore established. Avoid deliberately corrupting production devices to demonstrate detection, and do not treat a lab's recovery speed as a guarantee for a larger live pool.
Maintain evidence and recovery together
Schedule scans according to workload and support guidance, and alert on degraded state, new errors, and overdue accepted scans. Keep hardware mapping and replacement ownership current. Document how backups recover deletion or harmful application changes that redundant storage may faithfully preserve.
Frequently asked questions
Can a scrub repair every checksum error?
Only when an appropriate valid copy is available. Detection and repair are separate capabilities.
Does a successful resilver prove our backup is usable?
No. It establishes a storage reconstruction result. Verify independent backup access and an actual restore separately.
Continue the investigation
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix NAS, SAN & File Server Infrastructure to discuss implementation, validation and operational handover.