RAID Rebuild Time Calculator

How this is calculated

REBUILD TIME IS THE REPLACEMENT DRIVE'S CAPACITY DIVIDED BY THE REBUILD SPEED. An 8 TB drive rebuilding at 100 MB/s takes about 22 hours - and that is the optimistic case, with the array otherwise idle. A NAS still serving files rebuilds far more slowly because the same disks are doing two jobs, and many controllers deliberately throttle a rebuild to keep the array responsive. Doubling or tripling the figure for a working array is not pessimistic. ⚠️ THE READ IS THE PART THAT MATTERS, AND IT IS MUCH LARGER THAN THE WRITE. To reconstruct one failed drive in RAID 5 or RAID 6, every remaining drive must be read essentially in full. Six 8 TB drives means reading 40 TB to rebuild 8. RAID 10 is completely different: a failed drive is rebuilt by copying its MIRROR PARTNER, so you read one drive, not five. That single structural difference is the strongest practical argument for RAID 10 on large arrays, and it does not show up anywhere in a capacity comparison. DRIVES PUBLISH AN ERROR RATE AND IT IS ON THE DATASHEET. Consumer and NAS drives are typically specified at no more than one unrecoverable read error per 10^14 bits read - Seagate quote exactly that for IronWolf and SkyHawk. Enterprise drives such as Exos are specified an order of magnitude better, at 10^15. Ten to the fourteen bits is 12.5 TB, which is the number worth remembering: on a consumer spec you are entitled to expect one unreadable sector for roughly every 12.5 TB you read. ⚠️ TREAT THE RESULTING PROBABILITY AS A WORST CASE, NOT A FORECAST. This is important and it is where the well-known 'RAID 5 is dead' argument overreaches. The published figure is a MAXIMUM the manufacturer guarantees not to exceed, not the rate drives actually achieve, and measured error rates are generally far better than spec. Real rebuilds succeed much more often than this arithmetic suggests. What the number is genuinely good for is COMPARISON - between levels, between drive classes and between array sizes - rather than as a prediction of your Tuesday. A URE DURING REBUILD IS NOT ALWAYS TOTAL LOSS EITHER. Older controllers would fail the whole array on one bad sector; many modern systems and filesystems such as ZFS or btrfs will report the affected file, carry on, and leave the rest intact. Losing one file is a very different day from losing the array, and which one you get depends on your controller and filesystem rather than on this arithmetic. WHY DOUBLE PARITY EXISTS. RAID 6 survives a second failure DURING the rebuild, which is exactly the window this tool is measuring. As drives grow, rebuild windows lengthen while the amount that must be read grows with them - which is the real reason single parity fell out of favour on large arrays, more than any single probability figure.

Common questions

Why does the rebuild read so much more than it writes?

Because parity reconstruction needs every surviving drive. To rebuild one failed disk in RAID 5 or RAID 6, the controller reads all the remaining drives essentially end to end and recomputes the missing blocks - so six 8 TB drives means reading 40 TB in order to write 8. RAID 10 does not work that way at all: a failed drive is rebuilt by copying its mirror partner, so exactly one drive is read. That structural difference is the strongest practical argument for RAID 10 on large arrays, and it is invisible in any comparison based on usable capacity.

Is my rebuild really going to take this long?

Probably longer. The figure assumes the array is doing nothing else, and a rebuild on an array still serving files competes with that work for the same disks - many controllers also deliberately throttle rebuilds to keep the array responsive, which is usually the right trade but stretches the window. A third of the idle speed is common on a busy NAS. Since the risk window IS the rebuild duration, it is worth checking whether your controller lets you prioritise rebuild speed over performance, and worth accepting slower file access for a day if it does.

Where does the error rate come from?

The drive's own datasheet, under a line usually called non-recoverable read errors per bits read. Consumer and NAS drives are typically specified at no more than one per 10^14 bits - Seagate publish exactly that for IronWolf and SkyHawk - while enterprise drives such as Exos are specified an order of magnitude better at 10^15. Converting the consumer figure gives the number worth remembering: 10^14 bits is 12.5 TB, so you are entitled to expect one unreadable sector for roughly every 12.5 TB read. Enterprise drives stretch that to 125 TB, which is the actual substance behind their price premium.

So is RAID 5 dead?

That claim overreaches, and it is worth being precise about why. The published error rate is a MAXIMUM the manufacturer guarantees not to exceed, not the rate drives actually achieve - measured rates are generally far better, and real rebuilds succeed much more often than this arithmetic predicts. The honest use of the number is comparison rather than prophecy: it shows clearly that the risk grows with array size, that it grows faster for single parity, and that enterprise drives buy a real order of magnitude. Those conclusions hold even though the absolute probability is pessimistic.

Does one read error destroy the whole array?

It depends on your controller and filesystem, and the answer has improved a lot. Older hardware RAID controllers would fail the entire rebuild on a single unreadable sector, which is where the alarming version of this story comes from. Many modern systems are far more graceful: ZFS and btrfs will report which file was affected, carry on rebuilding, and leave everything else intact. Losing one file is a completely different day from losing the array, and which one you get is a property of your setup rather than of this calculation - it is worth knowing which you have before you need to.

What does RAID 6 actually buy me here?

Survival of a second failure during the rebuild, which is precisely the window this tool measures. The reason single parity fell out of favour on large arrays is not really any single probability figure - it is that drives keep growing, so rebuild windows keep lengthening while the amount that has to be read grows with them. Double parity means the window is no longer a single point of failure. That is also why the capacity comparison alone is misleading: RAID 6 costs one more drive of capacity and removes the one moment when a parity array has no protection left at all.

Should I just buy enterprise drives?

They buy exactly one order of magnitude on this specification - 125 TB of reading per allowed error instead of 12.5 - which is a genuine and quantifiable difference rather than marketing. Whether it is worth the price depends on how much has to be read during a rebuild, which is why the tool shows that figure directly. On a small array reading 10 TB, the consumer spec is comfortable. On a large one reading 100 TB it is not, and either enterprise drives or double parity starts to look like the cheaper option compared with the alternative. Run both drive classes through the tool with your real array size before deciding.

Take it further with AI

Copy this into ChatGPT or Claude with your own numbers filled in. It hands over the figures this calculator worked out, so the answer is built on real arithmetic instead of a guess.

I used the RAID Rebuild Time Calculator at https://www.bfcbrilliance.com/tools/raid-rebuild-time-calculator.

What I entered:
- RAID level: ___
- Drives in the array (drives): ___
- Size of each drive (TB): ___
- Rebuild speed (MB/s): ___
- Drive error rate (from the datasheet): ___

What it calculated:
- Rebuild time: ___
- That rebuild in days: ___
- Data that must be read to rebuild: ___
- Drives that get read end to end: ___
- Read errors the spec allows over that read: ___

Use those figures as given — they are already worked out, so please don't recalculate or estimate your own. Help me turn them into a plan: what to buy or do, in what order, roughly what it should cost, and the mistakes people most often make with this job.

More RAID & arrays tools