RAID is about tolerating a drive failure, not backing up your data
Every RAID level below solves one problem: keeping an array usable after one or more drives fail, without restoring from anywhere else. That's it. RAID does not protect against accidental deletion, ransomware, file corruption that gets written to all drives simultaneously, or your building burning down — all of those still require a real backup, stored somewhere the RAID array itself can't reach. If you take one thing from this guide, it's that RAID and backup solve two different problems and neither substitutes for the other.
What RAID levels differ on is how they tolerate that drive failure: how much raw capacity gets spent on redundancy, how many drives can fail at once, and how long the array takes to rebuild after a replacement — which matters because the array runs with reduced (or zero) fault tolerance for the entire rebuild window.
The five levels, in plain terms
RAID 0 — striping, no redundancy
Data is split (striped) across every drive with no duplication at all. You get the full combined capacity and the best performance of any level here, and zero fault tolerance — any single drive failure loses the entire array's data, not just that drive's share. RAID 0 is not really a redundancy level; it's a performance/capacity-maximizing layout for data you can afford to lose entirely, like a scratch disk or a cache.
RAID 1 — mirroring
Every drive is an exact copy of every other drive. Usable capacity is the size of one drive, regardless of how many you add — the simplest possible redundancy scheme, and the fastest to rebuild, since recovery is a direct copy rather than a computed reconstruction. The cost is capacity efficiency: a 2-drive RAID 1 array gives you 50% usable capacity, and it doesn't improve by adding more drives the way parity-based levels do.
RAID 5 — single parity
Parity data (enough to reconstruct any one missing drive) is distributed across all drives, rather than one dedicated parity drive. Usable capacity is (n−1) × drive size, so efficiency improves as you add drives — a 4-drive array is 75% efficient, an 8-drive array is 87.5%. Tolerates exactly one drive failure. The real risk with RAID 5 today is drive size: as drives get larger, the rebuild window (during which a second failure loses everything) gets longer, which is why RAID 5 is increasingly considered risky for large modern drives specifically, not because the RAID 5 math changed.
RAID 6 — double parity
Same idea as RAID 5, with a second independent parity calculation, tolerating two simultaneous drive failures. Usable capacity is (n−2) × drive size — a real capacity cost over RAID 5, and rebuilds take measurably longer because reconstructing under double parity is more compute-intensive. That tradeoff exists specifically to buy back the safety margin that large modern drives eroded from RAID 5 — see our RAID Rebuild Time Estimator for exactly how much longer, using your actual drive size and array configuration.
RAID 10 — mirror + stripe
Drives are mirrored in pairs, then those mirrored pairs are striped together for capacity and performance. Usable capacity is a flat 50% regardless of drive count, and it rebuilds fast (a direct mirror copy, not parity computation) — but fault tolerance is conditional: it survives losing up to half the drives, but only if no two failed drives are the same mirrored pair. Lose both drives in one mirror and the array is gone, regardless of how healthy every other drive is.
Side-by-side comparison
| Level | Min drives | Usable capacity | Fault tolerance | Rebuild speed | Best for |
|---|---|---|---|---|---|
| RAID 0 | 2 | 100% (all drives) | None | N/A — no rebuild possible | Scratch/cache data only, never anything you can't lose |
| RAID 1 | 2 | 50% (1 drive) | 1 drive | Fast — direct copy | Boot/OS drives, small critical volumes |
| RAID 5 | 3 | (n−1)/n | 1 drive | Moderate — single-parity compute | Read-heavy arrays, smaller drives, cost-sensitive builds |
| RAID 6 | 4 | (n−2)/n | 2 drives | Slower — double-parity compute | Large arrays, large modern drives, long rebuild windows |
| RAID 10 | 4 (even) | 50% (fixed) | Up to half, depends which drives | Fast — direct mirror copy | Write-heavy workloads (databases, VM hosts) needing both speed and redundancy |
Which level should you actually use?
For a home NAS with 2 drives protecting media or documents: RAID 1. Simple, fast to rebuild, and 2 drives isn't enough for parity RAID to make sense anyway (RAID 5 needs 3 minimum).
For a 4–6 drive NAS with modern large drives (8TB+): RAID 6 over RAID 5. The rebuild window on large drives is long enough that surviving a second failure during that window is worth the extra parity drive and slower rebuild — run the numbers for your actual drives with the RAID Rebuild Time Estimator before deciding.
For a database, VM host, or anything with heavy random writes: RAID 10. The direct-mirror write pattern handles random I/O far better than parity RAID's read-modify-write parity computation, and rebuilds fast if a drive does fail.
For mixed drive sizes bought over time, on Unraid or Synology hardware specifically: neither traditional RAID nor ZFS RAIDZ handle this well — both clamp every drive to the size of the smallest one. Unraid and Synology's SHR are built for exactly this case, sizing parity to your largest drive instead. See our NAS / RAID Storage Calculator to compare exact usable capacity across all of these for your specific drives.
Frequently asked questions
Is RAID 5 actually dead, as some people claim?
Not dead, but riskier than it used to be, specifically because drives got much larger while rebuild speeds didn't scale proportionally — a longer rebuild window means more exposure to a second failure. For smaller arrays with smaller drives, RAID 5 is still a reasonable, well-understood choice. For large modern drives (8TB+) in arrays of 4 or more, RAID 6 is the safer default.
Can I convert an existing RAID 5 array to RAID 6 without losing data?
Some hardware/software RAID controllers support an online migration between levels, but it's a slow, genuinely risky operation performed on a live array with reduced redundancy throughout — and not every controller supports it at all. Check your specific controller's documentation, and back up first regardless of what it claims to support.
Does more drives always mean better RAID 5/6 efficiency?
Yes for capacity efficiency — the fixed cost of 1 (RAID 5) or 2 (RAID 6) parity drives gets spread across more total capacity as you add drives. But more drives also means more chances for any single drive to fail, and a wider array takes longer to rebuild, so this is a real tradeoff, not a pure win as arrays grow.
What's the difference between RAID 6 and RAID 10 for the same drive count?
At 4 drives, both give 50% usable capacity, but they fail and rebuild differently. RAID 10 rebuilds faster (direct mirror copy) and handles write-heavy workloads better, but a specific pair of drive failures kills the whole array. RAID 6 always survives any two drive failures and rebuilds slower due to parity computation. Write-heavy and need speed: RAID 10. Bulk storage, want guaranteed 2-drive tolerance: RAID 6.
Is ZFS RAIDZ the same as RAID 5/6?
Functionally similar capacity and fault-tolerance math — RAIDZ1 mirrors RAID 5's single-parity model, RAIDZ2 mirrors RAID 6's double parity. The real difference is ZFS itself: built-in checksumming catches silent data corruption that traditional RAID has no way to detect, on top of the same redundancy math.
Do I need hardware RAID, or is software RAID good enough?
Modern software RAID (Linux mdadm, ZFS, Windows Storage Spaces) is mature, reliable, and doesn't tie you to a specific RAID card that could fail and be hard to replace with an identical model years later — a real, documented risk with proprietary hardware RAID controllers. Dedicated hardware RAID controllers can offer better performance under heavy sustained load and offload parity computation from the CPU, but for most home and small-business use, software RAID is the simpler, more portable choice.
Related reading: RAID Is Not Backup. Questions or corrections? info@mb-networks.ca