RAID discussions tend to be tables of levels memorized for exams. More useful: three primitive ideas — stripe (split data across disks for speed), mirror (copy it for safety), parity (compute redundancy for safety at lower cost) — plus the failure arithmetic that decides which composition survives contact with real disks. The arithmetic has changed as disks grew; some of the standard advice died with it, and my homelab’s array choices got re-derived the hard way.

The Primitives and the Parity Trick

RAID 0 stripes (N× throughput, and N× the failure rate — any death is total). RAID 1 mirrors (write twice, read from either, survive N−1 deaths, pay 50%+ capacity). Parity is the clever one: RAID 5 stores, per stripe, the XOR of the data chunks (rotated across disks to spread load):

text
  P = D1 ⊕ D2 ⊕ D3      lose any single disk:
  D2 = D1 ⊕ D3 ⊕ P      recompute it from the survivors

One disk of capacity buys survival of one failure. RAID 6 adds a second, differently-computed syndrome (Reed–Solomon over GF(2⁸), not just XOR) to survive two. The composition everyone actually deploys for performance-critical arrays is RAID 10 — stripe across mirrors — buying fast rebuilds and good random-write behavior at mirror prices.

Parity’s hidden operational cost is the partial-stripe write: to update one 4 KB chunk, read old data + old parity, XOR out, XOR in, write both — a 4-I/O penalty per small random write (6 for RAID 6). Parity arrays are lovely for sequential/streaming loads and rough on random-write databases; that single fact routes workloads to RAID 10 more reliably than any benchmark.

The Math That Killed Casual RAID 5

Disks quote an unrecoverable read error rate — consumer drives traditionally 1 URE per 10¹⁴ bits ≈ one bad sector per ~12.5 TB read. Now run a rebuild: one disk dead, and the array must read every surviving byte to reconstruct it. On an array with 30+ TB of survivors, hitting ≥1 URE during rebuild approaches coin-flip-or-worse odds — and a classic hardware RAID 5 hitting an URE mid-rebuild declares the second disk failed and takes the array with it. The folklore rule (“RAID 5 died in 2009”) overstates slightly — enterprise drives quote 10¹⁵, real-world URE behavior is lumpier than spec — but the direction is right, and it’s why RAID 6/RAIDZ2 became the floor for big-disk arrays, why rebuild windows (a day+ for 20 TB drives, running degraded and slow throughout) dominate modern designs, and why declustered/distributed rebuild schemes (draid, Ceph) exist: rebuild speed is now a first-class reliability parameter, because the danger window is the rebuild.

Two more failure modes the brochure skips. The write hole: a power cut between writing data and its parity leaves the stripe silently inconsistent — classic hardware RAID answers with battery-backed cache; mdraid with a journal/bitmap; ZFS dodges it structurally (copy-on-write full-stripe writes, hence “RAIDZ has no write hole”). And silent corruption: plain RAID verifies nothing on read — parity is only consulted on known failure, so bit rot returns confidently wrong data. Regular scrubs (echo check > /sys/block/md0/md/sync_action; zpool scrub) catch it late; checksumming filesystems (ZFS/Btrfs) catch it on every read and heal from redundancy — which is most of the argument for letting the filesystem own the disks instead of a RAID card.

And the sentence that belongs in every storage doc: RAID is availability, not backup. It protects against disk hardware death and nothing else — rm -rf, ransomware, filesystem bugs, controller failure, fire: all replicate instantly to every disk. Snapshots + off-machine copies (3-2-1) address a disjoint threat model; arrays and backups answer different questions and you need both answers.

Takeaways

  • Three primitives (stripe/mirror/parity) compose all levels; RAID 10 for random-write latency, RAID 6/Z2 for capacity at big-disk sizes.
  • Parity charges 4–6 I/Os per small random write — route databases accordingly.
  • URE × rebuild-read-volume math retired single-parity for large arrays; the rebuild window is the real risk metric now.
  • Mind the write hole (journal/BBU/ZFS-CoW) and scrub monthly — unverified redundancy rots silently.
  • RAID answers “a disk died”; backups answer everything else. Have both, test both.