What RAID Is Not (It Is Not a Backup)
Redundancy protects against a dead disk. It does nothing against the mistakes that actually lose your data
Contents
I’ve had this exact conversation more times than I can count: someone proudly describes their RAID array, mentions they lost a file to a bad rm, and asks why the redundant array didn’t save them. It didn’t save them because it was never built to. RAID and backup solve two entirely different problems, and the confusion between them is one of the most expensive misunderstandings in home and small-office storage — expensive specifically because it’s invisible until the exact moment it costs you everything.
The One Problem RAID Actually Solves
RAID — Redundant Array of Independent Disks — exists to answer one question: what happens the instant a physical drive dies. In a mirrored array, every write goes to two or more disks simultaneously, so if one drive fails outright, the data still exists intact on its twin and the array keeps serving requests without interruption. In a parity-based array, extra data is calculated and stored alongside your actual data specifically so that if one drive is lost, the missing data can be mathematically reconstructed from what remains on the surviving disks. Either way, the goal is continuity through a hardware failure: the service stays up, the data stays accessible, and a technician swaps the dead drive and rebuilds the array without anyone needing to restore anything from an external copy.
That is a genuinely valuable property, and worth having — a rebuild that takes a few hours beats a multi-day restore from an offsite copy every time the failure is one RAID is actually designed to handle. It is also the entire property RAID provides. Nothing about mirroring or parity has any concept of “this write was a mistake” or “this file used to be different.” RAID’s job is to make sure whatever gets written survives a drive failure, not to make sure what gets written was correct in the first place.
Why Every Kind of Mistake Sails Straight Through
Consider what actually happens when you delete a file by accident, or run a script that overwrites the wrong directory, or get hit by ransomware that encrypts everything it can reach. In every one of these cases, the operation that destroys your data is itself a perfectly valid write, indistinguishable at the storage layer from any other legitimate write. RAID replicates that write instantly and faithfully to every disk in the array, because faithful replication of every write is precisely the mechanism that makes RAID protect against drive failure in the first place. The exact feature that saves you from a dead disk is the same feature that guarantees a mistaken deletion, a corrupted database write, or a ransomware encryption pass reaches every mirror in the array before you’ve even noticed anything went wrong. There is no mechanism anywhere in the RAID layer that inspects a write and asks whether it looks intentional; asking it to would defeat the whole point, since a RAID controller that second-guessed writes would also be a RAID controller that couldn’t be trusted to durably store the writes you actually meant to make.
| |
On a RAID array, that command doesn’t get partially blocked by the redundancy. It gets executed against the array exactly as if the array were a single disk, and the mirror or parity faithfully preserves the now-empty directory across every drive. RAID has done its job perfectly. Your data is still gone.
This is also true of silent corruption, and of a category of failure people tend to forget entirely: your own future self, six months from now, realising a document was quietly wrong for the last four months and every version you’d want to recover has already been overwritten by the correct-looking but actually-wrong data. RAID has no concept of history. It has one current state, replicated for durability, and no record of what the state used to be.
What Backup Actually Adds That RAID Doesn’t Have
Backup solves a different problem: recovering a previous state after the current state has been damaged, whether by hardware failure, human error, or malicious action. The property that makes this possible is one RAID deliberately doesn’t have — separation in time and, ideally, in location. A real backup is a copy taken at a specific point in the past, kept independently of the live system, so that a mistake made today doesn’t propagate into yesterday’s copy. Multiple retained versions matter for exactly the “wrong for months before anyone noticed” scenario above; a single most-recent backup, if it was taken after the corruption happened, is just as useless as no backup at all.
This is where the well-known 3-2-1 framing earns its keep: three copies of anything that matters, on two different kinds of media, with one copy kept somewhere physically separate from the rest. RAID can be part of the storage underneath one of those three copies. It cannot be the whole strategy, because none of “two different kinds of media” or “one copy offsite” or “multiple points in time” describes what a RAID array does on its own.
The Same Confusion, One Layer Up: Snapshots
Filesystem snapshots — ZFS and Btrfs both do this well — sit closer to genuine backup than RAID does, because a snapshot does capture a specific point in time and can let you roll back a mistaken write. That’s a real and valuable step up from RAID alone — restoring a file from an hour-old snapshot takes seconds and requires no external media at all, which is a genuinely different and better experience than digging out an offsite copy for a routine mistake. It is still not a complete backup strategy on its own, for a simple reason: a snapshot usually lives on the same physical pool as the data it’s protecting. If that pool suffers a hardware failure severe enough to take out the array entirely, or if someone with sufficient access deletes the snapshots along with the live data, the point-in-time copies vanish along with everything else. Snapshots protect brilliantly against “I need last Tuesday’s version of this file.” They do nothing for “the building burned down” or “an attacker with admin access wiped the pool including its snapshots.”
The Rebuild Risk Nobody Mentions
There’s a second, less obvious way RAID can let you down even within its own job description, and it’s worth knowing before you rely on parity-based RAID for large modern drives. When a disk in a parity array (RAID 5, for instance) fails and gets replaced, rebuilding the array means reading every single remaining sector across every surviving disk to reconstruct the missing drive’s contents. On a large multi-terabyte drive, that’s an enormous number of sector reads, and every hard drive has a manufacturer-quoted rate of unrecoverable read errors — a vanishingly small but non-zero chance that any given sector simply can’t be read back correctly. String enough sector reads together during a single rebuild and the odds of hitting at least one unreadable sector on a surviving disk, at exactly the moment you have zero redundancy left to absorb it, become uncomfortably real on large enough arrays. This is the often-cited reason RAID 6 (tolerating two simultaneous drive losses, via a second independent parity calculation) and mirrored layouts have gained ground over single-parity RAID 5 as drive capacities have grown: the rebuild window is the most dangerous moment in the array’s life, and single parity leaves no margin at all if anything goes wrong during it.
| |
Watching a rebuild’s state directly, rather than assuming it’ll finish cleanly, is worth the habit — a rebuild that’s degraded and recovering is, by definition, an array currently running with less redundancy than its normal state, for however many hours the rebuild takes.
Why the Confusion Persists
Part of why this mix-up is so common and so persistent is that RAID genuinely does prevent a large fraction of the data-loss incidents an ordinary home user or small office will ever encounter, simply because drive failure is common and mistaken deletion, ransomware, and catastrophic site loss are comparatively rarer events for any individual system. Someone who’s run a mirrored array for years and never lost data to it isn’t wrong about their own experience — they’ve genuinely been protected from the failure mode that’s statistically most likely to have hit them. The trouble is that “hasn’t happened yet” and “can’t happen” are different claims, and the failure modes RAID doesn’t cover tend to be the rarer, more catastrophic ones precisely because they’re less routine — which also means less top-of-mind until the one time it matters.
Vendors and marketing copy don’t help. Consumer NAS boxes are frequently sold with language that leans hard on words like “protected” and “safe,” describing the redundancy the box provides without ever drawing the distinction this piece has been making. A buyer reasonably infers, from that language, that the box protects their data in a general sense, rather than the specific and narrower sense of surviving a single drive’s hardware failure.
Troubleshooting: Spotting the Gap Before It Costs You
The fastest way to check whether you actually have a backup, rather than just redundancy, is to ask one question honestly: if this exact server were destroyed right now — stolen, flooded, caught in a fire — does a usable copy of the data exist somewhere else entirely? If the honest answer involves the words “well, it’s RAID so—”, you don’t have a backup yet, regardless of how resilient the array itself is to a single drive dying.
A second check: try an actual restore, not a theoretical one. Pick a real file, delete your working copy entirely, and recover it purely from whatever you’re calling your backup. A backup you’ve never restored from is a backup you don’t actually know works, and the failures that show up here — wrong permissions, a broken restore script, an encryption key nobody wrote down, a retention policy that turned out to only keep the last day — are exactly the failures you’d rather discover during a drill than during a real incident.
A third: check whether your backup process runs on a schedule independent of the RAID array’s own health. If your only backup destination is a second array in the same rack, on the same power circuit, behind the same network switch, you’ve built redundancy against a drive failure and left every other failure mode — the power circuit, the switch, the building, a single person’s access credentials — completely uncovered.
A fourth check, specific to the rebuild risk above: know roughly how long a full rebuild takes on your actual array, and treat that window as elevated risk rather than a routine background task. If a second drive shows any sign of trouble — reallocated sectors, SMART warnings, unusual noise — during an active rebuild, that’s the moment to prioritise getting a fresh backup of anything irreplaceable off the array entirely, rather than assuming the rebuild will simply finish in time.
Is RAID Worth Running Anyway?
Yes, unambiguously, for what it actually does. A dead drive is one of the most common hardware failures you’ll encounter running any amount of storage, and RAID turns that routine event from a middle-of-the-night data-loss emergency into a scheduled disk swap and a rebuild. That’s real value, worth the extra drives and the modest performance overhead in most home and small-office setups. The mistake is stopping there and calling the job done. The two failure categories don’t overlap, so covering one never covers the other, no matter how well either is implemented. Redundancy and backup are complementary, not substitutes, and the setups that actually survive a bad day run both: RAID (or a redundant pool like ZFS or Btrfs) for uptime through a drive failure, and a genuinely separate, genuinely tested backup for everything RAID was never built to catch. For the practical version of that separate copy, the 3-2-1 backup rule actually implemented and restic and rclone: a 3-2-1 backup pipeline that actually restores both cover the part of the strategy this piece has been arguing you still need.
Related Content
