A home NAS filesystem scrub can take a few hours or more than a day, and neither result is automatically abnormal.
The useful question is whether this scrub matches the same pool's normal rate. Used capacity, HDD or SSD speed, pool geometry, error retries, and competing workloads all change the duration, so your own clean runs provide a better baseline than a universal estimate.
What Actually Determines Scrub Time
A scrub verifies allocated data rather than simply counting advertised drive capacity. For ZFS, duration changes with used data and pool performance; a lightly filled pool can finish much sooner than a nearly full pool of the same size.
Drive type, mirror or parity layout, fragmentation, controller bandwidth, and record distribution also matter. A scrub may read every pool block that contains data while yielding I/O priority to active applications.
| Observed pattern | Likely meaning | Best response |
|---|---|---|
| Steady rate, changing ETA | Normal workload or allocation variation | Let the run finish and record results |
| Rate drops during backups | Competing I/O | Compare during a quieter window |
| Repeated stalls on one drive | Retries, link, or media issue | Check device errors and health |
Estimate a Useful Baseline From Your Own Pool
Record the start time, allocated data, average scan rate, workload, pool status, repaired bytes, and final errors for several clean runs. A published test in which a 13.6 TB scrub completed in about 24 hours is useful as a scale example, not a promise for different hardware.
A rough estimate is allocated data divided by the sustained scrub rate, with margin for application traffic and slower regions of the pool. Do not multiply the fastest rate shown in the first minutes; the estimate can move as the filesystem reaches different blocks and devices.
When a Slow Scrub Signals a Problem
Investigate when the rate is materially below previous runs under similar conditions, the scrub repeatedly pauses at the same point, device error counters rise, or one disk shows high latency, resets, or temperature. A changing ETA by itself is weak evidence.
The purpose is not only speed. Full-data verification and checksums reveal silent corruption before another failure removes the good repair copy. Scrub errors therefore deserve more attention than an inconvenient finish time.
Schedule Scrubs Without Hiding Failures
Run scrubs regularly during a window that allows them to finish, but keep ordinary workloads available if the filesystem is designed for online checks. If production I/O causes a large slowdown, schedule the most intensive part outside backup, indexing, and media-processing jobs.
Review the final status instead of relying on task completion alone. A scrub complements backups and snapshots; it does not replace them, and snapshots can preserve already-corrupted data if integrity checks never expose the damage.
FAQ
Can you use the NAS while a scrub is running?
Usually yes. Expect some latency or throughput impact, especially on HDD pools, and compare behavior with the filesystem's own priority settings before pausing the job.
Why does the scrub ETA keep changing?
The scan rate changes with allocated regions, disk response, and competing I/O. Use the trend across the run and your prior baselines rather than one early estimate.
Should you stop a scrub that is taking too long?
Not for duration alone. Check status, device errors, temperature, and application impact. Stop or pause only when the platform supports it and a specific fault or operational risk justifies intervention.
Support & Tips
More to Read

Why Does a RAID Array Become Inactive After a Power Loss?
An inactive array often means metadata was found but the system did not have enough confidence or members to start it safely after an...

What Are the Risks of Forcing a Missing RAID Member Back Online?
Force options can bypass safety checks around stale metadata, dirty parity, missing writes, or active pools; inspect and preserve evidence before using them.

How to Distinguish a Bad SATA Cable From a Failing NAS Drive
Track whether errors follow the disk or remain with the SATA path, and separate transport counters from media-health evidence before replacing hardware.

