Free RAID calculator that goes past capacity. Monte Carlo simulation of rebuild windows, URE probability and second-drive failure across RAID 0, 1, 5, 6, 10, 50, 60 and JBOD.
Every RAID calculator on the internet answers the same question: eight 20 TB drives in RAID 5 gives you 140 TB usable. That is arithmetic, and it is correct, and it is not the number that decides whether your data survives.
The question a storage admin actually needs answered is the one nobody puts a calculator in front of:
Eight 20 TB drives in RAID 5. One drive dies. The rebuild will take 55 hours. Given a drive rated at one unrecoverable read error per 10^14 bits, what is the probability the array dies during that rebuild?
This tool answers both. It gives you the usable capacity, fault tolerance and IOPS multipliers for RAID 0, 1, 5, 6, 10, 50, 60 and JBOD, and then it runs a Monte Carlo simulation of the array's life over your chosen horizon and reports the probability of data loss for every level side by side.
A second drive fails before the rebuild finishes. Rebuild time is governed by how long it takes to write a full replacement drive: capacity divided by sustained rebuild throughput. A 20 TB drive at 100 MB/s is 55.6 hours — over two days in which a single-parity array has no redundancy left. Drive capacity has grown far faster than drive throughput, so this window has been getting steadily worse for twenty years. That is the insight the capacity calculators hide.
A URE is hit while reconstructing. To rebuild one drive in an eight-drive RAID 5, the controller must read every sector of the seven survivors — 140 TB, or 1.12 x 10^15 bits. A consumer SATA drive is specified at one unrecoverable read error per 10^14 bits. Working through the probability, P(at least one URE) = 1 - (1 - 10^-14)^(1.12 x 10^15), which is 99.999%. This is the entire basis of the "RAID 5 is dead" argument, and this tool shows you the number for your specific drives rather than asking you to take it on faith.
Drive failures are drawn from an exponential distribution derived from your annualised failure rate (or MTBF). When a drive fails, the array enters a rebuild window sized from your drive capacity and rebuild speed. Inside that window the surviving drives race the rebuild, optionally at an elevated failure rate to account for same-batch drives under sustained load. A URE roll happens on any rebuild running with zero redundancy left — which is why RAID 6 shrugs off the URE that kills RAID 5.
Ten thousand trials per RAID level, all in your browser, nothing uploaded.
Every level here protects against exactly one failure mode: a drive dying. None of them protect against a deleted directory, a bad application write, ransomware, a controller scribbling on the array, or the building burning down. The model here covers the drives only — not the controller, the backplane, the power supply, or the room. Keep independent, versioned, tested backups, with at least one copy somewhere else.
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.
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.