A rebuild is the highest-risk operation an array performs: it reads every surviving member end to end and writes across a new one. When it goes wrong, the question is not why it failed but how much it changed on the way.
Every rebuild reads all surviving members completely and writes to the array as it goes. On disks already carrying bad sectors, that is both the likeliest moment for a second failure and the point at which wrong data gets written.
Under normal use an array reads scattered blocks. A rebuild reads every sector of every surviving member without pause, often for many hours on large disks — which means it is the first time in the array’s life that every part of every disk has been exercised. Latent bad sectors that nobody knew about surface exactly here, and a single unreadable sector on a survivor is enough to stall or abort the process.
This is why arrays so often fail during a rebuild rather than before one, and why the disks in a set tend to be the same age, model and batch: they wear together, so the survivors are usually as tired as the disk that failed.
Where parity could not be read cleanly, a rebuild may still write something to the replacement disk — and that something is wrong. The array then reports itself healthy while containing regions of invalid data, which is why files appear intact in a listing and fail to open. On some controllers an aborted rebuild also leaves the metadata inconsistent, so the array can no longer be assembled at all.
The practical consequence is that a failed rebuild is not a neutral event you can simply undo. Some of the original state has been altered, which is precisely why the response to one failure should not be another attempt.
Frequently more than people expect. Every member — including the original failed disk, if you still have it — is imaged read-only. The original disk matters here: it holds the pre-rebuild state of its stripes, and where the rebuild wrote incorrect data, the old member may still carry the correct version. The array is then reconstructed from the images, with the geometry derived from the data rather than trusted from a controller that has already demonstrated it cannot be relied on.
Which is why the single most useful thing you can do after a failed rebuild is keep the disk that was pulled out. It is often the difference between a partial recovery and a complete one.
When an array degrades, the safe order is: back up what you can reach while it is still readable, then replace the failed member, then rebuild. Rebuilding first is the common instinct and the risky one, because a degraded array has no redundancy left and the rebuild is the heaviest load you can place on it.
If any surviving member shows reallocated sectors or SMART warnings, treat the array as a recovery job rather than a maintenance one. RAID and server recovery is from £500 +VAT after a free 48-hour diagnostic and a written quote.
Usually because a surviving member has bad sectors. A rebuild reads every sector of every remaining disk, often for hours, which is the first time the whole array has been exercised end to end — so latent faults surface precisely there. A single unreadable sector on a survivor can stall the whole process.
Where parity could not be read cleanly the rebuild may still have written data to the replacement disk, and that data is wrong. The array then reports healthy while holding invalid regions, which is why files list normally but fail to open. An aborted rebuild can also leave the array metadata inconsistent.
Often, yes — and more often than people assume. Every member is imaged read-only and the array reconstructed from the copies. Crucially, if you still have the original failed disk it should come in too: it holds the pre-rebuild version of its stripes and can supply correct data where the rebuild wrote wrong data.
No. A second attempt reads the same weakened disks and writes again, and it is commonly the attempt that exhausts the remaining margin. Power the array down, keep the disks in bay order, and keep the disk that was removed.
Back up whatever is still readable first, then replace the failed member, then rebuild. Rebuilding before securing the data is the instinctive move and the risky one, because a degraded array has no redundancy and a rebuild is the heaviest load it will ever carry.