Rethinking RAID: When Mirrors Beat Parity in a Homelab
Why the array everyone reaches for is often the wrong one at home
Contents
Almost everyone building their first NAS reaches for parity RAID, and I understand exactly why. Parity — RAID5, RAID6, RAIDZ1, RAIDZ2 — promises the best storage efficiency: buy five disks, lose only one disk’s worth to redundancy, keep four disks’ worth of usable space. Mirroring feels wasteful by comparison, because half your capacity vanishes into the copy. On a spreadsheet parity wins, and the spreadsheet is the wrong tool for this decision. After running both at home, I now build mirrors far more often than the capacity maths suggests I should, and this article is the argument for why.
I want to be careful here. Parity RAID is not wrong, and for some workloads it is clearly correct. The point is that the default reasoning — “parity gives more space per pound, so parity” — skips the questions that actually determine whether your array survives a bad day. Once you weigh rebuild risk, rebuild time, IOPS and how you will expand, the mirror looks a lot better than its capacity efficiency implies. If you are choosing a pool layout before you commit data to it, this is the decision to get right, because reshaping later is painful.
Why parity is seductive and where it hurts
Parity works by computing redundancy information across a stripe of disks. RAID5 and RAIDZ1 tolerate one disk failure; RAID6 and RAIDZ2 tolerate two. The appeal is capacity: in a six-disk RAIDZ2 you keep four disks of usable space and can lose any two drives. Nothing about mirroring comes close to that ratio.
The cost shows up when a disk dies and you replace it. To rebuild a parity array, the controller must read every block on every surviving disk to recompute the missing data. On a six-disk array of large modern drives that is tens of terabytes of reads, and it happens while the array is already degraded and under load. The rebuild can take many hours, sometimes more than a day, and throughout that window you are running without the redundancy you were relying on. If a second disk hiccups during a single-parity rebuild, the array is gone.
Mirrors rebuild differently. To restore a mirror you copy from the surviving half of that one pair to the new disk. There is no array-wide read, no parity recomputation, and no stress on unrelated disks — only the one mirror pair is involved. The rebuild reads one disk’s worth of data and writes it to one disk, which finishes far faster and touches far less hardware. A shorter, gentler rebuild is a smaller window of exposure, and the exposure window is where arrays die.
The unrecoverable read error problem
Here is the argument that changed how I build arrays. Hard drives have a specified unrecoverable read error (URE) rate — the manufacturer’s own figure for how often a read returns bad data that error correction cannot fix. For a typical consumer drive that rate is on the order of one URE per 10^14 bits read, roughly one per 12.5 terabytes.
Now picture a single-parity array of several large disks. One disk fails, and to rebuild you must read every remaining disk in full — easily tens of terabytes of reads across the survivors. When the total data you must read to rebuild approaches the same order of magnitude as the URE interval, the probability of hitting an unrecoverable read during the rebuild stops being negligible. On a traditional RAID5 controller a URE mid-rebuild can abort the whole rebuild, because the controller cannot reconstruct that stripe and gives up. You lose the array to one dead disk plus a single bad sector on a survivor at the worst possible moment — no second full drive failure required.
This is the maths behind the widely repeated claim that RAID5 is unsafe on large modern disks. It is a probability argument, and the probability grows with disk size, which is why it has got worse over the years as drives ballooned. RAIDZ (ZFS) handles a URE more gracefully than a dumb hardware controller — it knows which file a bad block belongs to and can often carry on with a single reported error rather than failing the whole rebuild — but the underlying pressure is real, and it is the strongest reason to prefer either double parity (RAIDZ2) or mirrors on big drives, rather than single parity.
A mirror rebuild dodges most of this. You read only the surviving disk of that one pair to rebuild rather than the whole array, so the total data read during the vulnerable window is a fraction of what a parity rebuild demands, and the odds of a fatal URE fall accordingly.
IOPS: the number nobody checks until it hurts
Capacity is the number everyone plans around; IOPS is the one that actually makes the NAS feel fast or slow, and parity is bad at it. In a parity array a single small random write can turn into a read-modify-write cycle across multiple disks, so the whole array delivers roughly the random-write performance of one disk no matter how many disks it contains. Add more disks to a RAIDZ vdev and you get more capacity, not more IOPS.
Mirrors scale the other way. In ZFS, a pool of several mirror pairs stripes across those pairs, so read IOPS scale with the number of mirrors and writes scale with the number of vdevs. A pool of three two-way mirrors comfortably outperforms a six-disk RAIDZ2 for the random workloads that hammer a home server — running VMs, container volumes, databases, anything that is not big sequential media. If your NAS also hosts application storage rather than only films, this difference is felt daily.
This is also why serious ZFS deployments that need performance use pools of mirrors rather than wide RAIDZ vdevs. The capacity cost buys you IOPS and rebuild safety, and for a busy home server that is frequently the better trade.
Expansion: the quiet advantage
How you grow the array matters as much as how you build it, and here mirrors have a decisive edge for the incremental way homelabs actually expand. Adding capacity to a ZFS pool of mirrors is trivial: buy two more disks, add them as a new mirror vdev, and the pool grows immediately. You expand two disks at a time, whenever you like, at whatever capacity is cheap that month.
Growing a RAIDZ vdev has historically been the sore point. For years you simply could not add a single disk to an existing RAIDZ vdev at all — the only way to grow was to replace every disk in the vdev with a larger one, one at a time with a full resilver between each, or to add an entire second vdev of several disks at once. That is a lot of money and a lot of rebuild cycles to add capacity. RAIDZ expansion has been in development to soften this, but the mirror’s “add two disks whenever” flexibility remains the friendlier model for the way most of us grow storage.
There is a middle path worth knowing about if flexible expansion is your priority above all: SnapRAID with mergerfs pools individually-formatted disks with parity computed on a schedule, letting you mix disk sizes and add one drive at a time. It suits a media library that is written once and rarely changed. I covered that pattern in flexible bulk storage for media hoarders; it trades live redundancy for flexibility, which is the opposite trade to a mirror.
A quick command tour
For ZFS, the pool topology is chosen at creation and the syntax makes the shape explicit. A pool of two mirror vdevs:
| |
Compare a single RAIDZ2 vdev of six disks:
| |
Always reference disks by their /dev/disk/by-id/ path rather than /dev/sda, because the kernel’s short names are reassigned across reboots and you do not want a pool built on names that move. Whichever topology you pick, the replication story on top is the same — being able to ship snapshots off the box with ZFS send/receive matters far more to your data’s survival than the RAID level does.
Troubleshooting and the mistakes I have made
A resilver is crawling and the pool feels dead. A parity resilver reads the whole array and competes with your normal workload for disk time. Expect it to be slow and the NAS to feel sluggish throughout — a healthy resilver simply competes with your workload for disk time. On ZFS you can tune resilver throttling, but the honest fix is a topology (mirrors) that resilvers faster in the first place.
“I built RAID so I do not need backups.” RAID protects against disk failure and nothing else. It does not protect against a deleted file, a corrupted database, ransomware, a failed PSU frying several disks at once, theft or fire. RAID is an availability tool that keeps the array serving while you replace a dead disk; it is one component of a data-safety plan, and the plan itself is the 3-2-1 rule properly implemented. Treating an array as a backup is the single most expensive mistake in home storage.
Mixed disk sizes in a mirror or vdev. A vdev is sized by its smallest member, so a mirror of a 4 TB and an 8 TB disk gives you 4 TB and wastes half the big drive. Match sizes within a vdev; use the odd-size disks in their own pair.
Rebuilding onto a disk from the same batch. Disks bought together, run together and stressed together tend to fail together, which is exactly the correlated failure that kills arrays mid-rebuild. Where you can, mix manufacture batches across a vdev so the survivors are not all the same age under the same load.
No scrubs scheduled. Redundancy only helps if the array notices corruption before you need it. Schedule a monthly zpool scrub (or the mdadm equivalent) so latent bad blocks are found and repaired from redundancy while you still have redundancy, rather than discovered during a rebuild.
Verdict: is it worth it, and for whom?
For a busy home server that runs VMs, containers and databases as well as storing files, build mirrors. You give up capacity efficiency and get faster rebuilds, a much smaller URE exposure window, IOPS that scale with the pool, and the freedom to grow two disks at a time. That combination has saved me real grief, and the capacity I “lost” turned out to be the cheapest insurance I have ever bought.
Parity still wins in specific cases: a large media archive that is mostly big sequential files, written once and read occasionally, where capacity per pound genuinely dominates and IOPS barely matter — there, RAIDZ2 (double parity, never single on large disks) is a sound choice. If you are storing tens of terabytes of films and rarely writing to them, parity is the efficient answer. For everything more active than that, the mirror is the array I wish more people started with, and the one I now reach for by default. Whichever you choose, remember that no RAID level is a backup, and pair the array with real off-box copies before you trust it with anything you cannot lose.
Related Content
