MB Networks
RAID · Rebuild · Risk
How long until your array is safe again?
Enter your drive size, RAID type, and throughput to estimate rebuild time and the window where a second failure means data loss.
Rebuild time
—
Data rebuilt
0TB
Throughput
0MB/s
Array configuration
Drive size quick-pick
Drive type preset
Rebuild time assumes constant sequential I/O. Real-world rebuilds are slower under concurrent reads/writes and may vary significantly with RAID controller and drive health.
Why rebuild time is the number that matters
A degraded RAID array isn't broken, but it isn't safe either. RAID 5 and RAID 10 have zero fault tolerance left once a drive has failed and been replaced — a second failure during the rebuild means the array is gone. RAID 6 survives a second failure during rebuild, but not a third. The rebuild window is the length of time your array spends in that reduced state, and it's driven almost entirely by one thing: how long it takes to write a full drive's worth of data back onto the replacement disk.
That's not the drive's rated sequential speed. It's whatever throughput the array can actually sustain while rebuilding — parity computation overhead, controller limits, and any I/O competing with the rebuild for the same disks. This calculator estimates that effective throughput from what you tell it about the array, then converts it into a rebuild time and a plain-language risk window.
How the estimate is calculated
Rebuild time is one drive's capacity divided by effective throughput: driveSize ÷ (sustainedThroughput × (1 − overhead%) ÷ parityFactor). Two adjustments matter:
- Concurrent I/O overhead — the percentage you set knocks directly off sustained throughput. An array serving reads/writes during the rebuild won't hit its idle rebuild speed; 15–30% is a reasonable planning range for a lightly used array, higher for anything under real load.
- RAID 6's parity penalty — reconstructing a drive under double parity costs more compute per stripe than single parity. This tool applies a 1.3× overhead factor to RAID 6 specifically, which is why it consistently comes out slower than RAID 5 at the same drive count and throughput, not just because it tolerates one more failure.
The result is an estimate, not a guarantee — real controllers rate-limit rebuilds to protect production I/O, drive health affects sustained read speed, and consumer NAS boxes throttle harder than dedicated RAID controllers. Use this to compare configurations and set expectations, not as a maintenance-window SLA.
RAID levels compared for rebuild risk
| Level | Min drives | Survives during rebuild | Rebuild load | Best for |
|---|---|---|---|---|
| RAID 1 | 2 | Nothing further | Direct copy, fastest | Boot/OS drives, small arrays |
| RAID 5 | 3 | Nothing further | Single-parity compute | Read-heavy, cost-sensitive |
| RAID 6 | 4 | One more drive failure | Double-parity compute (slower) | Large arrays, long rebuild windows |
| RAID 10 | 4 (even) | Depends which drive fails | Direct mirror copy, fastest | Write-heavy, needs both speed and redundancy |
The pattern worth internalizing: RAID 5 and RAID 10 rebuild by copying, which is fast but leaves zero margin for a second failure. RAID 6 rebuilds by recomputing parity, which is slower but survives another failure while it does. As drives get larger, rebuild windows get longer for every level — which is exactly why RAID 6 exists: bigger arrays need the extra margin precisely because their rebuilds take longer.
Worked example
Four 8TB drives in RAID 5, rebuilding at a sustained 150MB/s (typical for a NAS-class HDD under load) with 20% throughput reserved for concurrent I/O:
- Effective throughput: 150 × 0.80 ÷ 1.0 = 120MB/s
- Data to rebuild: 8TB ≈ 8,000GB
- Rebuild time: 8,000,000MB ÷ 120MB/s ≈ 18.5 hours
That's an extended risk window by this tool's own thresholds — long enough that pausing non-essential writes and running a SMART test on the remaining drives before you start is worth the time it costs.
How long does a RAID 5 rebuild actually take?
It depends almost entirely on drive size and sustained throughput, not drive count. A 4TB drive rebuilding at 150MB/s takes roughly 9–10 hours under moderate load; an 8–16TB drive on the same array can stretch past a full day. Use the calculator above with your actual drive size and a realistic throughput estimate — not the drive's rated max — for a number specific to your array.
Why is RAID 6 slower to rebuild than RAID 5?
RAID 6 reconstructs the failed drive by recomputing double parity across every stripe, which costs more read/write work per byte than RAID 5's single-parity math. That's the tradeoff: RAID 6 takes longer to rebuild in exchange for surviving a second drive failure while it does.
Is my data actually at risk during a rebuild?
For RAID 5 and RAID 10, yes — a second drive failure during the rebuild loses the array, full stop, no exceptions. RAID 6 tolerates one more failure during rebuild but not two. This is exactly why rebuild time matters: it's the length of time you're exposed, not just a maintenance inconvenience.
What actually slows a rebuild down?
Three things, roughly in order of impact: concurrent I/O competing with the rebuild for the same disks, the array controller deliberately rate-limiting the rebuild to protect production performance, and degraded read speed on the surviving drives (often the first sign a drive is failing, not just old).
Should I take the array offline during a rebuild?
You don't have to — RAID rebuilds are designed to run while the array stays online. But every read/write during that window competes with the rebuild for I/O and extends it, and on RAID 5/10 you're one failure away from data loss the whole time. Pausing non-essential writes (backup jobs, large transfers) during a long rebuild is a reasonable trade for shortening the exposure window.
Does a bigger drive always mean a longer rebuild?
Yes, roughly linearly — rebuild time is capacity divided by effective throughput, so doubling drive size roughly doubles rebuild time at the same throughput. This is the core argument for RAID 6 over RAID 5 as drives get larger: bigger drives mean longer exposure windows, and RAID 6's extra parity buys back margin for exactly that scenario.
RAID 5 vs RAID 6 — which should I actually use?
For arrays of 4+ large drives (8TB+), RAID 6 is the safer default — the rebuild window is long enough on modern drive sizes that surviving a second failure is worth the extra parity drive and slower rebuild. For 3-drive arrays or smaller drives with correspondingly short rebuild windows, RAID 5's simplicity and speed are a reasonable trade. Either way, RAID is not a backup — it protects against a drive failure, not against deletion, corruption, or a site-level incident.
Why does this tool ask for throughput instead of just using the drive's rated speed?
A drive's rated sequential speed is a best-case number measured with nothing else happening. Real rebuilds compete with production I/O, run through a RAID controller doing parity math, and often get deliberately throttled to protect array performance during the rebuild. Sustained real-world throughput is usually well below the spec sheet number — entering your own estimate (or the default) gets you a realistic estimate instead of an optimistic one.
Related tools
Estimates assume equal-size drives and constant throughput. Real rebuilds are affected by concurrent I/O, drive health, and controller limits.