Drives fail. Not "might fail eventually" in some abstract sense, but on a schedule you can count on if you run enough of them for long enough. Put a database, a hypervisor, or a media library on a single disk and you have wired a coin flip to your uptime. RAID (Redundant Array of Independent Disks) is how you stop that: you group several drives into one logical volume and spread the data across them so the array survives a dead disk, runs faster, or both.
The catch is that every RAID level trades those three things off differently. More redundancy costs you capacity. More speed can cost you safety. The RAID Calculator does the arithmetic for each layout so you can see usable capacity, fault tolerance, and efficiency side by side before you buy a single drive. This guide explains what those numbers mean.
The three things you are balancing
Any storage design is pulling against three constraints at once: how much space you actually get to use, how fast reads and writes are, and how many drives can die before the data is gone. No single RAID level maxes out all three, which is the whole reason there are several. Below, N is the number of drives and S is the size of the smallest drive in the set (mismatched drives get leveled down to the smallest).
The common RAID levels
RAID 0 (striping)
Data is split evenly across two or more drives with no redundancy at all. Usable capacity is the full N x S and read/write speed scales with the drive count, which is the appeal. Fault tolerance is zero: lose one drive and the whole array is gone. Use it for scratch space where speed is everything and the data is disposable, like video render caches, not for anything you would miss.
RAID 1 (mirroring)
An exact copy of the data is written to two or more drives. Usable capacity is just S no matter how many drives you add, so efficiency is low, but a two-drive mirror keeps running after one failure. This is the classic choice for OS boot volumes and small, write-reliable nodes where the dataset is modest and you care more about staying up than about squeezing out capacity.
RAID 5 (striping with distributed parity)
Data and parity are striped across three or more drives, with the parity spread evenly rather than parked on one disk. If a drive dies, the controller rebuilds the missing data from parity. Usable capacity is (N-1) x S and the array tolerates exactly one failure. It is a sensible balance for general-purpose file servers and NAS boxes, with one caveat worth taking seriously (more on rebuilds below).
RAID 6 (striping with dual parity)
RAID 6 is RAID 5 with a second, independent parity block computed with Galois-field math, so it needs at least four drives. Usable capacity is (N-2) x S and it survives two simultaneous failures. That second parity block earns its keep on large arrays built from high-density drives, where rebuilds take so long that a second failure during the rebuild is a real risk rather than a theoretical one.
RAID 10 (mirrored stripes)
RAID 10 stripes across mirrored pairs, combining RAID 1's redundancy with RAID 0's speed. It needs a minimum of four drives in an even number. Usable capacity is (N / 2) x S, so you give up half your raw space, but you get fast writes and quick rebuilds because recovery only copies one mirror rather than recomputing parity across the whole set. It tolerates at least one failure per mirror pair, up to N/2 in the lucky case. This is the go-to for busy databases and virtualization hosts.
Hot spares and the window of vulnerability
A hot spare is a drive sitting in the enclosure, powered on but idle. When the controller sees a failure, it pulls the spare in and starts rebuilding on its own, no one has to drive to the datacenter at 2 a.m. It costs you one drive's worth of usable capacity (effectively N-1), but it shrinks the dangerous stretch where the array is running degraded and one more failure means data loss. On arrays you cannot babysit, that trade is usually worth it.
What the calculator reports
For any layout you enter, the tool breaks out:
- Raw capacity — the sum of every physical drive,
N x S. - Usable capacity — what is left after mirroring or parity overhead.
- Overhead / parity loss — the space redundancy consumes.
- Efficiency — usable divided by raw, as
E = (C_usable / C_raw) x 100%. - Fault tolerance — how many drives can fail before the data is gone.
Here is how the same eight 4TB drives (32TB raw) shake out across four levels:
| RAID level | Usable | Overhead | Efficiency |
|---|---|---|---|
| RAID 0 | 32.0 TB | 0.0 TB | 100.0% |
| RAID 10 | 16.0 TB | 16.0 TB | 50.0% |
| RAID 5 | 28.0 TB | 4.0 TB | 87.5% |
| RAID 6 | 24.0 TB | 8.0 TB | 75.0% |
A worked example: sizing a SAN for VMs
Say you are speccing a SAN to host 50 VMs for a regional hospital. The budget covers eight 10TB enterprise SAS drives, so 80TB raw. Run the three realistic candidates through the calculator:
- RAID 5 → 70TB usable (87.5%), survives 1 failure.
- RAID 6 → 60TB usable (75%), survives 2 failures.
- RAID 10 → 40TB usable (50%), survives at least 1 per mirror pair.
RAID 5 looks tempting on capacity alone, but there is a trap in it. Rebuilding a failed 10TB drive can run for days, and hammering the seven surviving drives that hard often surfaces an unrecoverable read error or a second failure mid-rebuild, which on RAID 5 wipes every VM. For an array this size you drop RAID 5 and take RAID 6, or reach for RAID 10 if the workload is write-heavy databases. Either way you trade 10TB of space for the ability to lose a second drive and keep going.
Where to start
Decide what you cannot afford to lose first, then let capacity fall out of that. If the data is disposable, RAID 0. If it is a boot volume, RAID 1. For a general file server, RAID 5 or, on big drives, RAID 6. For transactional databases and hypervisors, RAID 10. Plug your real drive count and size into the RAID Calculator to see the exact numbers, and if you are planning the surrounding infrastructure, the Transfer Time Calculator will tell you how long moving that data will actually take and the Subnet Calculator helps lay out the network in front of it.