Stalls at a percentage and stops
A surviving member hit a sector it cannot read. The rebuild cannot compute the missing data without it, so it halts. Retrying hits the same sector.
Bad sectors
Rebuilds do not fail randomly. They fail because something in the array cannot be read, and running it again applies the same maximum load to the same struggling disks — usually with a worse result the second time.
It sweeps every surviving member end to end and writes as it goes. On disks already carrying unreadable sectors that is simultaneously the likeliest moment for a second failure and the point at which wrong data gets committed.
Understanding the load explains every failure mode below.
Rebuilding a parity array reconstructs the missing member by reading every sector of every surviving disk and computing what the absent one held. On a mirror it reads the survivor completely and copies it. Either way it is the heaviest sustained operation the array ever performs, and it applies to all members simultaneously for hours or days.
That matters because the surviving disks are almost always the same age as the one that just failed, bought in the same batch, and subjected to identical work since installation. The rebuild is a full-surface stress test applied to hardware with the same accumulated wear as the component that already gave up.
Note which one you saw — it changes the approach.
A surviving member hit a sector it cannot read. The rebuild cannot compute the missing data without it, so it halts. Retrying hits the same sector.
The stress finished off a member that was already marginal. The array is now past its redundancy limit and offline.
The array assembled but the file system is damaged — often because the rebuild wrote reconstructed data from stripes that were already inconsistent.
Usually a controller that cannot hold a stable view of the set, or a member dropping and returning intermittently.
All three are the natural next move.
Do not run it again. The same read that failed will fail again, and the disks will have spent another few hours at maximum load reaching it. Where a marginal member survived the first attempt, it may not survive the second.
Do not swap in more replacement disks. Adding another new member and restarting compounds the problem: more writing, more stress, and the original data now sitting behind two incomplete reconstructions.
Do not force a member online. Controllers offer to force-import or force-online a disk they have rejected. That accepts a member whose contents the controller does not trust into an array it is about to write to.
The failed rebuild has told you the array cannot be repaired in place. That is useful.
Including any the controller has ejected and any replacement already inserted.
The percentage it reached, whether a second disk dropped, and the wording of any error. That narrows the fault before anything is opened.
Including the failed original and the partially written replacement. Both carry information about what happened.
Every disk is imaged before analysis begins, so a large array takes days before reconstruction even starts.
No. Rebuilds do not fail randomly — something in the array cannot be read, and retrying applies the same maximum load to the same struggling disks to reach the same failure. Where a marginal member survived once, it may not survive twice.
A surviving member hit a sector it cannot read, and without it the missing data cannot be computed. The percentage tells you roughly where the unreadable region sits, which is genuinely useful information.
Frequently. A disk that dropped under rebuild stress is usually not destroyed — it failed a sustained read test rather than dying outright, and often images substantially once handled properly.
No. That accepts a member the controller does not trust into an array it is about to write to. If its contents are stale or partially written, forcing it online can propagate that across the set.
The array assembled but the file system is damaged — often because reconstructed data was computed from stripes that were already inconsistent. That is a logical repair rather than an array problem.
Every disk, labelled by bay, including the failed original and any replacement that was partially written. Both carry information about what happened, and the replacement occasionally holds usable reconstructed data.