Calculate RAID rebuild risk, not just capacity. Monte Carlo modelling of URE and second-drive failure across RAID 0, 1, 5, 6, 10, 50, 60 and JBOD. Free.
Most RAID calculators answer one question — how much usable capacity do I get? That question has a closed-form answer and it is not the one that keeps people awake. The question this tool answers is the other one: over the next few years, what is the chance this array loses data, and which of the two ways an array actually dies is the one that gets you? Enter the drive count, the drive size, an annualised failure rate, a URE rate from the datasheet, and a rebuild speed. The tool builds the group topology for every level it supports, works out the rebuild window in wall-clock hours, and then runs a Monte Carlo simulation of the array's lifetime to a horizon you choose.
Everything runs in your browser. There is no upload, no account, and no server round trip — the simulation loop is plain JavaScript on the main thread, chunked across frames so a 100,000-trial run does not freeze the page. Inputs round-trip through the URL, so a shared link reproduces the exact configuration, and the random number generator is a seeded mulberry32, so the same link produces the same numbers.
The model treats data loss as two separate events and reports them separately rather than adding them into one blurred figure.
The simulation continues past a URE for exactly that reason, and each trial records the earliest of the two events. The results panel gives you “any data loss over N years” and “total array loss over N years” as distinct figures, plus a 95% Wilson-score margin of error so you can see how much of a small number is simulation noise rather than signal.
The rate conversions assume an exponential drive lifetime, which is the standard assumption behind every AFR and MTBF figure a vendor publishes:
lambda = -ln(1 - AFR), per drive per year.AFR = 1 - e^(-8760 / MTBF). Typing an MTBF into the second field updates the AFR field, so you can drive the model from whichever number your datasheet gives you.drive bytes / (rebuild MB/s × 1e6) / 3600 hours. Parity levels also have to read every surviving member, but those reads happen in parallel across members, so writing the single replacement drive is the wall clock.1 - (1 - p)^bits, evaluated as -expm1(bits × log1p(-p)) so it stays exact when p is around 1e-14 and the bit count is around 1e15.Drive sizes are decimal TB (10^12 bytes), because that is what vendors sell. The tool also shows the binary TiB figure your operating system will report, which is where the “my 20 TB drive shows as 18.2 TB” conversation usually starts.
The critical read is the one that matters. When a RAID 5 group is rebuilding it has one drive down and zero redundancy remaining, so it must read every surviving member end to end. With 8 drives of 20 TB, that is 7 × 20 TB = 140 TB of reads, which is 1.12 × 10^15 bits. At the consumer-SATA datasheet figure of one unreadable sector per 10^14 bits:
P(URE) = 1 - (1 - 1e-14)^(1.12e15) ≈ 1 - e^(-11.2) ≈ 99.999%
That is the whole argument in one line. It is also why the URE rate dropdown matters more than almost any other input. The same 140 TB critical read against an enterprise SAS drive rated at 10^16 gives roughly 10.6% — a real risk, but a different category of risk.
| Layout (20 TB drives) | Critical read | P(URE) at 10^14 | P(URE) at 10^15 | P(URE) at 10^16 |
|---|---|---|---|---|
| RAID 5, 8 drives | 140 TB | ~99.999% | ~67.4% | ~10.6% |
| RAID 6, 8 drives (second drive already down) | 120 TB | ~99.99% | ~61.7% | ~9.2% |
| RAID 1 or RAID 10 (one mirror copy read) | 20 TB | ~79.8% | ~14.8% | ~1.6% |
Two things in that table are easy to miss. First, RAID 6 only rolls for a fatal URE once it is already down two drives — with a single drive down it still has its second parity and reconstructs the bad sector without incident. That is the actual value of dual parity, and it is why the RAID 6 row is not the disaster the RAID 5 row is despite similar per-rebuild odds. Second, mirrors read one surviving copy, not the whole array, so a mirror rebuild is bounded by drive size no matter how wide the array gets.
A 20 TB drive rebuilt at a sustained 100 MB/s takes 55.6 hours — about 2.3 days of the array running degraded. That number falls out of capacity divided by speed and nothing else, and it is the single lever most within your control. The default of 100 MB/s is already optimistic for a controller that is still serving production I/O while it rebuilds; halving the rebuild speed doubles the exposure window.
With 8 drives at a 1% AFR and no replace delay, the model puts the chance of a second drive failing inside that 55.6-hour window at roughly 0.045%. That sounds negligible until you notice how small it is compared to the URE number above — for large modern drives, the URE path dominates the second-failure path by orders of magnitude. Add a detect-and-replace delay (no hot spare, a weekend, a courier) and the second-failure number climbs in direct proportion to the window.
The correlated-failure multiplier scales the hazard rate of the surviving members while the group is degraded. Leaving it at 1 assumes drives fail independently, which is the assumption every naive MTTDL formula makes and the assumption reality most often violates:
Raising the multiplier to 2 or 3 is not pessimism, it is the reason “the second drive failed during the rebuild” is a story every storage administrator has heard. The multiplier only applies while degraded, so it does not distort the healthy-state failure rate.
The tool models JBOD, RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 and RAID 60. Nested levels are split into a number of parity groups you choose, and only a whole multiple of the group size is consumed — leftover drives are reported in a “drives used” figure rather than silently counted as capacity. JBOD is included and modelled honestly: every drive is its own island, so losing one loses only that drive's data, which is still a data-loss event.
Each level is scored on worst-case and best-case fault tolerance. RAID 10 is the clearest example of the gap: it is guaranteed to survive one drive, but in the lucky case it survives one drive in every mirror pair. The comparison table lists usable capacity, efficiency, tolerance, read and write multipliers, the rebuild window, P(URE per rebuild) and the simulated loss probabilities side by side, and copies as Markdown for pasting into a design document or a change ticket.
Performance figures use the standard IOPS model: reads are served by every member holding a copy, and writes are divided by the level's small-write penalty — 4 I/Os for single parity (read data, read parity, write data, write parity), 6 for dual parity, and n for an n-way mirror, where every write must land on every member.
| Input | Range | Notes |
|---|---|---|
| Drives in the array | 1–64 | Below a level's minimum, that level is simply not offered |
| Drive size | 1–40 TB | Decimal TB; TiB is shown alongside |
| RAID 50/60 groups | 2–8 | Wider groups mean bigger critical reads |
| Annualised failure rate | 0.1–20% | Vendor datasheets typically claim 0.35–0.7%; large published fleet studies have run higher |
| URE rate | 10^14 to 10^17 | Four datasheet tiers, from consumer SATA to enterprise SAS and SSD |
| Correlated-failure multiplier | 1–10 | Applied to survivors only while degraded |
| Rebuild speed | 10–1000 MB/s | Sustained throughput to the replacement drive |
| Detect + replace delay | 0–336 hours | 0 assumes a hot spare |
| Horizon | 1–10 years | Loss counts are also bucketed by year |
| Monte Carlo trials | 1,000–100,000 | More trials, less noise, longer run |
The conclusion the numbers keep pointing at is the unglamorous one: RAID is an availability mechanism, not a backup. It buys you the ability to keep serving through a drive failure. If you want to compare fault-tolerance behaviour interactively — inject a failure, watch which stripes go, watch a rebuild run — the raid-simulator covers the mechanics; this page is about the odds.
Every redundant RAID level has a period after a drive failure during which it is running with less protection than it was designed for. That period is the rebuild window, and its length is the most under-examined number in storage planning.
The floor on rebuild time is set by writing the replacement drive. Capacity divided by sustained throughput:
Parity levels must additionally read every surviving member to reconstruct the missing data, but those reads run in parallel across members, so the single-drive write generally dominates the wall clock. What that arithmetic does not capture is that an array serving production traffic does not rebuild at its idle rate. The controller interleaves rebuild I/O with client I/O, and most controllers default to a conservative rebuild priority precisely so that users do not notice a degraded array. Effective rebuild rates of 20-50 MB/s are ordinary, which turns a 55-hour job into five or ten days.
The structural problem is that this has been getting worse for two decades. Drive capacity has grown by roughly three orders of magnitude since the early 2000s; sustained sequential throughput has grown by less than one. A 250 GB drive in 2005 rebuilt in under an hour. A 20 TB drive today takes days. Every hour of that is an hour in which a single-parity array has zero redundancy, and an hour in which the surviving drives are doing a full-surface sequential read under sustained load — the single most demanding thing they will ever be asked to do, applied at the worst possible moment.
Two practical consequences follow. First, the case for double parity (RAID 6, raidz2) or mirroring gets stronger every time drives get bigger, independent of any argument about UREs. Second, wider arrays are worse, not better: adding drives to a RAID 5 set increases the number of survivors that must all read cleanly and increases the odds that one of them picks that window to fail. If you are sizing a new array, the rebuild window is the number to look at first, because it is the multiplier on every other risk in the system.
A simulation is only as useful as your understanding of what it left out. Here is what to trust in these results and what to discount.
Comparisons are much more reliable than absolute numbers. Every RAID level in the table is simulated under identical assumptions with the same drives, the same AFR, the same URE rate and the same rebuild speed. If RAID 6 comes out three orders of magnitude safer than RAID 5 for your configuration, that ratio is robust — it survives being wrong about the inputs, because being wrong about the inputs moves both levels together. The absolute probability for any single level inherits all the uncertainty in the AFR and URE figures you fed it, and those figures are soft.
The URE rate is a warranted bound, not a measurement. One error per 10^14 bits is the worst case the manufacturer is willing to stand behind. Observed field rates are generally better. Arrays that this model says should have died are running fine all over the world, and that is not a contradiction — it is what a conservative bound looks like from the inside. Read the URE column as an upper bound on risk.
Distinguish total array loss from block loss. The table separates them for a reason. Losing enough drives inside a rebuild window is unrecoverable under any implementation: the array is gone. A URE during a zero-redundancy rebuild is implementation-dependent. Classic hardware RAID controllers abort and fail the array. Linux mdadm and ZFS typically log the bad block, lose whatever lived there, and complete the rebuild — a lost file rather than a lost filesystem. Which one you are running materially changes what a URE costs you.
Exponential failure understates an ageing array. The model is memoryless: year one and year seven carry identical per-drive risk. Real drives follow a bathtub curve with elevated infant mortality, a long flat middle, and a rising tail after roughly four to five years. If your array is old, the real risk is higher than shown. Raising the AFR input is a crude way to model that.
Scrubbing is not modelled, and it matters. Regular patrol reads and scrubs walk the whole array while it is healthy, find unreadable sectors, and reconstruct and remap them from redundancy that still exists. That is the single most effective thing you can do to reduce URE risk during a rebuild, because it drains the pool of latent bad sectors before you need those reads to succeed. A monthly-scrubbed array is meaningfully safer than these numbers suggest. An array that has never been scrubbed may be worse.
And the scope is the drives only. Controller failure, backplanes, cabling, firmware bugs, a power supply that takes four drives with it, silent corruption that parity RAID cannot even detect, human error, ransomware, fire and theft are all outside the model, and collectively they cause more data loss than second-drive-during-rebuild ever has. Treat these numbers as a floor on your real risk. RAID is an availability feature. Backups are the data protection.
A URE is a sector a drive cannot read back, even after its own internal retries and error correction. The drive reports a read failure rather than returning wrong data. Manufacturers specify a rate on the datasheet: typically one URE per 10^14 bits read for consumer SATA, 10^15 for enterprise SATA and NAS drives, and 10^16 or better for enterprise SAS. During normal operation a URE is a non-event, because a redundant array reconstructs the sector from parity or a mirror and remaps it. During a rebuild on an array with no redundancy left, there is nothing to reconstruct from. A single-parity array that has already lost one drive is in exactly that state, and a rebuild must read every sector of every surviving drive. The more capacity you must read, the more likely you are to hit one. That is why the URE rate stops being a footnote and becomes the dominant risk factor once arrays get large.
Treat each bit read as an independent Bernoulli trial with failure probability p = 1 / (URE rate). If the rebuild must read B bits, the probability of at least one URE is 1 - (1 - p)^B. For eight 20 TB drives in RAID 5, the rebuild reads the seven surviving drives: 7 x 20 TB = 140 TB = 1.12 x 10^15 bits. With p = 10^-14 that gives 1 - (1 - 10^-14)^(1.12 x 10^15) = 0.99999, or effectively certain. Move the same array to drives rated 10^15 and it drops to about 67%; at 10^16 it is about 10.6%. The independence assumption is a simplification — real UREs cluster on damaged media rather than scattering uniformly — but it is the standard model and it is the one the vendor rate is written against.
Because the rebuild read grew while the URE rate stayed flat. In 2005, a five-drive RAID 5 of 250 GB disks read 1 TB during a rebuild — about 8 x 10^12 bits, or roughly an 8% chance of a URE at 10^14. Today an eight-drive array of 20 TB disks reads 140 TB, a 140-fold increase, and consumer drives are still specified at 10^14. At the same time rebuild windows stretched from a couple of hours to a couple of days, widening the window for a second drive to fail. Neither problem is a defect in RAID 5 itself; the parity maths still works exactly as it did. What changed is that single parity no longer buys enough margin at modern capacities. The practical guidance most storage teams follow is to stop using single parity above roughly 4-8 TB drives, and to use RAID 6, RAID 10, or a double-parity equivalent such as ZFS raidz2 instead. Run your own numbers in the simulator above rather than trusting a capacity threshold someone quoted in a forum.
The floor is set by writing the replacement drive: capacity divided by sustained write throughput. A 20 TB drive at 100 MB/s takes 55.6 hours. Parity levels must also read every surviving member, but those reads happen in parallel across members, so the single-drive write is usually the wall clock. That floor is optimistic. An array still serving production I/O rebuilds far slower, because the controller has to interleave rebuild traffic with client traffic, and most controllers throttle rebuild priority by default. Real-world rebuilds at 20-50 MB/s effective are common, which turns a two-day job into a five-to-ten-day job. Rebuild speed is an input in this tool for exactly that reason: try your array at 100 MB/s and again at 25 MB/s and watch what happens to the risk.
They fail differently, and the right answer depends on which failure you are more worried about. RAID 6 tolerates any two drives failing, in any combination, and gives better capacity efficiency at wide drive counts: twelve drives yields ten drives' worth of space versus six for RAID 10. Its weakness is the write penalty — six I/Os per small random write against two for RAID 10 — and rebuilds that must read every surviving member, which is slow and stressful for the array. RAID 10 tolerates one drive per mirror guaranteed, and can survive up to half the array if you are lucky about which drives die, but two failures in the same mirror pair lose everything. Its rebuild reads a single surviving drive rather than the whole array, so it finishes faster and puts less strain on the survivors. As a rule of thumb: RAID 10 for random-write-heavy workloads such as busy databases and virtualisation hosts, RAID 6 for capacity-oriented and sequential workloads such as backup targets, archives and media stores. Set both up in the comparison table above with your drive count and see what the numbers say.
AFR (annualised failure rate) is the probability a drive fails within a year; MTBF is the same information expressed as hours between failures. Vendor datasheets typically claim 0.35-0.7% AFR, or MTBF figures of 1-2.5 million hours. Backblaze publishes quarterly fleet statistics across tens of thousands of drives and generally reports something closer to 1-2% annualised across recent models, with individual bad models running considerably higher. If you have no better information, 1% is a defensible planning number, and running the simulation again at 2% is a cheap way to see how sensitive your conclusion is. Bear in mind that a single AFR flattens the bathtub curve: real drives show elevated infant mortality in the first few months, a long flat middle, and a rising tail past roughly four or five years. A five-year-old array is riskier than this model says.
There is an explicit correlated-failure multiplier for it. Drives bought together usually come from the same manufacturing batch, have near-identical power-on hours, share a chassis, a power supply and a thermal environment, and get hit by the same power events. A rebuild is also the heaviest sustained load the array will ever see, so it is a stress test applied at the exact moment you can least afford another failure. The multiplier raises the failure rate of surviving drives while the array is degraded. It is a blunt instrument and it is not calibrated against any published dataset, so treat it as a sensitivity knob rather than a measurement: set it to 3 and see whether your conclusion changes. If it does, that is worth knowing before you commit to a layout. The standard operational mitigation is to buy drives from mixed batches or mixed vendors.
Two reasons, and both are worth stating plainly. First, the URE rate on the datasheet is a warranted worst case, not a measurement — field studies and operator experience consistently observe better rates than the specification, sometimes by an order of magnitude. The number this tool reports is best used as an upper bound on risk and as a way to compare levels, not as a prediction of a specific date. Second, hitting a URE is not always fatal. A classic hardware RAID controller usually aborts the rebuild and fails the array on an unreadable sector, which is the scenario the "RAID 5 is dead" argument describes. Linux mdadm and ZFS generally record the bad block, lose the affected data, and finish the rebuild — so you lose a file rather than a filesystem. This is why the comparison table separates total array loss from any data loss. It is also why regular scrubbing matters: patrol reads find and remap bad sectors while the array is still healthy, so they are not waiting to ambush you during a rebuild.
No, and this is the single most expensive misunderstanding in storage. RAID protects against exactly one failure mode: a drive dying. It offers nothing against deleting the wrong directory, a bad application write corrupting a database, ransomware encrypting the volume, a RAID controller failing and scribbling on the array, firmware bugs, filesystem corruption, theft, fire or flood. In many of those cases RAID actively works against you by replicating the damage to every member instantly. The array-only scope of this simulator is deliberate and stated, but it means the numbers here are a floor on your real risk, not a ceiling. Keep independent, versioned, tested backups with at least one copy off-site, and rehearse a restore. An untested backup is a hypothesis, not a backup.
The simulation covers drive failure and unrecoverable read errors within the array, and nothing else. Excluded: RAID controller and HBA failure, backplane and cabling faults, firmware bugs, power supply failures that take several drives at once, silent data corruption that RAID cannot detect (parity RAID has no checksums — filesystems like ZFS and Btrfs do), filesystem-level corruption, human error, malware, and site-level disasters. Drive failures are modelled as exponential and therefore memoryless, which understates risk in an ageing array. Rebuild speed is treated as constant. Scrubbing and patrol reads are not modelled, which makes the URE numbers pessimistic for a well-maintained array. Use this to compare RAID levels against each other under consistent assumptions, which is what it is good at, rather than to predict when your specific array will fail.
Build virtual RAID 0–6, 0+1, 10, 50, and 60 arrays. Route text and sized payloads, model controller caching, inject failures, and watch rebuilds and RAID reshapes.
Calculate optimal RTO/RPO targets, analyze downtime costs, and compare backup strategies with cost-benefit analysis
Analyze system availability, calculate MTBF, MTTR, MTTA, MTTD, MTTF metrics, estimate downtime costs, and improve system reliability.
Calculate SLA uptime percentages and error budgets, and convert between nines of availability and allowed downtime.
Compare disaster recovery site types (hot, warm, cold, mobile, cloud) with 5-year TCO projections, RTO/RPO alignment analysis, and downtime cost modeling. Calculate breakeven points and generate cost justification reports for DR investments.