# RAID: What It Protects, What It Doesn't, and the URE Math

> RAID levels are three ideas — stripe, mirror, parity — composed. The interesting parts are the failure math: why RAID 5 rebuilds fail at modern disk sizes, what the write hole is, and why RAID is not backup, mathematically.

URL: https://harshith.in/blog/raid-what-it-does-and-doesnt/
Author: Harshith Sunku (Staff Engineer) — https://harshith.in/about/
Tags: systems, filesystems, hardware

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.