Don't Panic — RAID

RAID is a way to make several disks behave like one block device while arranging data so that some member failures do not immediately turn into a storage obituary. Before that arrangement, a disk was one disk and its failure was a very short meeting with a very long consequences list. RAID divides data into chunks, then decides where those chunks and their redundancy belong.

The three useful verbs are striping, mirroring, and parity. Striping spreads chunks across members. Mirroring keeps extra copies. Parity keeps reconstruction information instead of a complete extra copy. RAID 0 stripes without redundancy, RAID 1 mirrors, RAID 5 and RAID 6 distribute parity, and RAID 10 stripes across mirrored pairs. The names are compact. The consequences, regrettably, are not.

A RAID level is a layout, not a promise that every storage concern has been packed into a reassuring acronym. Equal-size members still lose usable capacity to the chosen layout; the smallest member limits larger ones; and filesystem overhead arrives afterward with impeccable timing. Controller cache, chunk size, implementation, and failure domains also influence what the array actually does.

When a member fails, the array may enter degraded state: it still serves data from a mirror or reconstructs missing data from parity, but it has spent part of its safety margin. A rebuild writes reconstructed data to a replacement or spare. It consumes bandwidth and can raise latency, so the interesting test is not only whether the healthy array is fast. It is whether the service behaves acceptably while recovery is happening.

The surprise is that restored redundancy is not restored truth. A completed rebuild says the layout again has the members it expects. It does not reverse deletion, corruption, ransomware, controller defects, or a carefully replicated mistake. That is why RAID is about availability after selected member failures, while backups need an independent boundary and a tested restore. Storage has room for more than one safety net; it is annoyingly skilled at finding the gap between them.

Read the intro for the full request path and the limits of each layout. Use the slides to follow a request from chunks to failure and rebuild. Keep the cheatsheet nearby for capacity, parity-write, state, and replacement checks. The reference tab then moves from this mental map to the exact behavior of Linux MD and LVM RAID, where device names become real and therefore deserve suspicion.