RAID is not a backup, and the day that becomes obvious
RAID protects against one specific failure: a disk dying. It offers nothing at all against the four things that actually destroy data.
6 August 20262 min readadmin
RAID solves one problem well. A disk fails, the array carries on, you replace the disk and it rebuilds. That is worth having and it is not a backup, because the failure it protects against is not the failure that usually costs people their data.
The four things RAID does not help with
Deletion. A file deleted on a RAID array is deleted on every disk in it, immediately and consistently. That is what the array is for — the disks agree.
Corruption. If an application writes bad data, the array faithfully stores bad data with full redundancy.
Ransomware. Encryption is just writing. The array has no opinion about what it is asked to write.
Losing the box. Fire, flood, theft, a failed controller that takes the array's metadata with it. Every disk is in the same chassis in the same room.
Each of these is more likely than the mechanical failure of two disks at once, and RAID is defence against precisely the one that is least likely.
The rebuild window is the risk nobody prices
When a disk in a RAID 5 array fails, the array is running without redundancy until the replacement finishes rebuilding. That rebuild reads every sector of every remaining disk — the heaviest sustained load those disks will ever see — and it does it on drives of the same age, from the same batch, with the same hours on them.
On large modern drives a rebuild is measured in days, not hours. A second failure during that window loses the array, and the load makes a second failure more likely, not less. This is the argument for RAID 6 over RAID 5 on any array built from large disks, and it is why "we have RAID" should always be followed by "and how long is a rebuild".
What a backup has that RAID does not
Three properties, and none of them is redundancy:
- History. Yesterday's version, and last month's. Redundancy gives you the current state on more than one disk; a backup gives you a different state.
- Separation. A copy that a compromise of the live system cannot reach or modify.
- A restore that has been tested. An untested backup is a belief.
The one question worth asking
Not "are we backed up" — everybody says yes. Ask: when did somebody last restore a file from it, and how long did it take?
If nobody can answer, the backup has not been tested, only performed. The two are different, and the difference only ever surfaces on the worst possible day.