RAID: Explanation & Insights

Multiple disks, one idea: no single drive should be able to ruin your day.

What It Is

RAID stands for Redundant Array of Independent Disks, and the name is the whole philosophy in five words. Instead of trusting your data to one disk — one set of spinning platters, one set of flash cells, one controller, one cable, one single point of failure — you spread it across several, arranged so that any one of them can die and the show goes on. The server doesn't reboot, the database doesn't hiccup, the users don't notice. You get an alert, you swap the dead drive, the array rebuilds itself, and you go back to your coffee. That's the promise, and on a well-configured server it delivers, year after year, drive after drive.

If you're new to running servers, there are two things worth knowing right at the top. First: disks fail. Not might, not occasionally — will, on a schedule set by physics, and the more disks you run the sooner one of them proves it. A single bare-metal server with four drives will, statistically, lose one within a few years. A rack of twenty servers is losing drives every few months. This is not bad luck; it's the arithmetic of spinning metal and aging silicon, and it's the entire reason RAID was invented. Second: RAID is not a backup. It protects you against a dead disk; it does nothing against rm -rf, a bad deploy, ransomware, or a fire — every one of which it faithfully mirrors to all your drives at once, instantly. You need both. Backup saves you from yourself; RAID saves you from your hardware.

The rest of this page goes deep. We'll walk through every RAID level you'll encounter in the real world, show you exactly how to inspect and manage arrays with mdadm and /proc/mdstat, and — the part that makes it all stick — explain the actual maths that lets four disks survive as three. By the end you'll understand RAID well enough to choose a level for a new server, diagnose a degraded array without panic, and hold your own in the conversation when the datacenter calls about a failed member.

Why Every Server Should Have It

The argument for RAID on a server is simple arithmetic. A modern disk has an annualised failure rate (AFR) somewhere between 0.5% and 3%, depending on the model, the age, and how hard you work it. That sounds low — until you remember that a server runs 24/7, that you probably have more than one disk, and that "2% per year" over four disks and five years is not a small number. The question isn't if you'll lose a disk. It's when, and whether you'll be ready.

Without RAID, a single disk failure means downtime, data loss, or both. The server stops serving, you restore from backup (you do have a backup, right?), you lose whatever happened between the last backup and the failure, and your weekend is gone. With RAID, a single disk failure means an alert, a swap, and a rebuild — no downtime, no data loss, no weekend lost. The cost is one extra disk (for a mirror) or the equivalent of one disk's capacity (for parity). It's the cheapest insurance in all of computing, and there is no good reason to run a server without it.

The one exception is a truly stateless box that can be rebuilt from scratch in minutes — a container host with no local state, an ephemeral CI runner. Even there, the boot disk is usually a mirror, because rebuilding from scratch is only painless if you planned for it.

The RAID Levels

There are more RAID levels than anyone needs, but in practice you'll encounter five. Here they are, from the simplest to the one you actually want on a big server.

RAID 0 — Striping (No Redundancy)

RAID 0 is the odd one out: it has the word "redundant" in its name and provides none. It splits data across two or more disks in alternating stripes — block 1 on disk A, block 2 on disk B, block 3 on disk A — so reads and writes can happen in parallel. You get roughly N× the throughput of a single disk, and you get the combined capacity of all disks. The price is that any single disk failure destroys the entire array. Not degrades it, not limps it — destroys it. Every disk is load-bearing for every file.

RAID 0 has its place: scratch space for video editing, temporary build artifacts, benchmarks that need raw speed and don't care about the data. But on a server that stores anything you'd miss? No. RAID 0 is a bet that no disk will fail, and it's a bet you will eventually lose. If you're running RAID 0 on a production server right now, stop reading and go fix that first. This page will still be here when you get back.

RAID 1 — Mirroring

RAID 1 is the one everybody understands instinctively: two disks (or more, though two is the norm), each holding an identical copy of every byte. Write a block and it goes to both; lose one disk and the other is a complete, working copy of your data, no reconstruction required. The array drops the dead half and keeps serving reads from the survivor without missing a beat.

The cost is honest and obvious: you buy two disks and get the capacity of one. You're paying for a spare tyre that's already mounted and spinning. Read performance actually improves (the array can read from either disk), but write performance is unchanged — every write must land on both.

RAID 1 is the default choice for boot disks and small servers. It's simple, fast to rebuild (just a block-for-block copy), and there's nothing that can go subtly wrong with "copy this disk to that one." Most servers you'll ever touch boot from a two-disk RAID 1 mirror — including the ones running RAID 5 or 6 for their data. It's also the level that lets you do the bar trick of pulling a running disk out of a live server, booting it standalone in another machine, and having it just work. (Don't try this in production. But it does work, and there's something deeply satisfying about that.)

RAID 5 — Distributed Parity

RAID 5 is where the cleverness starts, and where most medium-sized servers live. It needs at least three disks and survives exactly one failure — like RAID 1, but without paying the 50% capacity tax. Instead of keeping a full second copy, RAID 5 keeps a much smaller insurance policy: parity, distributed across all the disks. We'll explain the actual maths in How Parity Works below — for now, the headline is that XOR, one of the simplest operations in computing, lets any single missing disk be recomputed from the others.

The capacity you get is (N-1) × disk size — so four 2 TB disks give you 6 TB of usable space (three disks of data, one disk's worth of parity scattered across all four). That's 75% efficiency, versus 50% for RAID 1. The catch is that RAID 5 survives exactly one failure and no more. A second disk dying during a rebuild — and rebuilds hammer the survivors hard, which is exactly when a tired sibling likes to give up — means the array is gone and your data with it. This is the scenario that keeps storage engineers up at night, and it's the entire reason RAID 6 exists.

Warning

On very large disks (4 TB and above), a RAID 5 rebuild reads every sector on every surviving disk. At those sizes, the probability of hitting an unreadable sector during the rebuild is uncomfortably high — high enough that many storage guides now recommend RAID 6 instead of RAID 5 for any array with disks above 2 TB. The bigger your disks, the longer the rebuild, the wider the danger window.

RAID 6 — Double Parity

RAID 6 is RAID 5's answer to the "what if two disks die at once" question. It needs at least four disks and keeps two independent parity calculations — one is the familiar XOR, the other uses Reed–Solomon codes (the same Galois-field maths that protects your Blu-ray discs and QR codes). Two sets of parity means two simultaneous failures and the data is still intact.

Capacity is (N-2) × disk size — four 2 TB disks give you 4 TB (two disks of data, two disks' worth of parity). Less efficient than RAID 5, but the safety margin is worth it for large arrays. A single disk failure in RAID 6 leaves you at roughly the same safety level as a healthy RAID 5 — still one disk of parity left, still operational, still protected against one more failure. That breathing room is the whole point.

RAID 6 is the right choice for large storage arrays — anything with more than four disks, anything with disks above 2 TB, anything where a rebuild takes hours and a second failure during that window would be catastrophic. The write penalty is slightly higher than RAID 5 (two parity blocks to compute instead of one), but on modern hardware you'd never notice.

RAID 10 — Mirrored Stripes

RAID 10 (sometimes written RAID 1+0) combines two ideas: mirror pairs for safety, then stripe across the pairs for speed. Four disks become two mirror pairs, and data is striped across the pairs. Each pair tolerates one failure independently — the array only dies if both halves of the same pair go down, which requires a specific bad-luck combination rather than just "any two disks."

Capacity is 50% of the raw total (same as RAID 1 — you're mirroring), but performance is excellent: reads fan out across all disks, writes only need to hit two (a pair). Rebuilds are fast because only the mirror partner needs to be copied, not the whole array. RAID 10 is the classic choice for databases — MySQL, PostgreSQL, anything with heavy random I/O where latency matters more than capacity. It's also simple to reason about: each pair is just a RAID 1 mirror, and the stripe is just RAID 0 across them. No parity maths, no XOR, no Galois fields — just copies and stripes.

At a Glance

Level	Min Disks	Usable Capacity	"Wasted"	Failures Survived	Best For
RAID 0	2	100% (N disks)	0%	0 — any disk kills it	Never on a server
RAID 1	2	50% (1 disk)	50%	1 disk	Boot disks, small servers
RAID 5	3	(N−1)/N — e.g. 75% with 4 disks	1 disk	1 disk	Medium servers, general data
RAID 6	4	(N−2)/N — e.g. 67% with 6 disks	2 disks	2 disks	Large arrays, big disks
RAID 10	4	50% (N/2 disks)	50%	1 per mirror pair	Databases, heavy random I/O

The "wasted" column is the price of sleep. RAID 1 and 10 cost you half your disks; RAID 5 and 6 cost you one or two disks' worth regardless of array size — so the bigger the array, the better the efficiency. RAID 0 wastes nothing and protects nothing; as a philosophy it's "I'll deal with it when it happens," which on a server means "I'll deal with it at 3 a.m."

Choosing a Level

There's no universal right answer, but there is a cheat sheet:

Boot disk: RAID 1 mirror, two disks. Simple, fast, foolproof.
Small server (2–4 disks): RAID 1 for everything, or RAID 1 for boot + RAID 5 for data.
Medium server (4–8 disks): RAID 1 for boot + RAID 6 for data. The double parity is worth the disk.
Database server: RAID 10 for the data volume. The I/O pattern demands it.
Large storage (8+ disks): RAID 6, no question. The rebuild window on large arrays is too wide for single parity.
Temporary scratch / build artifacts: RAID 0 if you truly don't care — but think twice.

How I Inspect It

Two places tell you everything about your arrays, and you read them in order: /proc/mdstat for the live state at a glance, then mdadm --detail for the full story on a specific array.

`/proc/mdstat` — The Live Scoreboard

This is the kernel's own view of every software array on the box, updated in real time. One cat and you see everything:

cat /proc/mdstat

Personalities : [raid1] [raid6] [raid5] [raid4]
md3 : active raid5 sdc4[2] sdd4[4] sdb4[1] sda4[0]
      5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

md0 : active raid1 sdb1[1] sda1[0]
      33520640 blocks super 1.2 [2/2] [UU]

Read the bottom-right corner like a status light: [4/4] means four members expected, four present; [UUUU] means all four up. The mirror below it: [2/2] [UU], two for two, both up. An underscore means a missing member: [U_] is a degraded mirror, [UUU_] is a RAID 5 down one disk. If you see a progress bar (recovery = 34.5% ...), an array is rebuilding — see RAID rebuilding. If the file is empty or missing, you have no software arrays, which is either fine (hardware RAID) or a problem (no RAID at all).

`mdadm --detail` — The Full Portrait

For the detail on a specific array — the member list, the state, the slot numbers, the serials:

mdadm --detail /dev/md0

This is the command that turns "a disk is gone" into "this disk is gone," because the device table at the bottom names every member by its /dev/sdX path and raid-slot number. A removed or faulty line is the hole. See degraded RAID for the full walk-through of reading this output.

`mdadm --examine` — Reading a Disk's Own Memory

Every RAID member carries a small metadata area (the superblock) that remembers which array it belongs to, what role it plays, and when it last synced. You can read it even on a disk that's been pulled from the array:

mdadm --examine /dev/sdb1

This is the forensic tool — useful when you've got a pile of disks and need to figure out which array each one came from, or when you're debugging a disk that was kicked out and want to know why.

Cheat Sheet

The commands you'll actually use, in roughly the order you'll need them. All assume Linux software RAID (md) managed by mdadm.

# --- Inspect ---
cat /proc/mdstat                          # live state of all arrays
mdadm --detail /dev/md0                   # full detail on one array
mdadm --examine /dev/sdb1                 # read the superblock on a member disk
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,SERIAL  # map devices to serials

# --- Create ---
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1   # RAID 1
mdadm --create /dev/md1 --level=5 --raid-devices=4 /dev/sd[abcd]2        # RAID 5
mdadm --create /dev/md2 --level=6 --raid-devices=6 /dev/sd[abcdef]3      # RAID 6
mdadm --create /dev/md3 --level=10 --raid-devices=4 /dev/sd[abcd]4       # RAID 10

# --- Persist config (survives reboot) ---
mdadm --detail --scan >> /etc/mdadm/mdadm.conf   # Debian/Ubuntu
mdadm --detail --scan >> /etc/mdadm.conf          # RHEL/CentOS
update-initramfs -u                                # rebuild initrd so it finds arrays at boot

# --- Replace a failed disk ---
mdadm /dev/md0 --fail /dev/sdb1           # mark the member as failed
mdadm /dev/md0 --remove /dev/sdb1         # remove it from the array
# (physically swap the disk, partition the new one to match)
mdadm /dev/md0 --add /dev/sdb1            # add the replacement — rebuild starts

# --- Re-add a transiently dropped member (bitmap resync, seconds not hours) ---
mdadm /dev/md0 --re-add /dev/sdb1

# --- Hot spare ---
mdadm /dev/md0 --add /dev/sde1            # extra disk auto-kicks in on next failure

# --- Scrub (find silent rot before it finds you) ---
echo check > /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt        # 0 = clean, >0 = investigate

# --- Speed tuning (during a rebuild) ---
cat /proc/sys/dev/raid/speed_limit_min    # minimum rebuild speed (KB/s)
cat /proc/sys/dev/raid/speed_limit_max    # maximum rebuild speed (KB/s)
echo 200000 > /proc/sys/dev/raid/speed_limit_min   # speed up a rebuild

# --- Stop and reassemble (rarely needed) ---
mdadm --stop /dev/md0                     # deactivate
mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1     # bring it back

# --- Mark a read-only array as read-write ---
mdadm --readwrite /dev/md0

Pro Tip

After creating or modifying an array, always run mdadm --detail --scan and save the output to your distro's mdadm.conf. Without it, the array may not assemble automatically on reboot — and discovering that at 3 a.m. after an unplanned restart is exactly the kind of surprise RAID was supposed to eliminate.

How Parity Works

This is the part that makes RAID 5 and 6 feel like a magic trick — and once you see it, you'll never forget it. The whole thing rests on one operation: XOR.

XOR: The Trick Behind Everything

XOR (exclusive or) is as simple as an operation gets. Given two bits, it returns 1 if they differ and 0 if they match:

0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0

That's it. Four cases, no carries, no remainders. Your CPU can do billions of these per second without breaking a sweat. But XOR has a property that makes the entire of RAID 5 possible: it's reversible. If you know the result and all but one input, you can recover the missing one by XOR-ing everything else together. It's the mathematical equivalent of a see-saw: if you know the weight on one side and the balance point, the other side is determined.

From XOR to Surviving a Dead Disk

Take three data disks, each holding one bit of a row: 1, 0, 1. Compute the parity: 1 XOR 0 XOR 1 = 0. Store that 0 on a fourth disk. Now four values sit across four disks:

Disk A: 1    Disk B: 0    Disk C: 1    Parity: 0

Pull any single disk out — say disk B. Can we recover its bit? XOR the remaining three: 1 XOR 1 XOR 0 = 0. And 0 is exactly what disk B held. The missing disk is recomputed from its siblings, every single read, for as long as the array is degraded. Nothing is stored; the answer is calculated on the fly, billions of times a second, from a single binary operation. That's what [UUU_] in /proc/mdstat actually means: the array is doing arithmetic on every read to fill in the disk that isn't there.

Now try losing two disks. You've got one equation and two unknowns — and XOR, for all its elegance, can only solve for one. That's the hard ceiling of RAID 5: one death, no more. Which is exactly why RAID 6 adds a second, mathematically-independent parity using Reed–Solomon codes — a different branch of algebra (Galois fields, if you want to look it up) that gives you a second equation. Two equations, two unknowns, both solvable. The same underlying trick, just with richer maths.

Why the Parity Rotates

The original design — RAID 4 — put all the parity on one dedicated disk. It worked, but that parity disk became a brutal bottleneck: every write to any data disk also had to update the parity disk, so the parity disk saw N× the write traffic of any single data disk. RAID 5 solved this with one simple twist: scatter the parity across all the disks, one stripe's parity on disk A, the next on disk B, the next on disk C, round and round. That's the left-symmetric layout you see in mdadm --detail — the rotation pattern that distributes the parity load evenly. No single disk carries the burden; every disk is part data, part insurance. It's a small idea — just rotating the assignment — but it's the one that made parity RAID practical for real workloads.

Gotchas

Things that catch people, roughly in order of how much they sting:

RAID is not a backup. Worth saying twice. RAID protects you from a hardware failure. A DROP TABLE, a ransomware encryption, a rogue find -delete — all of these get faithfully written to every disk in the array simultaneously. Your backup is what saves you from those. RAID and backup are complements, not substitutes.
Don't pull the wrong disk. Device names (/dev/sda, /dev/sdb) are assigned at boot and can reorder between reboots. Before you touch a screw, identify the failed disk by its serial number — smartctl -i /dev/sdb or lsblk -o NAME,SERIAL — and pull the one whose serial matches. See degraded RAID for the full procedure.
Save your mdadm.conf. Without it, arrays don't assemble on reboot. Run mdadm --detail --scan >> /etc/mdadm/mdadm.conf after every change, and rebuild your initramfs.
Partition, then RAID. A RAID member is usually a partition (sdb1), not a whole disk (sdb). Using whole disks means no space for a partition table, no room for the RAID superblock to live where other tools expect it, and a world of confusion when you swap a drive and the replacement doesn't have a matching layout. Partition first, RAID the partitions.
Same-batch drives fail together. Disks from the same manufacturer, same batch, installed the same day, running in the same hot rack — they wear at the same rate and like to fail within weeks of each other. Stagger your purchases, or at minimum: don't wait to replace a degraded member. The rebuild is a full-surface stress test on every survivor, and it's the worst possible moment for a tired sibling to give up.
Monitor your arrays. A degraded array is the quietest emergency in computing — your server keeps working perfectly, and the only sign is an underscore in a file nobody reads. Set up mdadm --monitor to email you on failure, or use a monitoring tool that reads /proc/mdstat for you.

History and Philosophy

The story starts in 1988, at the University of California, Berkeley, with a paper by David Patterson, Garth Gibson, and Randy Katz titled — and this is the fun part — "A Case for Redundant Arrays of Inexpensive Disks." Not independent. Inexpensive. The whole thesis was a rebellion against the mainframe world's approach to storage reliability: buy one enormous, fantastically expensive disk and pray it doesn't fail. Patterson, Gibson, and Katz argued the opposite: take a bunch of cheap commodity drives, combine them with some clever maths, and get both better performance and better reliability than the single expensive disk. The industry adopted the idea, rebranded "inexpensive" as "independent" (nobody selling enterprise storage wants the word "cheap" in the acronym), and the rest is three decades of servers that survive dead drives.

The irony is rich: the original paper was about saving money. Today, enterprise RAID controllers cost more than the disks they protect. But the core insight — that redundancy through multiplicity beats reliability through expense — turned out to be one of the most important ideas in computing. It's the same philosophy behind replicated databases, distributed filesystems, and the whole cloud: don't build one perfect thing; build many imperfect things and let the maths compensate. Patterson, Gibson, and Katz didn't just invent a disk trick. They articulated a principle.

The levels themselves are a historical layer cake. RAID 0 through 5 were defined in the original paper. RAID 6 came later, as disks got bigger and the "what if two die at once" question stopped being theoretical. RAID 10, 50, and 60 are composites — nesting one level inside another — that emerged from practice rather than theory. The numbered list was never meant to be a ranking (RAID 6 is not "better" than RAID 5 in every case), but the numbers stuck, and now everyone treats them as a menu.

Linux's software RAID implementation — md (multiple devices), the thing behind mdadm — has been in the kernel since the late 1990s and is quietly one of the most battle-tested subsystems in all of Linux. It handles RAID 0, 1, 4, 5, 6, and 10 in software, with no special hardware, at speeds that made dedicated hardware RAID controllers increasingly hard to justify. Most Linux servers today use md, and most admins interact with it through mdadm and /proc/mdstat — the two tools you already know from this page. Hardware RAID controllers still exist (LSI/Broadcom MegaRAID, HP SmartArray), but they hide the arrays from the OS, which means the kernel can't see /proc/mdstat and tools like smartctl need special flags (-d megaraid,N) to reach through the controller to the physical disks. Software RAID is transparent; hardware RAID is a black box. Both work. Transparency is nicer at 3 a.m.