The question is normally asked as a scheduling problem: how long will this take. The number matters for a different reason.
A rebuild reads every surviving disk from end to end, and until it finishes, the array has no redundancy left. The duration is not a wait. It is the length of the window in which one more problem destroys everything.
What sets the duration
The floor is capacity divided by sustained read speed, because every remaining disk must be read in full to recompute what was lost. Everything else adds to it:
- Array activity. Every read and write your users send competes with the rebuild for the same drives.
- Rebuild priority. Most controllers let you choose between finishing fast and staying responsive. During a rebuild, fast is usually the right answer.
- Controller performance. Parity computation for a large array is real work.
Which is why any single number quoted in an article is worthless for your array. Measure yours once, deliberately, while nothing is wrong, and you will know what to expect when something is.
Why the window is the dangerous part
The surviving disks are almost always the same model, the same age, and often the same manufacturing batch as the one that just died. They have run the same hours in the same rack at the same temperature.
A rebuild asks all of them, simultaneously, for the heaviest sustained read they have done in their lives, at exactly the moment the array can least afford another failure.
And it does not take a full second failure to hurt you. A single unreadable sector on a survivor can abort the rebuild, because the controller needs that block to reconstruct the missing one.
Two timers, started together, running at different speeds. The rebuild is the one you are watching. The other one, which no dashboard displays, is the remaining life of the disks doing the rebuilding.
What actually reduces the risk
- Have a current backup before the rebuild starts. Everything below is secondary to this.
- Stop using the array if the work can wait. An idle rebuild is a shorter rebuild.
- Raise rebuild priority. Slower service for a day is a good trade against a wider window.
- Replace with an identical-or-larger disk, immediately. A degraded array left running for a week is a decision, whether or not anyone made it deliberately.
- Consider RAID 6 for large arrays. It survives one more failure during exactly this window.
The part people find annoying and should not
RAID is not a backup.
It protects against a disk failing. It does nothing about a deleted file, a ransomware run, a corrupted database, a controller writing garbage, a fire or a theft. In every one of those cases the array faithfully replicates the damage across all its disks, immediately and reliably.
If the only copy of something lives on the array, you have redundancy and no backup. The rebuild is the moment you find out which one you had.
Where this page stops being useful
If the array is already degraded and a second disk is now showing errors, stop reading and stop the array. At that point a rebuild is a gamble with your data as the stake, and the safer path is imaging the individual disks first, then reconstructing offline from the images.
We cannot tell you from here which situation you are in. What we can say is that the decision gets harder every hour the degraded array keeps running, and that nobody has ever regretted having a backup at that moment.
If you write about storage yourself, the rebuild-time calculator behind these figures is free to embed on your own site: one iframe, no account, and it keeps your readers on your page instead of sending them elsewhere.
If the rebuild has already failed, or a second disk went during it, the situation has changed category and this page no longer applies. What follows then is RAID data recovery, which starts by imaging the member disks individually rather than by asking the controller to try again.
Recover your deleted files → EaseUS
Free scan · deleted, formatted & lost files · Windows & Mac
