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.

Usable capacity
--
Redundancy overhead
--
Disks that can fail
--
Rebuild window
--
Read error during rebuild
--
Write penalty --
Read throughput --

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

Databases, VMs

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.

Bulk storage

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.

Boot volumes

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.

Scratch, caches

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.

Small RAID 5

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? +
RAID 5 gives you N-1 disks of usable space, RAID 6 gives you N-2, and RAID 10 gives you exactly half. With eight 4 TB disks that is 28 TB on RAID 5, 24 TB on RAID 6 and 16 TB on RAID 10. RAID 0 gives you all of it and protects none of it. Every figure is in decimal terabytes, the way disks are sold: the operating system will report about 9% less because it counts in binary tebibytes.
How many disks can fail in each RAID level? +
RAID 0 tolerates none. RAID 5 tolerates one. RAID 6 tolerates any two. RAID 1 tolerates every disk but one. RAID 10, 50 and 60 have two answers: RAID 10 always survives one failure and can survive up to half the array if no two failures land in the same mirror pair, RAID 50 always survives one and up to one per group, RAID 60 always survives two and up to two per group. Plan against the guaranteed number, because you do not get to choose which disk dies.
Why is RAID 5 considered risky with large disks? +
Because rebuilding it has to read every surviving disk from end to end without a single unrecoverable read error, and consumer SATA drives are specified at roughly one unrecoverable sector per 10^14 bits read. Seven surviving 4 TB disks is 2.24 x 10^14 bits, so the odds of the rebuild hitting a bad sector are near 90% - and on single parity, a bad sector during a rebuild is the array. The same array on RAID 6 shrugs it off, because the second parity block reconstructs the unreadable sector while the first covers the dead disk.
What happens if my disks are different sizes? +
The array equalises down to the smallest member. Six 4 TB disks and two 8 TB disks behave as eight 4 TB disks, and the extra 8 TB is stranded unless your controller or volume manager can carve it into a separate array. Enter the smallest disk's size in the calculator. ZFS and mdadm behave the same way here, and so does every hardware controller worth using.
How long does a RAID rebuild take? +
Long enough that it matters. The rebuild has to write one full replacement disk, so the floor is the disk's size divided by the sustained rebuild rate: a 4 TB disk at 80 MB/s is about 14 hours, and 12 TB is closer to two days. A busy array is routinely several times slower, because the rebuild competes with production I/O; the calculator applies a 4x factor for the upper end of its range. That whole window is time spent degraded, which is why a hot spare that starts the rebuild the second a disk dies is worth more than a faster controller.
What is the RAID write penalty? +
The number of physical operations a single logical write costs. RAID 0 is 1. RAID 10 is 2, and so is a two-way RAID 1, because the write lands on both halves of the mirror - an N-way mirror costs N, one write per member. RAID 5 is 4 - read the old data, read the old parity, write the new data, write the new parity. RAID 6 is 6, with a second parity block to read and write. It is why a database on RAID 6 can feel slow on disks that benchmark fine, and why RAID 10 stays the default for write-heavy workloads.
Is RAID a backup? +
No. RAID protects against a disk dying. It does nothing about a mistaken delete, a ransomware run, a controller writing corruption to every member at once, a filesystem bug, or a fire. All of those are faithfully replicated to every disk in the array in real time. Keep backups somewhere the array cannot write to, and test restoring them.
Should I use a hot spare? +
On any parity array whose rebuild window runs into days, yes. A hot spare turns 'degraded until someone reads the alert, drives to the datacentre and swaps a disk' into 'degraded for the length of the rebuild'. It costs one disk of capacity and removes the human from the most dangerous window an array has. It is not a substitute for being alerted that the disk died, though: an array that quietly consumed its spare and is now running with no protection looks perfectly healthy from the outside.

Monitor disk space and pool health across every RAID array you run

Start monitoring with fivenines.io