Before any of the levels, the sentence that matters most: RAID buys uptime, not safety.
It does nothing about a file you deleted, a ransomware run, a power supply that takes several drives with it, a filesystem bug, or the building burning down. Every one of those reaches all the drives at once, which is exactly what an array is built to do. The rule RAID does not replace is three copies of anything you care about, on two kinds of media, with one of them somewhere else, and a restore you have actually tested.
With that said, here is what each level costs and what it survives.
The levels, on four 8 TB drives
| Level | Usable | Survives | Efficiency |
|---|---|---|---|
| RAID 0, striping only | 32 TB | nothing | 100% |
| RAID 1, mirror | 8 TB | 3 failures | 25% |
| RAID 5 or RAIDZ1 | 24 TB | 1 failure | 75% |
| RAID 6 or RAIDZ2 | 16 TB | 2 failures | 50% |
| RAID 10, striped mirrors | 16 TB | 1 failure, often more | 50% |
RAIDZ3 needs five drives, so it does not appear in a four-drive comparison.
A few things that catch people out in that table.
RAID 0 is not RAID. It survives nothing, and it is worse than a single drive: any one of the four failing loses everything. It exists for speed and for scratch space you can afford to lose.
A mirror with four drives is a four-way mirror, not two pairs. Every drive holds the same 8 TB, so three can die, and you are paying 32 TB to store 8. If you wanted two pairs, that is RAID 10 and it is a different row.
RAID 10’s tolerance is a floor. It always survives one failure, and it survives two if they land in different mirrors, which is likely but not guaranteed. I would size on the guarantee.
Parity gets cheaper with more drives, protection does not
This is the part that changes what you buy. Single parity always costs exactly one drive, however many you have:
| Drives (8 TB each) | RAID 5 usable | Efficiency | Survives |
|---|---|---|---|
| 3 | 16 TB | 67% | 1 |
| 4 | 24 TB | 75% | 1 |
| 6 | 40 TB | 83% | 1 |
| 8 | 56 TB | 88% | 1 |
| 12 | 88 TB | 92% | 1 |
Twelve drives with single parity is 92 percent efficient and still dies on the second failure, out of twelve chances. Double parity on the same twelve costs 80 TB instead of 88 and survives two:
| Drives (8 TB each) | RAID 6 usable | Efficiency | Survives |
|---|---|---|---|
| 4 | 16 TB | 50% | 2 |
| 6 | 32 TB | 67% | 2 |
| 8 | 48 TB | 75% | 2 |
| 12 | 80 TB | 83% | 2 |
The case for double parity strengthens as the array grows, because the capacity you give up shrinks as a fraction while the number of things that can fail goes up. At four drives the second parity drive costs a third of your capacity. At twelve it costs a tenth.
The NAS capacity calculator runs all of this against your own drive count and size, including the levels not tabulated here.
The rebuild is the risk
Losing a drive is not the dangerous moment. Replacing it is.
While the replacement resilvers, a single-parity array has no redundancy left and is reading every surviving drive end to end for hours. Those drives are the same age, the same model, and often from the same manufacturing batch as the one that just died. A second failure during that window takes the array.
Rebuild time scales with drive size. Reading a drive end to end at 150 MB/s:
| Drive size | Rebuild time |
|---|---|
| 4 TB | 7.4 hours |
| 8 TB | 14.8 hours |
| 12 TB | 22.2 hours |
| 16 TB | 29.6 hours |
| 20 TB | 37.0 hours |
| 24 TB | 44.4 hours |
That 150 MB/s is an optimistic input, not a measurement. A rebuild competing with normal use runs slower, and the same 16 TB drive takes a very different time depending on what else the array is doing:
| Rebuild throughput | 16 TB drive |
|---|---|
| 50 MB/s | 3.7 days |
| 100 MB/s | 1.9 days |
| 150 MB/s | 1.2 days |
| 200 MB/s | 0.9 days |
Three to four days with no redundancy is the scenario to plan against, and it is why large drives and single parity is an uncomfortable pairing. ZFS helps here by resilvering only the blocks that hold data rather than every sector, so a half-empty pool rebuilds in roughly half the time. A full one does not.
Two things ZFS does that traditional RAID does not
It closes the write hole. Traditional RAID updates data and parity as separate operations. Lose power between them and the stripe is self-contradictory, with no record of which half is stale, and a later rebuild may reconstruct from the wrong one. Hardware controllers address this with a battery-backed write cache. ZFS avoids it structurally by writing data and parity as a single transaction, so there is no window to be interrupted in.
It checksums everything. A traditional array reading a bad block during a rebuild has no way to know it is bad, and will happily reconstruct from it. ZFS verifies what it reads against a checksum and repairs from redundancy when they disagree.
That second point is what makes a scrub worth scheduling. A scrub reads everything stored, checks it, and fixes what it can, which is how silent corruption gets caught while there is still redundancy to fix it from. Without one, a bad block can sit unread for years and surface at the worst possible moment, during a resilver, when it is the only copy left. Monthly is a common cadence for a home array.
One thing to budget for: a scrub moves the whole array to active power for its duration, so it shows up on the meter and in the room as noise. If the array shares a room with anything else, how those two sources combine is less intuitive than it looks.
Your array will report less than you expect
Two separate deductions land before you store a byte.
Parity takes its share first: four 8 TB drives at single parity give 24 TB usable, not 32. Then the units change underneath you. Drive makers count a terabyte as a trillion bytes; operating systems count in powers of two. So 24 TB of usable capacity appears as 21.8 TiB, about nine percent smaller, with nobody at fault. Filesystem metadata and reserved space take a little more on top.
If you are budgeting to a target, work backwards from the TiB figure your operating system will show you, which the capacity calculator reports alongside the TB.
Drives cost power, permanently
Every drive in the array has a standing draw, whether or not anything is reading from it. Adding drives adds watts for as long as the array exists, which is a running cost that never appears in the purchase decision.
Take the drive count seriously for that reason, and cost it: the arithmetic is the same as everywhere else on this site, and I have worked it through in what a homelab really costs in electricity. The flip side of a machine that is already switched on is that anything else you ask of it is nearly free, which is the whole case for running models on the NAS itself. Spin-down helps if your workload tolerates it, and it is not free, because anything touching the array regularly keeps it awake and adds start cycles for nothing.
What I would actually pick
- Two drives, and the data matters: a mirror. Simple, fast to rebuild, and the surviving drive is a complete copy you can read on any machine.
- Three to five drives, mixed use: single parity. Accept that a large-drive rebuild is a long window and that this is the level a good backup covers for.
- Six or more, or drives above about 8 TB: double parity. The capacity cost has fallen to a fraction by then and the rebuild window has grown.
- You need write speed more than capacity: striped mirrors, and read the tolerance as one failure.
- Scratch space you can rebuild from source: striping only, deliberately, with the risk understood.
Whichever you pick, the backup is the thing that actually saves you. The array is what stops a dead drive from ruining your week.
FAQ
Is RAID a backup?
No, and treating it as one is the most expensive mistake in this subject. RAID protects against one specific failure, a drive dying, and every drive in the array sees your deletions, your ransomware and your power surges at the same instant. A backup is a separate copy that does not see those events. Keep three copies, on two kinds of media, one of them off site.
RAID 5 or RAID 6 for a home NAS?
Single parity if the array is small and the drives are small; double parity as either grows. The trade is concrete: on four 8 TB drives, double parity costs you 8 TB of the 24 you would otherwise have. On twelve drives it costs 8 TB of 88. Meanwhile a 16 TB drive can take over a day to rebuild, and single parity means that entire day has no redundancy.
What is the difference between RAID 5 and RAIDZ1?
The capacity arithmetic is identical: both give up one drive to parity and survive one failure. RAIDZ1 is part of ZFS rather than a layer under the filesystem, which lets it write data and parity as one transaction and so avoid the write hole, checksum everything it stores, and rebuild only the blocks in use. Those differences matter during a failure rather than during normal operation.
Do the drives need to be the same size?
For traditional RAID and RAIDZ, effectively yes: every drive is used only up to the size of the smallest, so a larger one wastes the difference. Some systems, notably Unraid and ZFS pools built from differently sized mirrored pairs, handle mixed sizes deliberately and trade something else for it. If you are mixing sizes, check what your specific system does before buying.
How often should I scrub?
Monthly suits most home arrays. The point is to find corruption while there is still redundancy to repair it from, rather than during a rebuild when there is not. Schedule it for a time when the noise and the power draw do not bother you, since the whole array is active for the duration.
Can I add one drive to an existing array later?
It depends on the system, and it is worth checking before you buy rather than after. Traditional RAID and several NAS operating systems support growing an array in place. ZFS historically expanded by adding a whole extra group of drives rather than one at a time, though single-drive expansion has since been added to RAIDZ. Either way the operation is long and it is one to have a current backup before starting.
Sources
- The taxonomy and the original level numbering come from Patterson, Gibson and Katz (1988), “A Case for Redundant Arrays of Inexpensive Disks (RAID)”, presented at SIGMOD. The levels have outlived most of the paper’s assumptions about drive sizes, which is part of why rebuild time now dominates the discussion.
- Capacity, efficiency, failure tolerance and rebuild time on this page are computed by the same code that runs the NAS capacity calculator. Drive sizes, rebuild throughput and per-drive wattage are illustrative inputs, not measurements: nothing on this page was measured on hardware. Take rebuild throughput from your own array during an actual resilver, because it is the input the answer is most sensitive to.
- The write hole and the checksum behaviour are properties of ZFS’s transactional design rather than results from a test. The OpenZFS documentation is the reference for both.