RAID Is Not a Backup
RAID is not a backup. RAID (except RAID 0) protects against exactly one failure mode — a drive dying — by keeping the array online while you replace the disk; everything else that destroys data (deletion, ransomware, corruption, controller failure, surge, theft, fire) is replicated to every drive instantly or takes the whole box at once. A backup is a separate, versioned, ideally offline or off-site copy you can restore from — see the 3-2-1 rule. RAID is for uptime; backup is for survival. You need both.
The one thing to know: RAID is not a backup. RAID (except RAID 0) protects against DRIVE failure — if one disk dies, the array keeps running while you replace it. It does nothing against the things that actually destroy data: accidental deletion, ransomware, file corruption, a failed controller, theft, fire, or a power surge that takes the whole box. All of those hit the live array and every mirror of it at once. RAID is about uptime and availability; a backup is a separate, ideally offline or off-site copy you can restore from. You need both, and 'I have RAID' is the single most common — and most dangerous — misconception in home storage.
What does RAID actually protect against?
One thing: single-drive hardware failure (or two-drive, with RAID 6 / SHR-2). When a disk dies, the array runs degraded on the surviving drives' redundancy data, you swap in a replacement, and the array rebuilds. Your files stay available the whole time — no downtime, no restore. That is genuinely valuable, and it is the entire value. RAID is an availability mechanism: it answers "can I keep working while a drive is replaced?", not "can I get my data back after something bad happened to it?" (RAID 0 doesn't even do that — it stripes with zero redundancy, so any one drive failing loses everything.)
What does RAID happily replicate to every drive, instantly?
RAID's job is to make all member drives agree. It performs that job faithfully for destructive writes too — the mirror is not a safety copy, it's a synchronized copy:
- Accidental deletion: the delete is just a write, and RAID commits it to every drive in the same instant — the "redundant" copy of your file is gone before you notice.
- Ransomware encryption: the malware overwrites files with encrypted versions, and RAID diligently mirrors each encrypted block across the array in real time.
- File corruption: a bad write from a crashing app or flaky RAM is stored with full redundancy — RAID guarantees the corrupt version survives a drive failure.
- Filesystem bugs: a filesystem-level fault scrambles metadata identically on every member drive, because they all hold the same filesystem.
- Controller / NAS failure: the drives may be fine, but the array's layout lives in the controller and its metadata — a failed board or corrupted array config can leave healthy disks unreadable without matching hardware or painful recovery.
- Power surge: a surge doesn't pick one drive — it can kill several drives, the controller, and the PSU in the same chassis at the same moment.
- Fire, flood, theft: every drive in the array shares one physical box in one building; whatever takes the box takes all copies inside it.
Every one of these defeats RAID 1, 5, 6, 10, and SHR equally, because none of them is the failure mode RAID was designed for. This is why "I have RAID" is the most dangerous sentence in home storage.
Protects vs. doesn't: the full table
| Failure mode | RAID (1/5/6/10/SHR) | Snapshots (same pool) | Versioned 3-2-1 backup |
|---|---|---|---|
| Single drive dies | ✅ Protected (that's the job) | ❌ Dies with the pool if redundancy is exceeded | ✅ Restorable |
| Second drive dies during rebuild | ⚠️ Only with two-drive redundancy (RAID 6 / SHR-2) | ❌ | ✅ Restorable |
| Accidental deletion | ❌ Replicated instantly | ✅ Roll back to snapshot | ✅ Restorable |
| Ransomware encryption | ❌ Replicated instantly | ⚠️ Usually — if snapshots are read-only and the NAS admin account wasn't compromised | ✅ If a copy is offline/off-site or immutable |
| File corruption / bad write | ❌ Stored redundantly | ✅ Older version preserved | ✅ Older version preserved |
| Filesystem bug | ❌ Same filesystem on all drives | ❌ Snapshots live in that filesystem | ✅ Separate copy |
| Controller / NAS hardware failure | ❌ Array metadata at risk | ❌ Same box | ✅ Separate device |
| Power surge | ❌ Can kill multiple drives at once | ❌ Same box | ✅ If a copy is offline or elsewhere |
| Fire / flood / theft | ❌ One box, one building | ❌ Same box | ✅ Off-site copy survives |
Why is the rebuild window the most dangerous moment?
When a drive fails and you insert a replacement, the array rebuilds by reading essentially everything on the surviving drives for hours or days. Three risk factors stack up at exactly the wrong time:
- No safety margin: a degraded single-redundancy array (RAID 1/5/SHR-1) has zero tolerance left — one more failure ends it.
- Maximum stress: the rebuild subjects the surviving drives to their heaviest sustained workload precisely when you can least afford another failure.
- Correlated age: home arrays are usually built from identical drives bought together, so the survivors share the model, batch, and wear profile of the one that just died — failures are not independent coin flips.
This is also where drive choice bites: SMR (shingled) drives rewrite whole zones on sustained writes, which can stretch a rebuild from hours into days or cause the drive to drop out of the array mid-rebuild — see CMR vs SMR. The mitigations are all boring and effective: CMR NAS-rated drives, two-drive redundancy (RAID 6 / SHR-2) on larger arrays, mixed purchase batches, prompt replacement — and, above all, a backup, so a failed rebuild is an inconvenience rather than a catastrophe.
What about URE math — do big arrays really fail rebuilds on read errors?
You'll see a famous claim that rebuilding a large RAID 5 array is statistically doomed because consumer drives are spec'd at an unrecoverable read error (URE) rate of about 1 in 1014 bits — roughly one bad sector per ~12TB read — so a multi-terabyte rebuild "must" hit one. Honest version: the naive math overstates the risk. The spec is a conservative worst-case ceiling, not a measured average; real drives routinely read far more than 12TB without an error, errors cluster on failing drives rather than arriving uniformly, and modern RAID/filesystem layers can often continue past a bad sector (losing one file, not the array). But the underlying point survives the hedging: on large arrays, the probability of hitting some read problem during a full-array rebuild is real and grows with capacity. That's a legitimate argument for two-drive redundancy and scheduled scrubs on big arrays — and another argument for a backup, which makes the whole question low-stakes.
What actually counts as a backup?
A backup is a separate, versioned copy on a separate device, ideally offline or off-site, that you have tested restoring from. Each word is load-bearing:
- Separate device: so no single hardware event (surge, controller death, theft) can take both copies.
- Versioned: so yesterday's good file survives today's deletion, encryption, or corruption — a plain one-way sync replicates mistakes just like RAID does.
- Offline or off-site: so ransomware that reaches the NAS can't reach the backup, and a fire that takes the building doesn't take every copy.
- Tested: an untested backup is a hope, not a backup.
The 3-2-1 rule is the standard for real data safety: keep at least 3 copies of your data, on 2 different types of media, with 1 copy off-site. A NAS with RAID is one copy on one device in one building — it satisfies none of the three on its own. A practical home version: the working files on your PC (copy 1), the NAS (copy 2), and an off-site or cloud copy (copy 3). Test a restore occasionally — an untested backup is a hope, not a backup. Full breakdown: the 3-2-1 backup rule.
Where do Btrfs/ZFS snapshots fit?
Snapshots are the honest middle ground. A snapshot is a read-only, point-in-time view of the filesystem that costs almost nothing to keep, so you can retain hours, days, and weeks of versions. Against accidental deletion and most ransomware they are excellent: roll back and the damage is undone, provided the snapshots are read-only and the attacker didn't gain NAS admin rights to delete them. But be honest about the bounds: snapshots live in the same pool as the data. Anything that kills the pool — drive failures beyond the RAID's tolerance, filesystem corruption, controller failure, surge, fire, theft — kills the snapshots with it. Snapshots become a genuine backup layer only when they're replicated to a separate pool, a second NAS, or off-site (ZFS send/receive, Btrfs snapshot replication, or the NAS vendor's backup suite). Rule of thumb: snapshots for fast, frequent restore points; replication and 3-2-1 for survival.
What are the practical backup targets for a home NAS?
- A second NAS (ideally elsewhere): the gold standard for self-hosters — scheduled, versioned replication to a box at a family member's house or an office covers the off-site leg automatically.
- A USB drive, rotated and kept offline: the cheapest real backup. A NAS-scheduled versioned backup to an attached USB disk that you unplug between runs is immune to ransomware that hits the live NAS. Two rotated drives, one stored elsewhere, quietly satisfies 3-2-1.
- Cloud backup (as a category): encrypted, versioned backup to an object-storage or consumer cloud target covers the off-site leg with zero hardware. The caveat is cost at scale and restore time over a home connection — many self-hosters cloud-back only the irreplaceable subset (photos, documents) and accept that ripped media is re-acquirable.
Which NAS picks make real backup easy?
Every enclosure on our list can push data to USB or cloud somehow, but the mature first-party backup suites are where Synology and QNAP earn their software premium:
- Synology DiskStation DS224+ — DSM's first-party backup tooling is the most polished and best-documented in the class; versioned backups to USB, a second Synology, or cloud targets are wizard-driven. Watch out: Only 1GbE networking (no 2.5GbE) caps real-world throughput near ~110MB/s, which a single modern hard drive can already exceed; 2GB base RAM is tight for many apps; and Synology has been steadily tightening drive-compatibility policy on newer models — the DS224+ still runs third-party drives, but verify the current compatibility list before buying. Check price on Amazon →
- Synology DiskStation DS923+ — adds Btrfs snapshots plus DSM's backup suite on ECC hardware, the strongest snapshot-and-replicate combination among the turnkey picks. Check price on Amazon →
- QNAP TS-264 / TS-464 — QNAP's HBS 3 (Hybrid Backup Sync) covers versioned local, remote-NAS, and cloud jobs, and QuTS hero brings ZFS snapshots. The standing caveat applies double for backup integrity: never expose a QNAP to the open internet, and patch it promptly. Check price on Amazon →
TerraMaster, Asustor, and UGREEN boxes all have workable backup tools, but their suites are younger or thinner — many owners of those boxes run TrueNAS and use ZFS replication instead, which is excellent if you're comfortable driving it. See DIY TrueNAS vs Synology.
Related reading
Frequently Asked Questions
No. RAID (except RAID 0, which has no redundancy at all) protects against one thing: a drive dying, so the array stays online while you replace it. It does nothing against accidental deletion, ransomware, file corruption, filesystem bugs, controller failure, a power surge, theft, or fire — all of which hit the live array and every mirrored copy on it at the same instant. RAID is uptime; a backup is a separate, versioned copy you can restore from. You need both.
Because the mirror is live and instant. RAID replicates every write to all member drives in real time — including the write that deletes your file, the write that encrypts it with ransomware, and the write that saves a corrupted version. A backup is useful precisely because it is NOT synchronized with the live data: it holds older, versioned copies that the mistake or the malware never touched.
Partially. Snapshots are excellent protection against accidental deletion and many ransomware scenarios, because they preserve read-only, point-in-time versions you can roll back to. But a snapshot on the same pool dies with the pool — drive failures beyond the RAID's tolerance, filesystem corruption, controller failure, surge, theft, and fire take the snapshots too. Snapshots become a real backup layer only when they are replicated to a separate pool, a second NAS, or off-site.
A separate copy, on a separate device, that keeps versions and that you have tested restoring from. The standard is the 3-2-1 rule: at least 3 copies of the data, on 2 different media types, with 1 copy off-site. Practical NAS targets: a second NAS at another location, a rotated USB drive kept offline, or an encrypted cloud backup — driven by versioned backup software (Synology's Hyper Backup class of tool, QNAP's HBS 3 class), not a plain sync.
Plain sync is not, for the same reason RAID is not: it faithfully replicates deletions, encryptions, and corruption to the other side. Sync services with version history and deleted-file retention are better and can serve as a backup layer if the retention window is long enough — but a purpose-built versioned backup with its own retention rules is the safer default for irreplaceable data.
Yes — for what it actually does. Redundancy keeps your files available while a failed drive is replaced, spares you a multi-day restore, and on larger arrays two-drive redundancy (RAID 6 / SHR-2) hedges the real risk of a second failure during a rebuild. RAID is an availability tool, and a good one. It just occupies a completely different slot in your plan than a backup does, and can never substitute for one.
How we work
We're a research-based site: we analyze storage and filesystem engineering, manufacturer documentation, and published large-scale drive-reliability data rather than lab-testing every failure mode. We report mechanisms and specs, never guarantees about data safety — drives fail, arrays fail, and only a tested 3-2-1 backup protects your data. Read our full methodology →