Every storage administrator learns this twice. Once when someone tells them, and they nod. And again, for real, the night a RAID array is perfectly healthy and the data is still gone.
RAID is not a backup. It has never been a backup. It solves exactly one problem — the loss of a physical disk — and it solves that one problem well. Everything else that can destroy your data, RAID watches happen without lifting a finger, because protecting you from those things was never its job.
What RAID actually does
RAID — redundant array of independent disks — spreads data across multiple drives with enough redundancy that the array survives losing one (or two, for RAID 6) without losing data. A drive dies, you swap it, the array rebuilds, service never stops. That is a genuinely valuable thing. Drive death is the single most common hardware failure in a storage system, and RAID turns it from an outage into a hot-swap.
That is the entire scope of the guarantee. "If a disk fails, you keep running." Read it narrowly, because the array does.
What RAID does not do
Everything on this list has destroyed production data on a perfectly healthy array:
- Deletion. Someone
rm -rfs the wrong directory, or a script does. RAID faithfully replicates the deletion across every disk in the set. The array is fine. The files are gone. - Corruption. An application bug, a bad controller, a silent bit-flip that propagates — RAID stores the corrupted blocks with perfect redundancy. You now have a very reliable copy of garbage.
- Ransomware. Encryption is just writes. RAID writes them beautifully to every member disk. The array health is green while every file becomes unreadable.
- Controller failure. The RAID controller itself dies and scrambles the array, or a firmware bug corrupts the metadata. The disks are physically fine and the data is inaccessible.
- Multiple simultaneous drive failure. Beyond the redundancy level. Two disks in a RAID 5 set, three in a RAID 6 — often correlated, because drives bought together, aged together, and stressed together during a rebuild tend to fail together.
- Fire, flood, theft, and the building. RAID is one array in one chassis in one room. A physical disaster takes all the redundancy at once.
- The rebuild that kills the array. This one deserves its own paragraph.
The rebuild trap
When a drive fails in a large array, the rebuild reads every block on every surviving drive to reconstruct the lost one. On modern high-capacity drives, that rebuild can take many hours to days, during which the surviving disks are under sustained maximum load — exactly the condition most likely to expose a second marginal drive.
The result: the moment you're least protected (one drive already down) is also the moment you're stressing the remaining drives hardest. A second failure during rebuild on a RAID 5 set means total loss. This is why RAID 6 (two-drive tolerance) became standard for large drives, and why "the array is rebuilding" is a sentence that should raise your pulse, not lower it.
What RAID is for, stated honestly
RAID buys you uptime through a single disk failure. That's it. It keeps the service running when the most common hardware fault occurs. It is an availability feature, not a data-protection strategy.
Backup is a different thing entirely: independent copies, on separate media, in separate locations, with versions over time, that you have actually restored from. RAID has none of those properties. It's one copy, on one set of coupled media, in one place, with no history, that replicates every logical change including the catastrophic ones instantly.
The discipline
Keep RAID. It's good at its job. But never let a healthy array substitute for the things it cannot do:
- Keep real backups — independent copies with version history, following a rule like 3-2-1-1-0 (three copies, two media types, one offsite, one offline/immutable, zero errors on a tested restore).
- Test restores. A backup you've never restored is a hope. (That has its own article — the restore drill nobody runs.)
- Keep at least one copy that RAID's failure modes can't reach — offsite, offline, or immutable, so deletion, corruption, ransomware, and the burning building can't take your last copy.
The array being green tells you one disk can die without an outage. It tells you nothing about whether your data will survive the next bad Tuesday. Those are two different questions, and the operator who conflates them learns the difference the hard way, exactly once.