RAID Rebuild Running but I/O Errors Rising: What to Do

If I/O errors keep rising during a NAS rebuild, reduce writes and treat the surviving member or connection path as unstable. A progressing percentage does not make increasing read failures safe to ignore.

The immediate goal is to preserve readable data and identify whether errors are media failures, link resets, or a bad target. Save logs and serials, confirm backup status, and avoid repeatedly restarting reconstruction while the source set is deteriorating.

Rising Errors Override the Progress Bar

A rebuild percentage answers how much of the target has been processed. It does not answer whether every source read succeeded. Compare cumulative read, write, checksum, media, and command-timeout counters at regular intervals.

When the rebuild advances while errors also rise, the array may be reconstructing most blocks but failing on specific regions. One failed source read can matter more than thousands of successful ones when the RAID level has no remaining copy for that block.

Identify Which Device Is Producing the Errors

Map every log identifier to a physical serial number. Determine whether errors come from the old surviving member, the new target, or a shared controller path. A target write error and a source read error require different decisions.

Drive-health data helps prioritize the investigation. Backblaze’s operational use of five SMART warning attributes focuses attention on reallocated, uncorrectable, timeout, pending, and offline-uncorrectable indicators rather than relying on a single overall health label.

Separate Media Errors From Link Errors

Pending or uncorrectable sectors point toward unreadable media. UDMA CRC growth, transport resets, and repeated detachments more often indicate a cable, backplane, bridge, power, or controller path. Both can interrupt reconstruction, but swapping disks will not fix a shared link problem.

A UDMA CRC error count explanation distinguishes interface transfer errors from platter damage. Save the raw count, correct one connection variable, and verify whether the counter continues increasing.

Do Not Keep Restarting a Failing Rebuild

Each full restart rereads the surviving members and may stress the same weak regions without producing a better result. If the operation repeatedly aborts near the same address or a second drive drops, stop routine repair attempts.

A rebuild blocked by source errors demonstrates the central limit: when the only good source has an unrecoverable read, the array has nowhere else to obtain the missing data. Force options cannot recreate unknown content.

Choose Between Continuing, Copying, and Imaging

If data is irreplaceable and backup is not verified, imaging readable members can be safer than allowing another automatic rebuild. A recovery-oriented second-drive failure during rebuild workflow emphasizes stopping write-heavy repair attempts when the surviving set is unstable.

Reduce Foreground Work Without Hiding the Incident

Stop backups, media indexing, downloads, virtual machines, and other avoidable writes. Keep only services needed to copy critical data or monitor the array. Lowering workload can reduce queueing and make error timing easier to interpret.

Do not clear logs, reset SMART counters, or reboot repeatedly before capturing evidence. A reboot can change device names and erase the sequence that shows which member failed first.

What to Capture Before Powering Down

• Array state, RAID level, member roles, rebuild target, and exact progress counters
• Every disk model, serial number, bay, controller port, and current device identifier
• Kernel or controller events covering the first failure through the latest I/O error
• SMART raw media, timeout, temperature, and interface-error values
• List of unreadable files or block ranges and the status of the latest verified backup

This record supports a controlled cable test, disk replacement, clone, or professional recovery without guessing which member contained the freshest data.

Require a Stable Follow-Up After Any Intervention

After replacing a cable, moving a confirmed serial-numbered disk, or reducing workload, reset only the relevant comparison baseline and watch for recurrence. A temporary improvement is not proof that the underlying fault is gone.

The array should complete recovery, return to full membership, and pass a later integrity check without new I/O errors. Until all three conditions hold under a normal representative workload, safely keep the incident open and retain the captured logs.

FAQ

Can I let the rebuild finish if only a few errors appear?

Only when the errors are understood, stable, and the data is backed up. Rising source read errors or repeated resets are an escalation signal even when the target percentage continues upward.

Should I replace the disk with the highest SMART count?

Not automatically. Confirm whether the errors follow that serial-numbered disk or remain with its bay and connection path. Replacing the wrong member during degraded operation can destroy the remaining valid source.

Can a completed rebuild still contain damaged files?

Yes. Some implementations may complete while reporting unrecoverable sectors or affected files. Always review the final error report and run an integrity check after the array returns to a stable state.

The Stop Condition

When I/O errors rise during reconstruction, protect readable data before chasing completion. Continue only after proving the source set and connection path are stable enough to supply every remaining block.