A rebuild that fails, freezes at some percentage, or drops a second drive partway is the most dangerous moment in an array’s life — because every instinct shouts try again, and trying again is how a one-drive problem becomes a total loss. Here’s why rebuilds fail, the three moves that make it worse, and the discipline that keeps a wounded array recoverable.
A rebuild reads every sector of every surviving disk at sustained full intensity — on drives the same age and mileage as the one that just died. It’s a stress test scheduled for the worst possible week.
An unreadable sector on a survivor. Rebuilding RAID 5 means reading everything off every remaining disk; a single sector one drive can’t return, and many controllers give up — or worse, drop that drive too. On today’s multi-terabyte disks the chance of meeting at least one such sector across a whole-array read is uncomfortably high, which is why large rebuilds fail so much more readily than the small ones ever did. The batch-twin trap. Arrays get assembled from identical drives bought the same afternoon and aged by identical work — so when one dies of wear, its siblings are the next likeliest disks in the building to go, and the rebuild hands them the hardest week of their lives. The wrong-drive slip. Under pressure a healthy member gets pulled in place of the failed one, or a hot spare launches an automatic rebuild against a faltering survivor — human-factor failures behind a startling share of the arrays that reach the bench. Different causes, one shared fact: after the failure the data still exists on the members — right up until the next move destroys it.
Force online. The controller dropped a member for a reason, at a moment; forcing it back folds stale data into a live array, and the ‘repair’ that follows calculates rubbish into every stripe. Re-initialise or recreate the array. Every controller offers it as the clean-slate option — and it writes new metadata (sometimes new parity) across all the members, straight over your volume. The array turns healthy; its contents turn into the recovery job. Serial retries. Rebuild fails, reboot, rebuild again — each pass re-runs the full-intensity read over drives that have just proved they can’t take it. If the first retry didn’t work, the second is spending your data’s last odds. The instant any of these starts to tempt you is the instant to power down instead.
The protocol fits on a sticky note. Power the box down — a degraded array at rest is stable; the same array under load is deteriorating by the minute. Photograph and label every disk with its bay before anything moves; member order is reconstruction gold. Touch nothing in the controller — no config saves, no ‘repairs’, no firmware updates mid-crisis. Then the professional sequence: every member is imaged read-only — the ‘failed’ one included, since it’s often 95% readable on gentler hardware and holds the very stripes the survivors are missing — and the array is rebuilt virtually from those images, where parameters can be tried and mistakes cost nothing. Your data comes off the virtual volume; the original disks are never gambled. That’s the substance of our RAID recovery work — rack servers and under-desk NAS boxes alike — and the deeper why-arrays-fail arithmetic is laid out in the RAID 10 guide.
If the array holds data you can’t lose and you’ve no verified backup: no — pause it if the controller allows, and stop adding load either way. A crawling rebuild usually means a surviving disk is fighting through read errors, and hours more of maximum-intensity reading is the precise stress that kills a second drive. A paused, degraded array is recoverable; a rebuild that killed drive two often isn’t — not fully.
Forcing a member online is the single most destructive button in RAID. The controller dropped that disk at a point in time; the array has moved on since. Force it back and the controller may treat stale data as current — corrupting the very parity it then leans on to ‘repair’ everything else. If the array matters, the honest sequence is power down and image every member; the reassembly happens virtually, where mistakes cost nothing.
Same bench, same method. A four-bay Synology or QNAP under a desk is, architecturally, a small RAID server — mdadm or a vendor variant running on ordinary disks. Send the labelled drives only (no enclosure needed): every member is imaged, the array logic is rebuilt from the images, and the volume returns file by file. The details are on the NAS recovery page.
Free 48-hour diagnostic on multi-disk arrays in the lab — every member imaged before any array logic runs, written quote before any work.