Three separate deductions stand between the box and the volume
Buy six 8 TB drives and you have 48 TB in your hand. What the operating system offers you is smaller for three independent reasons, and confusing them is the reason so many storage builds come up short.
Redundancy is the largest deduction and the intentional one. RAID 6 keeps two drives' worth of parity, so six drives give the capacity of four: 32 TB. RAID 10 keeps a full second copy, so half of everything you buy is a mirror. RAID 0 keeps nothing, which is why it is not really RAID at all in the sense the acronym intends.
Unit conversion is the deduction nobody chose. Drives are sold in decimal terabytes, where 1 TB is 1012 bytes, but most filesystems and Windows report tebibytes, where 1 TiB is 240 = 1,099,511,627,776 bytes. The ratio is 1.0995, so 32 TB becomes 29.10 TiB. Nothing has been lost; the yardstick changed.
Filesystem overhead is the smallest and most variable. Inode tables, journals, superblock copies and reserved blocks all consume space before you write a single file. About 5% is typical for ext4 at defaults. Copy-on-write filesystems such as ZFS and Btrfs need more than that kept free rather than merely allocated — 10–20% is the usual guidance — because their allocation strategy degrades badly when a pool approaches full.
This calculator applies all three, in that order, and reports the intermediate values so you can see which deduction is costing you what.
Why each level has the capacity formula it does
Every RAID level reduces to a count of data-bearing drive equivalents. Multiply that count by the drive size and you have the usable capacity.
RAID 0 stripes data across all n drives with no redundancy, so all n carry data. RAID 1 writes the same data to every member, so the array holds one drive's worth however many mirrors you add. RAID 10 is a stripe of mirrored pairs: half the drives hold copies, so capacity is n/2.
RAID 5 computes a parity block as the XOR of the data blocks in each stripe and distributes those parity blocks across all members. Because exactly one block per stripe is parity, the array loses exactly one drive's worth of capacity regardless of width — hence (n − 1). RAID 6 adds a second, algebraically independent syndrome (typically Reed-Solomon over a Galois field rather than a second XOR, because a second XOR would carry no new information), so it loses two drives' worth: (n − 2).
RAID 50 and 60 stripe across several RAID 5 or RAID 6 groups. Each group pays its own parity cost, so with g groups the deductions are g and 2g drives respectively. Nested levels trade capacity for rebuild time: a failure only rebuilds within its own group, so the read load and the exposure window shrink with group size.
Single-parity JBOD schemes such as unRAID and SnapRAID dedicate whole drives to parity rather than distributing it, and do not stripe. Capacity is the sum of the data drives, which for equal-sized drives is the same (n − 1) as RAID 5, but the failure behaviour differs: because each data drive holds a complete filesystem, losing more drives than you have parity for costs you only the data on those drives rather than the whole array.
Fault tolerance is the guaranteed number, not the lucky one. RAID 10 survives one failure guaranteed and often survives more — up to one per mirror pair — but a second failure that lands on the partner of the first destroys the array. Report and plan on the guarantee.
Worked example: six 8 TB drives in RAID 6 with a 5% reserve
A six-bay NAS, six 8 TB drives at $150 each, RAID 6, no hot spare, ext4 at defaults.
- Raw purchased capacity. 6 × 8 = 48 TB.
- Data-bearing equivalents. RAID 6 loses two drives to parity: 6 − 2 = 4 drives.
- Usable before formatting. 4 × 8 = 32 TB.
- Apply the filesystem reserve. 32 × (1 − 0.05) = 30.4 TB.
- Convert to the unit the OS shows. 30.4 × 1012 ÷ 240 = 27.65 TiB.
- Storage efficiency. 30.4 ÷ 48 = 63.3%. Against the pre-format 32 TB it is 66.7%, which is the figure the parity arithmetic alone gives.
- Cost per usable terabyte. 6 × $150 = $900, ÷ 30.4 TB = $29.61 per usable TB.
- Fault tolerance. Two simultaneous drive failures, guaranteed.
Now compare against the alternatives with the same six drives. RAID 5 gives (6 − 1) × 8 = 40 TB before formatting, 25% more capacity, and survives one failure. RAID 10 gives 6 ÷ 2 × 8 = 24 TB, 25% less, and also guarantees only one failure — but rebuilds by copying a single mirror partner rather than reading every surviving drive, which is why it remains the choice for write-heavy databases.
The RAID 5 option deserves the arithmetic that argues against it. Rebuilding a failed drive in a six-wide RAID 5 of 8 TB members requires reading all 40 TB of the surviving members, which is 3.2 × 1014 bits. Consumer drive datasheets typically quote an unrecoverable read error rate of one per 1014 bits, so the expected number of read errors during that rebuild is about 3.2. Enterprise drives quote one per 1015, which brings the expectation to 0.32. That single calculation is why RAID 5 fell out of favour as drive capacities passed a few terabytes, and it is worth doing for your own drives with your own datasheet figure.
How to read the result
Efficiency and resilience trade against each other along a known curve. RAID 0 is 100% efficient and survives nothing. RAID 10 is 50% efficient and rebuilds fastest. Parity levels sit in between, and their efficiency improves as the array widens — RAID 6 across six drives is 67% efficient, across twelve it is 83%. Widening also lengthens rebuilds and raises the chance that a second drive fails during one, which is the argument for nested levels on large arrays.
Cost per usable terabyte is the number to compare configurations with, not cost per drive. Larger drives almost always win on this metric until you reach the price premium at the top of the range, and a wider array of smaller drives usually loses to a narrower array of larger ones once you count enclosure slots and power.
Guaranteed fault tolerance of 1 means you are exposed during every rebuild. On multi-terabyte drives a rebuild takes hours to days, and the array is unprotected for that whole period while running at its heaviest read load of the year. If the data matters, either pick a dual-parity level or keep a hot spare so the rebuild starts without waiting for a human.
None of this is a backup. RAID protects against drive failure and nothing else. It does not protect against deletion, ransomware, filesystem corruption, controller failure, fire or theft, and a mirrored array replicates a bad write to both copies instantly. Keep separate backups with at least one offline or off-site copy.
RAID level reference
| Level | Minimum drives | Usable capacity | Failures survived | Write penalty | Typical use |
|---|---|---|---|---|---|
| RAID 0 | 1 | n × d | 0 | 1 | Scratch space, render caches |
| RAID 1 | 2 | d | n − 1 | 2 | Boot volumes, small critical sets |
| RAID 5 | 3 | (n − 1) × d | 1 | 4 | Read-heavy bulk storage, smaller drives |
| RAID 6 | 4 | (n − 2) × d | 2 | 6 | Archives and NAS on large drives |
| RAID 10 | 4 | n × d ÷ 2 | 1 guaranteed | 2 | Databases, virtualisation, write-heavy work |
| RAID 50 | 6 | (n − g) × d | 1 guaranteed | 4 | Wide arrays needing shorter rebuilds |
| RAID 60 | 8 | (n − 2g) × d | 2 guaranteed | 6 | Very wide arrays of large drives |
| Single-parity JBOD | 2 | (n − 1) × d | 1 | varies | Home media servers with mixed drive sizes |
Write penalty is the number of physical I/O operations per logical write, used for IOPS sizing rather than capacity. Guaranteed tolerance is the worst case; RAID 10 and nested levels often survive more failures if they land in different mirrors or groups.
Mixed drive sizes strand capacity
Traditional RAID levels treat every member as if it were the size of the smallest one. Put a 4 TB drive into an array of 8 TB drives and every member contributes 4 TB, stranding half of each larger drive. Only a few schemes avoid this: unRAID and SnapRAID allow mixed sizes provided the parity drive is at least as large as the biggest data drive, and Synology SHR and BTRFS/ZFS with unequal vdevs can use part of the excess. If you plan to grow an array by replacing drives one at a time, check whether your controller expands the array after the last small member is replaced — many do, but not automatically.
Mistakes that make a capacity plan wrong
- Comparing a TB purchase against a TiB requirement. A 20 TiB requirement needs 22 TB of decimal capacity, not 20. The gap is 9.95% at the terabyte scale and it grows with the exponent.
- Counting hot spares as usable. A spare is a drive you have paid for and cannot write to. It buys rebuild speed, not space.
- Filling a ZFS or Btrfs pool past about 80%. Copy-on-write allocators need free space to write efficiently; performance falls off sharply near full, and on some versions the pool becomes very difficult to free.
- Assuming parity overhead scales with array width. It does not — RAID 6 always costs two drives, whether the array has 4 members or 24. That is why efficiency improves as arrays widen, and why the argument against wide arrays is rebuild exposure rather than capacity.
- Sizing on capacity alone when the workload is transactional. A parity array with enough terabytes can still be far too slow, because every small write costs four or six physical operations. Size that with the RAID IOPS calculator before you commit.
- Treating RAID as a backup. It is an availability mechanism for drive failure. Deletion, corruption and ransomware propagate to every member at once.
Beyond classic RAID: erasure coding and pool layouts
Classic RAID levels are a special case of erasure coding, which generalises the idea to k data fragments plus m parity fragments spread across nodes as well as drives. Object stores and scale-out filesystems — Ceph, MinIO, Azure and AWS internals — use schemes such as 8+3 or 10+4, where efficiency is k/(k+m) and tolerance is m. The capacity arithmetic on this page is exactly the same idea: RAID 5 is (n−1)+1 and RAID 6 is (n−2)+2.
ZFS deserves its own note because its terminology differs. A RAID-Z1 vdev behaves like RAID 5, RAID-Z2 like RAID 6 and RAID-Z3 adds a third parity device. Capacity follows the same (n − p) × d rule, but ZFS's variable stripe width means the effective overhead on small files can exceed the nominal parity ratio, and pools are built from multiple vdevs whose capacities add. Plan a ZFS pool one vdev at a time, then sum, rather than treating all drives as a single array.
Once capacity is settled, two other questions usually follow. Whether the array can deliver the transaction rate the application needs is a separate calculation entirely, because parity layouts multiply every small write — the RAID IOPS and write penalty calculator handles it. Whether the array will be available when you need it is a reliability question: combine your drive vendor's MTBF figure with a realistic replacement time in the MTBF, MTTR and availability calculator to see what your rebuild policy is actually worth. And if the data is destined for or replicated to a cloud provider, the transfer window follows from your link speed — the Mbps to MB/s converter turns terabytes into hours.