RAID levels, and the array that is not a backup

Why this matters

RAID is a small topic with one large misconception attached, and the exam tests the misconception directly. Organisations lose data every year because somebody believed a mirrored pair was a backup, and then a file was deleted, or encrypted by ransomware, or overwritten — and the mirror faithfully reproduced the damage on both disks instantly.

The technical content is genuinely small: four levels, their capacity arithmetic, and their fault tolerance. What is worth spending time on is the reasoning that makes those numbers predictable rather than memorised, and the argument about what RAID is actually for.

This is one of three lessons in this course with no short bench lab, because a reader with one disk cannot build an array. The applied lab works the arithmetic and the failure scenarios instead, which is the form the exam asks in.

The lesson

What RAID solves: availability, not safety, and why that distinction is examinable

RAID keeps a system running when a disk fails. That is its purpose, and everything else follows.

• It does not protect against deletion, because the deletion is written to every disk.
• It does not protect against corruption, ransomware or a bad update, for the same reason.
• It does not protect against theft, fire, flood or the controller failing.
• It does not give you yesterday's version of a file.

A backup does all of those, because a backup is a separate copy at a separate point in time, ideally in a separate place. RAID is a simultaneous copy, which is precisely why it cannot help with anything that happens to the data itself.

The way to hold it: RAID answers "a disk died, can we keep working?" A backup answers "the data is wrong or gone, can we get it back?" Those are different questions and they need different mechanisms. A scenario describing accidental deletion, ransomware or a need for a previous version is asking for a backup, and RAID will be among the wrong answers.

The levels a technician meets: 0, 1, 5 and 10, by behaviour rather than by number

RAID 0 — striping. Data is split across all disks. Every disk holds a different part of every file.

• Fast, because reads and writes are spread across all members.
• Zero fault tolerance. Any disk failing loses everything, and the risk grows with the number of disks. Two disks in RAID 0 are roughly twice as likely to fail as one.
• Its place is scratch space and temporary work where speed matters and the data is reproducible.

RAID 1 — mirroring. Every disk holds the same data.

• Survives the loss of any one disk in a two-disk mirror.
• Reads can be served from either member; writes go to both.
• Simple, which is its main virtue. The smallest sensible array.

RAID 5 — striping with distributed parity. Data is striped, and a parity block is calculated and spread across the members.

• Needs at least three disks.
• Survives one disk failing; parity plus the surviving data reconstructs the missing part.
• Write performance suffers because every write updates parity too.

RAID 10 — a stripe of mirrors. Pairs are mirrored, and the mirrors are striped.

• Needs at least four disks.
• Fast and tolerant: survives one disk from each mirror.
• Uses half the raw capacity, which is the price.

Also in scope conceptually: RAID 6, which is RAID 5 with two parity blocks and survives two simultaneous failures, at the cost of more capacity and slower writes.

Capacity and fault tolerance arithmetic for each level

Using n disks of size s, assuming all members the same size:

Worked examples of the kind the exam asks:

• Four 4 TB disks in RAID 5. Usable (4 − 1) × 4 = 12 TB, surviving one failure.
• Four 4 TB disks in RAID 10. Usable (4 ÷ 2) × 4 = 8 TB, surviving one disk per pair — so potentially two failures, if they are in different pairs, and only one if they are not.
• Three 2 TB disks in RAID 5. Usable 4 TB.
• Two 1 TB disks in RAID 1. Usable 1 TB.
• Two 1 TB disks in RAID 0. Usable 2 TB, surviving nothing.

If members are different sizes, every member is treated as the size of the smallest, and the excess is wasted. That is why arrays are built from matched disks, and why replacing a failed 4 TB member with a 6 TB disk gains nothing.

Hardware, software and firmware RAID, and what happens when a controller dies

Hardware RAID uses a dedicated controller with its own processor and often a battery-backed cache. The operating system sees one disk. It performs well and offloads parity calculation.

Its specific risk is the one the exam asks about: the array metadata is in a controller-specific format. If the controller fails, the disks are often unreadable by anything except an identical controller. Organisations depending on hardware RAID keep a spare controller for exactly this reason.

Software RAID is implemented by the operating system. No special hardware, portable between machines running the same system, and it costs some processor time — which matters much less than it used to. Modern implementations are mature and are frequently the better choice for small deployments.

Firmware RAID, sometimes called fake RAID, is the option built into consumer motherboards. It looks like hardware RAID and is really a firmware stub plus a driver doing the work in software. It combines the portability problems of hardware RAID with the performance of software RAID, and it is generally the worst of the three.

Rebuilds: the window where an array is at its most fragile

When a member fails, a redundant array runs degraded: still serving data, with no remaining tolerance. Replacing the disk starts a rebuild, which reconstructs the missing data onto the new member.

Why that window is dangerous:

• A rebuild reads every sector of every surviving disk. It is the heaviest sustained load the array ever experiences.
• Array members are usually the same age, from the same batch, with the same hours. The conditions that killed one apply to the others.
• On large disks a rebuild takes many hours or days, and the array is unprotected throughout.
• A previously unnoticed unreadable sector on a surviving disk surfaces during the rebuild, which is when a RAID 5 rebuild fails and takes the array with it.

The practical consequences a technician should be able to state:

• A degraded array is an emergency, not a maintenance item.
• Verify the backup before starting the rebuild. If the rebuild fails, the backup is everything you have — which is the point of this lesson arriving from the other direction.
• A hot spare shortens the window by starting the rebuild automatically.
• Scrubbing, which reads the whole array periodically, finds unreadable sectors while there is still redundancy to repair them — before the rebuild does, under pressure.