Pick a level and a drive count to get usable capacity in both TB and TiB, how much of the raw capacity goes to parity, how many drives the array survives, and the write penalty each level charges per random write. Every level is compared on the same drives underneath. It all runs in your browser, and the URL updates so you can share the configuration.
| RAID level | RAID 6 — Striping with dual parity |
|---|---|
| Drives in array | 8 |
| Data drives | 6 |
| Parity / mirror drives | 2 |
| Raw capacity installed | 32.0 TB |
| Usable capacity | 24.0 TB (21.8 TiB) |
| Write penalty | 6× per random write |
Two drives worth of parity, so the array survives a second failure during a rebuild. The default for large-capacity arrays, at the cost of the heaviest write penalty here.
What 8 × 4 TB drives deliver under each level, so the trade between capacity, redundancy, and write speed is visible in one place.
| Level | Usable | Efficiency | Survives | Write penalty | Best for |
|---|---|---|---|---|---|
| RAID 0 | 32.0 TB | 100% | 0 | 1× | Scratch space, render caches, anything reproducible |
| RAID 1 | 4.00 TB | 13% | 7 | 2× | Boot volumes, hypervisor OS drives, small critical datasets |
| RAID 5 | 28.0 TB | 88% | 1 | 4× | General file and VM storage on drives under ~4 TB |
| RAID 6 | 24.0 TB | 75% | 2 | 6× | Bulk storage, backup targets, any array of large drives |
| RAID 10 | 16.0 TB | 50% | 1 | 2× | Databases, busy virtualization hosts, write-heavy workloads |
| RAID 50 | 24.0 TB | 75% | 2 | 4× | Large RAID 5 arrays that have outgrown a single group |
| RAID 60 | 16.0 TB | 50% | 4 | 6× | High-capacity archives and backup arrays, 16 drives and up |
| JBOD | 32.0 TB | 100% | 0 | 1× | ZFS, Ceph, Hadoop, and other software-defined storage |
What each level does with your drives, the minimum it needs, and the workload it suits. Write penalty is the number of physical I/Os per random write — the figure that decides whether a level can carry a database.
Striping
Stripes data across every drive with no redundancy. Fastest and cheapest per terabyte, and the only level where a single failure destroys the whole array.
Mirroring
Every drive holds an identical copy. Reads scale with the mirror count, rebuilds are a straight copy, and capacity is whatever one drive holds.
Striping with single parity
One drive worth of parity distributed across the set. Good capacity efficiency, but a rebuild reads every remaining drive end to end — the window where a second failure or an unrecoverable read error takes the array with it.
Striping with dual parity
Two drives worth of parity, so the array survives a second failure during a rebuild. The default for large-capacity arrays, at the cost of the heaviest write penalty here.
Striped mirrors (1+0)
Mirrored pairs, striped together. Half the capacity, but the best random-write performance of any redundant level and the fastest rebuild, because rebuilding reads one surviving drive instead of the whole array.
Striped RAID 5 groups (5+0)
Several RAID 5 groups striped together. Shortens rebuilds and raises throughput versus one wide RAID 5, and each group still tolerates only one failure.
Striped RAID 6 groups (6+0)
Several RAID 6 groups striped together — dual parity per group with shorter rebuild windows. The standard shape for very large arrays of high-capacity drives.
Independent drives / spanning
No RAID at all: each drive is presented on its own. What ZFS, Ceph, and most scale-out filesystems want, because they handle redundancy themselves.
A parity rebuild reads every surviving drive from end to end while the array is still serving traffic. On 16 TB nearline drives that is measured in days, and the array is degraded for all of it. Dual parity, more RAID groups, or mirrored levels all shorten or survive that window; a bigger drive count on a single RAID 5 does the opposite.
A hardware controller with write-back cache and no battery or flash backup will happily acknowledge writes it has not committed. Pair write-back with a BBU or FBWC module, or run write-through and accept the penalty — the middle option is where silent corruption after a power loss comes from.
A 3.5-inch LFF chassis buys capacity per dollar; 2.5-inch SFF bays buy spindles and therefore IOPS. Decide the level and drive count first, then pick the chassis that holds them with room for the hot spare and a year of growth — retrofitting bays costs far more than buying them up front.
Know the array you want? Configure the server and pick the controller, drive bays, and disks with live pricing.
Start from the drives in the array, not the drives in the chassis — hot spares hold no data. RAID 0 and JBOD give you all of them; RAID 5 gives you all but one; RAID 6 all but two; RAID 10 exactly half; RAID 50 loses one drive per group and RAID 60 two per group. Multiply what is left by the size of the smallest drive, because a mixed array runs at the smallest member.
Drives are sold in decimal terabytes (4 TB = 4,000,000,000,000 bytes) and most operating systems report binary tebibytes (1 TiB = 1,099,511,627,776 bytes). That alone is about 9 percent. The calculator prints both figures so you can see which number you are looking at, and filesystem metadata takes a further slice on top.
Use RAID 6 on anything with large drives. RAID 5 survives one failure, and a rebuild has to read every remaining drive from end to end; on a set of 12 TB or 16 TB drives that takes a day or more, and a second failure or an unrecoverable read error during that window loses the array. RAID 6 costs one more drive of capacity and covers exactly that window. RAID 5 is still reasonable on small, fast drives with a hot spare and a tested backup.
It is how many physical I/Os the controller performs for one random write. RAID 0 and JBOD are 1. Mirrored levels — RAID 1 and RAID 10 — are 2, one write per copy. RAID 5 is 4 because the controller must read the old data and parity, then write both back. RAID 6 is 6 for the same reason with a second parity block. It is why a database on RAID 6 can feel slow even when the raw drive count looks generous.
Multiply the drive count by the random IOPS of one drive to get the raw figure, then charge reads at one I/O and writes at the write penalty. A 70/30 read/write mix on eight 150-IOPS drives is about 840 read IOPS plus 60 write IOPS on RAID 6 — roughly 900 functional. The same drives in RAID 10 return about 1,020. Controller cache absorbs bursts and can beat these numbers briefly, but not sustained load.
On any array you would not rebuild the same day, yes. A hot spare starts the rebuild the moment a drive drops instead of when someone walks into the room, which shortens the degraded window that failures actually happen in. It costs one drive of capacity — subtract it before the RAID math, which is what the hot spare field here does.
Hardware RAID with a battery- or flash-backed cache is still the straightforward choice for a boot volume and for general VM storage, and it keeps the array invisible to the OS. ZFS and other software-defined stacks want the drives presented raw — JBOD or an HBA in IT mode — and pay you back with checksums, snapshots, and no rebuild-window write hole. Pick one: ZFS on top of a hardware RAID volume gets the drawbacks of both.
No. RAID covers drive failure, and nothing else. Deletions, ransomware, a controller that corrupts on the way in, fire, and theft all pass straight through it, and every copy in a mirror gets the bad write at the same instant. Size the array here, then budget separately for backups that live somewhere the array does not.