"My data is on RAID, it's protected." The shortcut is so widespread it sounds reasonable. It rests on confusing two properties that have almost nothing to do with each other.
What RAID actually does
RAID spreads data across several disks with redundancy, so that losing one — sometimes two, depending on the level — does not interrupt service. You replace the failed unit, the array rebuilds, nobody noticed anything.
That is availability, and it is valuable: it avoids downtime and a full restore every time a disk dies.
But note what it implies: there is only one version of your data, the current one. RAID keeps it reachable despite a hardware failure. It preserves no earlier state.
The six scenarios it does not cover
Deletion. You erase a directory by mistake. RAID performs the deletion across every disk, faithfully and instantly. Redundancy keeps no previous version.
Application corruption. A database writes inconsistent data, a failed update destroys a configuration: RAID faithfully stores what it is handed. It does not judge content.
Ransomware. Encryption is a legitimate write. RAID applies it across the whole array without slowing down. Here redundancy serves the attacker.
Theft, fire, water damage. Every disk is in the same enclosure, in the same place. One physical event takes them together.
The mistyped command. A format on the wrong volume, a partition table on the wrong device: applied to the entire array.
Silent corruption. A block degrades without anyone noticing. Classic RAID generally has no way to know which copy is correct — it can even propagate the bad one during a rebuild. Only filesystems with checksums genuinely detect and correct this, and that is a filesystem property, not a RAID one.
The rebuild: the most dangerous moment
Here is the point that discussions about RAID levels most often skip.
A disk dies, you replace it, the rebuild starts. To recompute the missing data, the system must read every surviving disk in full. It is the heaviest load they will ever experience, running for hours or days on large capacities.
Those disks are the same age, often from the same batch, and have carried exactly the same load since day one. They are in the same state of wear as the one that just failed.
If an unreadable sector is lurking anywhere, the rebuild will find it — and on an array tolerating a single failure, it fails. You then lose the whole array, not one disk.
The controller, the forgotten failure point
On hardware RAID, the controller card writes its metadata in a proprietary format. If it dies, you often need a compatible model to read the array back. On older hardware that can mean hunting for a part on the second-hand market — with perfectly intact and perfectly unusable disks.
Software RAID managed by the operating system does not have this flaw: the disks reassemble on any machine running the same system. For a homelab, where nobody keeps a spare card on the shelf, that is decisive.
So, should you use RAID?
Yes — for what it does. It avoids downtime on every disk failure, and on a machine providing a permanent service that is genuine comfort.
The question to ask is simply not "am I protected?" but "protected from what?". RAID answers one scenario out of seven. The other six require independent, versioned copies, at least one of them out of the machine's reach.
And if budget forces you to choose between the two, the choice is clear: a backup without RAID beats RAID without a backup. The first costs you downtime. The second costs you your data.
Comments