How Long Should You Wait Before Calling a RAID Rebuild Stalled?

Call a RAID rebuild stalled only when processed blocks stop increasing across repeated checks and the logs show no intentional pause, priority throttling, queued phase, or recoverable retry. Elapsed time alone is insufficient.

Large arrays can spend hours at a slow region, change speed sharply under application load, or pause between reconstruction and verification. Establish movement with counters and logs before intervening, because stopping or reassembling an array can create more risk than waiting.

Use Progress Delta, Not a Single Percentage

Record the exact processed-block count, percentage, speed, and estimated finish time at fixed intervals. A rebuild is moving when the block count increases, even if the rounded percentage stays unchanged. On multi-terabyte arrays, one displayed tenth of a percent can represent a large amount of work.

Check the controller or operating system from the same interface each time. Different dashboards may cache status or report different phases. A progress bar that appears frozen while block counters advance is a monitoring problem, not a stalled rebuild.

Estimate a Local Baseline Instead of a Universal Timeout

There is no single safe number of hours. Rebuild time depends on used capacity, RAID layout, drive speed, errors, controller policy, background load, and whether the implementation copies all blocks or only allocated regions.

Use the first stable hour to estimate an approximate range, then compare later intervals. A very slow mdadm resync rate may come from workload, alignment, link behavior, or a struggling drive; the correct diagnosis requires more than increasing a speed limit.

Look for an Intentional Pause or a New Phase

Some systems throttle recovery to protect foreground I/O, pause scrubs during resilver, wait for a spare assignment, or transition from rebuild to parity initialization or consistency verification. The label may remain “rebuilding” while the active task changes.

Review scheduled maintenance, power settings, temperature limits, rebuild priority, and application traffic. If speed rises when foreground load drops, the array is resource-constrained rather than stuck.

Repeated Read Errors Create a Real Stall

A source drive can spend a long time retrying a weak sector, causing throughput to collapse near the same block range. If the controller eventually reports an unrecoverable read, the rebuild may abort because redundancy cannot reconstruct that region.

A rebuild stopped by read errors demonstrates why the last successful block and the kernel error immediately afterward matter. Do not repeatedly restart a recovery that fails at the same address without protecting data and examining the source member.

A Zero Speed With Log Activity May Be Retrying

A displayed speed of zero can occur during command retries, device resets, error recovery, metadata updates, or a temporary pause. Watch disk busy time, queue depth, controller events, and kernel messages. Repeated resets or timeouts are not healthy progress.

A recovery that repeatedly interrupts also shows that not every stop has an obvious SMART failure. Capture the exact point and all logs rather than assuming a new disk or higher speed setting will solve it.

Use a Practical Stall Decision Table

Require evidence from at least two independent signals before calling the rebuild stalled: no counter movement plus an error, aborted state, or persistent identical stopping point.

What to Do Before You Restart Anything

1. Save array details, member serials, processed-block counters, and the complete event log.
2. Reduce nonessential application I/O and confirm the target and source disks remain detected.
3. Check SMART media indicators and link-reset or CRC counters on every active source.
4. Confirm there is no paused state, temperature limit, priority policy, or queued verification phase.
5. Escalate to backup, imaging, or recovery when the same unreadable range stops repeated attempts.

Do not use stop, assemble, force-online, or metadata-clear commands until the array state and exact implementation are known.

Compare Progress During a Quiet Interval

A useful stall test needs a controlled observation window. Pause large transfers and scheduled jobs, then record counters at the beginning and end of the interval. This separates foreground contention from a recovery process that cannot advance on its own.

If progress resumes when load drops, choose a lower maintenance priority or a quieter schedule. If counters remain fixed and the same error repeats, additional waiting without investigation adds little information.

FAQ

Is 99.9 percent for an hour automatically stalled?

No. Final metadata updates or a verification phase can take time. Confirm whether processed blocks, device writes, or operation state are still changing before intervening.

Should I raise the rebuild speed limit?

Only after proving the disks are healthy and foreground I/O policy is the bottleneck. A higher limit can worsen application latency and place more pressure on a marginal source drive.

When should I stop waiting?

Stop treating it as normal when counters remain unchanged across repeated checks and logs show an abort, recurring device reset, unrecoverable read, or failure at the same block range.

The Working Definition of Stalled

A rebuild is stalled when measurable work has stopped and the system cannot explain the pause as policy, load, or a new phase. Use counters and error evidence, not anxiety or wall-clock time.