RAID Calculator
Usable capacity, how many disks can fail, and how likely the rebuild is to finish.
Mixed sizes? Enter the smallest disk - the array equalises down to it.
Sets the rebuild speed and the error rate used below.
Runs entirely in your browser. Rebuild times assume a sustained rate for the disk type you picked and no other load; treat them as a floor, not a promise.
RAID levels at a glance
| Level | Min disks | Usable | Survives | Write penalty | Use it for |
|---|---|---|---|---|---|
| RAID 0 | 2 | N | 0 | 1x | Scratch space, caches, anything you can regenerate |
| RAID 1 | 2 | 1 disk | N-1 | 2x | Boot volumes, two-bay NAS, small critical datasets |
| RAID 5 | 3 | N-1 | 1 | 4x | Small arrays of small or fast disks, read-heavy |
| RAID 6 | 4 | N-2 | 2 | 6x | The default for bulk storage on large disks |
| RAID 10 | 4 | N/2 | 1 to N/2 | 2x | Databases, virtual machines, anything write-heavy |
| RAID 50 | 6 | N-g | 1 to g | 4x | Large shelves where RAID 5 rebuild windows got out of hand |
| RAID 60 | 8 | N-2g | 2 to 2g | 6x | Very large shelves that still need double parity |
N is the disk count, g is the number of groups a nested level stripes across. Write penalty is physical operations per logical write, so an N-way RAID 1 mirror costs Nx rather than 2x - the calculator shows 3x for three disks. RAID 0 needs 2 disks to actually stripe; the calculator accepts one and says what it is.
Why the rebuild is the dangerous part
An array does not usually die when a disk fails. It dies during the rebuild that follows, and there are two independent reasons why.
The window is long. Restoring redundancy means writing one entire replacement disk. A 12 TB disk at a sustained 80 MB/s is around 42 hours at best, and a rebuild competing with production traffic routinely takes several times that (the calculator applies 4x). For every hour of it, a single-parity array has no protection left at all. Disks in the same array were bought together, racked together and have identical hours on them, so the odds of a second failure in that window are not the odds of a random failure.
The read is enormous. Parity rebuilds must read every surviving member end to end. Manufacturers publish an unrecoverable read error rate for exactly this: roughly one unreadable sector per 1014 bits for consumer SATA, 1015 for enterprise nearline, 1016 and better for SSDs. Seven surviving 4 TB disks is 2.24 x 1014 bits of reading, which puts the odds of meeting at least one bad sector near 90%. On RAID 5 that bad sector arrives when there is no parity left to reconstruct it from.
RAID 6 exists for precisely this. With a second parity block, one dead disk and one unreadable sector are two different failures the array can absorb at the same time. That is the whole argument, and it is why the guidance shifted from "RAID 5 with a hot spare" to "RAID 6" as disks passed a couple of terabytes. The calculator above shows both numbers so you can see where your own array sits rather than taking the rule of thumb on faith.
Nested levels attack the same problem from the other side. RAID 50 and RAID 60 rebuild only within the group that lost a disk, so the read volume scales with the group size instead of the whole shelf. A 24-disk RAID 6 rebuilds by reading 23 disks; the same 24 disks as four RAID 6 groups read only 5.
Choosing a level
RAID 10. A 2x write penalty against RAID 6's 6x is the difference you feel on every commit, and the rebuild copies one mirror rather than reading the array. You pay half your raw capacity for it, which on the workloads that need it is the cheapest half you will ever spend.
RAID 6, or RAID 60 past a dozen disks. Backups, media, archives and object stores are read-heavy and write-sequential, which is where parity is cheapest, and large disks are exactly where single parity stops being defensible.
RAID 1. Two disks, trivial to reason about, and a machine that keeps booting when one of them dies. There is no reason to be clever with the disks the operating system lives on.
RAID 0, and only when losing the array costs you time rather than data. Striping multiplies both throughput and failure rate by the disk count, so it belongs on data that exists somewhere else too.
Still defensible on three or four small or enterprise-grade disks, where the rebuild read is a fraction of the error budget. Run the numbers above before committing: the level is not obsolete, it just stopped scaling with disk size.
What a capacity number will not tell you
A degraded array looks completely normal from the outside. Capacity is unchanged, the filesystem mounts, the application serves traffic. The only difference is that the redundancy you paid for is gone, and nothing on the machine will mention it unless something is watching the controller.
A consumed hot spare is a silent downgrade. The array rebuilt itself, nobody was paged, and it is now running with no spare and no margin. The next failure is the one that hurts.
Scrubs are how bad sectors get found early. An unreadable sector on a disk nobody has read in a year is discovered during the rebuild, at the worst possible moment. A monthly scrub finds it while the parity is still there to repair it.
Capacity planning outlives the array. Usable space is fixed the day you build it, and the fill rate is not. Knowing you have 28 TB matters far less than knowing you are adding 400 GB a week.
Fivenines watches the array after the spreadsheet is done. The agent reports ZFS pool health and resilver progress per pool, disk usage and growth per filesystem, and alerts on a degraded pool or a disk filling up, across every server you run. Sizing is a one-off; noticing is not.
FAQ
How much usable capacity do RAID 5, RAID 6 and RAID 10 give me? +
How many disks can fail in each RAID level? +
Why is RAID 5 considered risky with large disks? +
What happens if my disks are different sizes? +
How long does a RAID rebuild take? +
What is the RAID write penalty? +
Is RAID a backup? +
Should I use a hot spare? +
Explore next
Related Resources
Disk Space Calculator
Size the storage itself: growth projections, retention, multiple servers.
Explore ->Infrastructure Services
ZFS pool health, degraded vdevs and resilver progress across your fleet.
Explore ->Server Alerting & Notifications
Get paged when a pool degrades or a filesystem fills up.
Explore ->SLA Uptime Calculator
Work out what a rebuild window costs against your uptime target.
Explore ->See how Fivenines compares to other tools
Read our guide to the best infrastructure monitoring tools in 2026.
Monitor disk space and pool health across every RAID array you run
Start monitoring with fivenines.io