RAID Calculator — Usable Capacity & Fault Tolerance

RAID Levels Explained

RAID — Redundant Array of Independent Disks — is a method of combining multiple physical storage devices into a logical unit to achieve some combination of increased capacity, improved read/write performance, or fault tolerance against drive failures. The concept was formalised in a 1988 paper by Patterson, Gibson, and Katz at UC Berkeley, though the industry had been experimenting with disk arrays for years prior.

Two fundamentally different implementations exist. Hardware RAID uses a dedicated controller card (or on-board controller) with its own processor and cache. The operating system sees a single logical drive and has no knowledge of the underlying array. Hardware RAID typically delivers better performance under heavy write workloads and can survive an operating system reinstall without data loss. Software RAID is managed by the OS kernel (e.g., Linux's mdadm, Windows Storage Spaces, or macOS Disk Utility). It is free, flexible, and portable across hardware, but adds CPU load and relies on the OS running correctly to maintain array integrity.

The key tradeoffs across RAID levels are capacity efficiency (how much of your raw storage is usable), fault tolerance (how many drives can fail before you lose data), and write performance (parity-based RAID levels incur a write penalty because parity must be updated on every write).

RAID 0 — Striping

RAID 0 splits data in chunks across all drives simultaneously. A write to a 4-drive RAID 0 array writes roughly one quarter of the data to each drive in parallel. This delivers the best possible throughput of all RAID levels — sequential read and write speeds scale nearly linearly with the number of drives — while using 100% of the raw capacity.

The critical downside: RAID 0 provides zero fault tolerance. Lose any single drive and the entire array is lost, because each drive holds unique fragments of every file. With N drives, the probability of losing the array in a given time period is approximately N times the probability of losing a single drive. A 4-drive RAID 0 is roughly 4× more likely to fail completely than a single drive.

RAID 0 is appropriate for temporary scratch space, video editing proxies, rendering caches, or any workload where speed is critical and data loss is acceptable because the data can be regenerated. It is not appropriate for anything that cannot be easily recreated from source.

RAID 1 — Mirroring

RAID 1 writes identical copies of all data to every drive in the array. A two-drive RAID 1 maintains two complete copies of all data at all times. With N drives, N−1 drives can fail completely and the array remains operational — a two-drive mirror can survive one failure, a four-drive mirror can survive three.

The tradeoff is storage efficiency: a two-drive RAID 1 gives you the capacity of a single drive, regardless of how large the second drive is. Four 4 TB drives in RAID 1 yields 4 TB usable — the same as one drive. This 50% (or worse, for N > 2) efficiency makes RAID 1 expensive per usable gigabyte compared to parity-based alternatives.

Write performance matches a single drive (every write must be committed to all mirrors). Read performance can improve — many controllers and software implementations distribute reads across mirrors, effectively doubling sequential read throughput from a two-drive mirror. RAID 1 is simple, reliable, and well-understood. It is an excellent choice for operating system drives, boot volumes, and small high-value datasets where the overhead is acceptable.

RAID 5 and RAID 6

RAID 5 is the classic compromise between storage efficiency and fault tolerance. Data is striped across all drives, and a rotating parity block is distributed across the array so no single drive holds all parity. One drive's worth of capacity is consumed for parity: a 5-drive RAID 5 with 4 TB drives gives you 4 × 4 TB = 16 TB usable, storing 80% of raw capacity.

RAID 5 tolerates a single drive failure. After a failure, the array operates in degraded mode, reconstructing missing data on-the-fly from parity. This works correctly but comes at a significant read performance cost in degraded mode.

RAID 6 extends RAID 5 with double parity, using two independent parity algorithms (typically P+Q parity) to tolerate simultaneous failure of any two drives. This consumes two drives' worth of capacity: an 8-drive RAID 6 with 4 TB drives gives (8−2) × 4 TB = 24 TB usable. RAID 6 is strongly preferred over RAID 5 for arrays using large drives (4 TB and above) because of the increasing risk of a second failure during the extended rebuild window — discussed below.

Both RAID 5 and RAID 6 suffer a write penalty: every write requires reading the old data and old parity, computing new parity, then writing both. This is typically a 4-I/O read-modify-write cycle for RAID 5 and a 6-I/O cycle for RAID 6. Under random write-heavy workloads this penalty can halve effective IOPS compared to RAID 0.

RAID 10 — Stripe of Mirrors

RAID 10 (sometimes written RAID 1+0) combines mirroring and striping: drives are first paired into RAID 1 mirrors, then those mirrors are striped together in a RAID 0 configuration. A standard RAID 10 with 4 drives creates two mirrored pairs and stripes across them.

RAID 10 delivers read and write performance close to RAID 0 (because writes are striped across mirror pairs in parallel) with the fault tolerance of RAID 1 within each pair. Each mirror pair can sustain the loss of one drive independently — so in a 4-drive array, you can lose one drive from each pair (2 total) and survive, but losing both drives in the same pair destroys the array.

The storage efficiency is always 50%, regardless of drive count. The write penalty is absent: parity calculation is not involved, so writes simply go to both drives in a pair at full speed. This makes RAID 10 the preferred choice for high-write-throughput, latency-sensitive applications such as databases and transactional storage, when budget allows for the 50% overhead. A minimum of 4 drives is required, and the drive count must always be even.

Write Penalty and Rebuild Time

The write penalty for parity-based RAID (levels 5 and 6) is well-known, but the rebuild risk is less discussed and arguably more dangerous.

When a drive fails in a RAID 5 or RAID 6 array, the controller must reconstruct the missing data by reading every remaining drive in the array and computing the lost data from parity. On a 6-drive RAID 5 array with 4 TB drives, a rebuild requires reading approximately 20 TB of data (the entire capacity of the remaining five drives). At a sustained read rate of 150 MB/s — realistic for mechanical drives under the mixed load of serving I/O plus rebuilding — that rebuild takes roughly 37 hours.

During those 37 hours, the array is in degraded mode with no redundancy remaining (for RAID 5). The stress of a full sequential read across all drives during an already-stressful event significantly elevates the probability of a second drive failing. More worryingly, large drives accumulate Unrecoverable Read Errors (UREs) — the specification for most enterprise SATA drives is 1 URE per 10¹⁴ bits read (approximately 12.5 TB). When rebuilding a 4 TB drive from a 20 TB array read, there is a non-trivial probability of encountering a URE on another drive. A URE during rebuild causes RAID 5 to fail completely, with no data recovery possible without backups.

RAID 6's double parity means a single URE during rebuild does not destroy the array — the second parity can cover it. This is the primary technical argument for preferring RAID 6 over RAID 5 on arrays with drives larger than 2–3 TB. For arrays with eight or more large drives, RAID 6 should be considered the minimum acceptable parity configuration.

RAID vs ZFS and Btrfs

Traditional RAID controllers and software RAID (mdadm) operate at the block level — they do not understand the data stored on the array. This creates a class of problem that RAID cannot detect: silent data corruption, sometimes called "bit rot." A drive may return incorrect data due to a marginal sector, firmware bug, or cosmic ray event without triggering any error detectable by traditional RAID.

ZFS and Btrfs are modern copy-on-write filesystems that integrate storage management and filesystem concerns. Every data block is checksummed at write time. On every read, the checksum is verified. If a corruption is detected, ZFS can automatically repair it from a mirror or parity copy — even one that appears healthy at the block level. This makes ZFS and Btrfs far more effective at preventing silent data corruption than traditional RAID.

ZFS raidz1 (equivalent to RAID 5), raidz2 (RAID 6), and raidz3 (triple parity) offer similar capacity efficiencies with end-to-end data integrity. ZFS also brings features like atomic snapshots, send/receive replication, compression, and deduplication. Btrfs offers a similar feature set on Linux with native RAID 1, 5, and 6 support, though its RAID 5/6 implementation has historically had stability concerns and should be researched carefully before production use.

For new deployments where the operating environment supports it, ZFS (on Linux via OpenZFS, or natively on FreeBSD and TrueNAS) is generally preferred over traditional RAID for any storage that matters. Traditional RAID remains relevant in environments with existing infrastructure, hardware RAID controllers with large battery-backed caches, or where ZFS's memory requirements (typically 1–2 GB RAM per TB of storage for ARC) are prohibitive.

Critically: RAID is not a backup. RAID protects against drive failure, not against accidental deletion, ransomware, filesystem corruption, or controller failure. Any data you cannot afford to lose requires a separate backup strategy with at least one off-site or air-gapped copy.

Disclaimer

This calculator is provided for planning and educational purposes. Real-world usable capacity may differ from calculated values due to filesystem overhead, drive formatting, manufacturer's definition of gigabyte (1 GB = 10⁹ bytes vs 1 GiB = 2³⁰ bytes), and controller or driver behaviour. RAID level suitability depends on your specific workload, hardware, and recovery time objectives. Always maintain tested backups independent of your RAID configuration. The authors accept no liability for data loss arising from reliance on these calculations.