RAID: what it actually gives you

RAID (Redundant Array of Independent Disks) combines several physical disks into one logical volume so that a disk failure doesn't stop the system or lose data. Everything else people credit it with is beside the point. This lesson covers the levels, degradation and rebuild, monitoring, and the main thing: why RAID sits in the backup track even though it isn't a backup.

One job: survive a dead disk

Disks die predictably often: in a fleet of a hundred, a couple fail every single year. RAID turns that event from an outage into a task: "replace the hardware."

RAID covers a disk failure. It doesn't cover a deleted file, a corrupted database, or a fire in the server room. More on that in the last section.

The levels you'll run into

RAID 0 (striping) slices data into stripes and spreads them across disks. Fast, capacity adds up, zero redundancy. Any disk's death takes the whole volume with it. It's a speed boost, not protection, and in production it's used only for data you wouldn't miss.

RAID 1 (mirroring) writes the same data to two disks. Half the capacity goes to redundancy, but the array survives the death of one disk. Reads get faster under parallel load: requests spread across the copies, though a single sequential stream won't go any faster.

RAID 5 stores data stripes plus a parity block, and that block rotates across the different disks. Out of N disks, N-1 are available, and the array survives the death of one. For a long time this was the standard for large arrays.

RAID 6 works the same way but with two parity blocks, so it survives two disks dying at once. Writes are slower, but it's a calmer setup.

RAID 10 combines mirrors into stripes. Capacity-wise it's expensive (half goes to redundancy), but it rebuilds fast and predictably.

How parity gets back what's lost

Parity in RAID 5 is computed with XOR (exclusive or) across the blocks of one stripe. XOR has a convenient property: if P = A xor B xor C, then B = A xor C xor P. Any single block in the stripe, including the parity block itself, can be recovered from all the others.

An example in bytes: A = 0x0f, B = 0x35, C = 0x60. The parity is P = 0x0f xor 0x35 xor 0x60 = 0x5a. The disk with B dies, and then 0x0f xor 0x60 xor 0x5a = 0x35 gives B back.

This reveals the main limitation: recovery needs every remaining block of the stripe. Lose two, and you get an equation with two unknowns that can't be solved. RAID 6 adds a second, independent checksum, which is why it survives two failures.

Degradation and rebuild

While every disk is intact, the array runs normally. After a disk dies, the array enters a degraded state: the data is still available, but there's no redundancy left. Any further failure at this point means losing the volume.

You insert a new disk, and a rebuild starts: the array recomputes the missing data and writes it to the replacement. In software RAID on Linux, the kernel's md driver does this; in hardware RAID, the controller does. This is the most dangerous stretch in an array's life.

In RAID 5 and 6, the rebuild reads all the other disks in full: the missing block is computed from parity across the survivors. The disks are the same age, from the same batch, with the same power-on hours, and it's exactly this load that often kills the second one. In RAID 1 and 10 it's gentler; only the mirror partner of the failed disk gets read.

Let's estimate the time. A 20 TB disk read in full at around 200 MB/s takes about 28 hours, and that's without any workload on top. The whole time, the array has no redundancy. That's why big disks go with RAID 6 or RAID 10, and RAID 5 is left for smaller, fast volumes.

A second reason for the same choice: unreadable sectors. The more data read in one rebuild, the higher the chance of hitting a bad sector, and on consumer disks this is no longer theoretical. For RAID 5, hitting one means either an aborted rebuild or lost data in the affected blocks: there's nothing left to recover them from, because the redundancy is gone.

You'll also run into the sharper claim that RAID 5 is "mathematically doomed" because of the rated unreadable-sector rate. Don't take that too literally: the rated figure is the manufacturer's guaranteed minimum, not the observed rate. The conclusion about large disks doesn't change either way.

Monitoring matters more than the level

An array that degraded six months ago and never told anyone isn't protecting you anymore. The practice is simple: watch the array's state and the disks' health.

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo smartctl -a /dev/sda

The first command shows all of Linux's software arrays, the second gives details on one array, the third shows the health of one specific disk (the smartmontools package).

In /proc/mdstat, every array has a pair of counters: [2/2] [UU] means "there should be 2 disks, 2 are running." A degraded mirror looks like [2/1] [U_], and a failed disk is marked (F) in the device list:

md0 : active raid1 sdb1[1](F) sda1[0]
      976630464 blocks super 1.2 [2/1] [U_]

This is the line worth wiring into monitoring. mdadm has a mode for that, mdadm --monitor, which sends an email or runs a script when a disk in the array fails.

For disks, watch SMART. According to Backblaze's data, five attributes point to a failure: reallocated sectors (5, Reallocated_Sector_Ct), uncorrectable errors (187, Reported_Uncorrect), command timeouts (188, Command_Timeout), sectors pending reallocation (197, Current_Pending_Sector), and ones unreadable during an offline scan (198, Offline_Uncorrectable). Watch the RAW_VALUE column: zero is good, growth is bad. NVMe disks don't have this table; smartctl shows their own health log instead (Critical Warning, Media and Data Integrity Errors).

An important caveat: by that same Backblaze data, almost a quarter of failed disks showed none of the five signs. Clean attributes mean an absence of bad news, not a certificate of health.

And keep a spare disk: cold on a shelf, or hot in the bay (hot spare). With a hot spare, md starts the rebuild on its own, right after the failure. A rebuild started a week after the failure too often starts after the second failure has already happened.

Why this lesson is in the backup track

Because RAID regularly gets mistaken for a backup, and that's the most expensive mistake in this subject.

RAID doesn't protect against rm -rf, a DROP TABLE, ransomware, a bug in your application, or a fire in the server room. It neatly duplicates all of these events to every disk at once, because to RAID it's just an ordinary write.

RAID is responsible for availability: the service keeps running while you swap hardware. A backup is responsible for durability: the data exists even when everything else is gone. Neither can substitute for the other.

Common mistakes

• Treating RAID as a backup. Deletion and corruption get copied to every disk instantly.
• Building an array and never setting up alerts. Degradation only gets noticed on the second failure, when there's nothing left to save.
• Putting off replacing a disk. While the array is degraded, it runs with no margin left.
• Replacing the wrong disk. Before swapping one, cross-check the device name from /proc/mdstat or mdadm --detail against the serial number from smartctl -i and the label on the case.
• Putting RAID 5 on large disks. The rebuild takes days and pushes the remaining disks to their limit.
• Trusting a clean SMART report. It catches some failures, not all of them.

What you'll need for the tasks

• Reading /proc/mdstat: array type, the [N/M] counters, the [UU]/[U_] mask, the (F) marker.
• Reading the smartctl -A attribute table: attribute number, name, the RAW_VALUE column, the five Backblaze attributes.
• Understanding that RAID 5 parity is an XOR across a stripe's blocks, and that recovering one block needs all the others.
• Docker and bash: docker exec <container> <command>, cat, grep.

What to remember

RAID covers exactly one scenario: a disk failure.

RAID 0 gives no redundancy at all. RAID 1 and 5 survive one disk failing, RAID 6 survives two, RAID 10 survives one per mirror.

A degraded array runs with no safety margin, and a rebuild loads the remaining disks hard enough that it often kills a second one.

On large disks, people choose RAID 6 or 10, because a RAID 5 rebuild takes days.

An array with no monitoring and no spare disk only protects you on paper.

Next up is the most consequential part: database backups, where a copy of the file and a copy of the data are two different things.