ZFS pool design for a 4-bay homelab: the decisions that actually matter

A 4-bay homelab is the most common starting point for a serious self-hosted setup, and it is also where the most common pool-design mistakes happen. The wrong decision at the start does not show up for two years — until a drive fails, the resilver takes a week, and you discover you have been one bad block away from losing everything since 2024.

This guide is the design conversation I have with myself every time I plan a new pool. It is opinionated. Every recommendation has a reason. If you disagree with any of them, do the research and disagree on purpose — that is fine — but do not skip the decision.

The three decisions that matter most

For a 4-bay pool, there are exactly three architectural decisions that determine the next decade of your storage experience:

1. Topology — mirror vs RAIDZ1 vs RAIDZ2
2. Drive selection — what disks to buy
3. ashift and recordsize — the boring tuning that you cannot change later

Get these right and the rest is operational hygiene. Get one wrong and you live with the consequences until you rebuild the pool from scratch.

Topology: pick mirrors

For a 4-bay homelab, the right answer is almost always two mirror vdevs in a single pool. The tradeoffs:

Topology	Capacity	Read perf	Write perf	Rebuild time	Survives	Expandable
2× mirror	50% (2 of 4 drives)	~2× single	~2× single	Fast (single-drive copy)	1 drive per mirror	Yes, add mirrors
RAIDZ1 (4-wide)	75% (3 of 4 drives)	~3× single	~1× single	Slow (rebuild whole stripe)	Any 1 drive	No, rebuild required
RAIDZ2 (4-wide)	50% (2 of 4 drives)	~2× single	~1× single	Slowest	Any 2 drives	No, rebuild required

The seductive option is RAIDZ1. You get 75% capacity utilisation — three usable drives instead of two — which feels like a free bonus. The problem is what happens during a resilver. With 18TB or 20TB drives (which is what you are buying in 2026), a RAIDZ1 resilver of a fully-written pool can take three to seven days. During that window, you are one drive failure away from total data loss. Modern enterprise studies have shown that the probability of a second drive failure during a long resilver is not negligible — that is exactly why enterprise shops moved off RAID5-equivalents fifteen years ago.

Mirror vdevs do not have this problem. A failed mirror member resilvers in roughly the time it takes to read one drive end-to-end — usually 12 to 24 hours for an 18TB drive. The pool stays redundant on the other mirror through the entire process. You also get noticeably better random read performance (each mirror can serve different reads) and the ability to grow the pool by adding more mirror vdevs later — RAIDZ vdevs cannot be expanded the same way, even with the newer RAIDZ expansion feature, which has caveats.

The cost is 50% capacity. For a 4-bay pool that is the only real downside, and it is usually the right trade.

The exception: if your workload is “I just want bulk archive storage, I have backups elsewhere, I am okay with a long resilver because nothing on this pool is irreplaceable,” RAIDZ1 can be fine. Just know what you are signing up for.

Drive selection: what to actually buy in 2026

The drive market in 2026 is roughly:

A few non-obvious tips:

• Mix vendors, not models. Buying 4 of the same drive from the same batch means 4 drives with the same firmware bug and the same MTBF curve. Buy 2 WD and 2 Seagate of similar capacity. The 5–10% premium is the cheapest insurance you will ever pay.
• Used enterprise drives are excellent value if you buy from a reputable reseller (ServerPartDeals, GoHardDrive, RecycledGoods) and you check SMART before deploying. Five years of power-on hours on an enterprise drive is roughly equivalent to one year on a consumer drive in terms of stress. Look at smartctl -a for Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable — any non-zero is a return.
• Burn-in matters. Before a drive joins a pool, run badblocks -wsv /dev/sdX or equivalent (this destroys data — do it on the empty drive). It takes 24–48 hours for a large drive and catches infant mortality before your data is on it.

ashift and recordsize: set them right, set them once

ashift is the physical block size ZFS assumes for the drive. For any modern HDD or SSD, ashift=12 (4K sectors) is correct. For drives that report 4Kn natively or are confirmed 16K (some recent enterprise drives) you may want ashift=13. Never go below 12 on a modern drive. ashift is set at vdev creation and cannot be changed without rebuilding the vdev — get this right at create time.

recordsize is per-dataset and is the maximum block size ZFS uses for writes within that dataset. The default is 128K. For most homelab uses, the right move is:

• General-purpose data (Documents, media): leave at 128K default
• Bulk media (large videos, ISO images, datasets): bump to 1M (recordsize=1M)
• Database storage (Postgres, MySQL data dirs): drop to 16K or whatever the DB’s block size is
• Virtual machine images (.vmdk, .qcow2): typically 64K
• Containers / docker volumes: 128K is fine

Wrong recordsize causes write amplification and bad performance, but unlike ashift it can be changed per-dataset and only applies to new writes. Get the big ones right at the start; tune the rest as you observe.

Compression and dedup

Always turn on compression. zstd is the modern default — better compression ratio than lz4 with negligible CPU cost on any modern CPU. compression=zstd (or zstd-3 to specify level) at the pool root and it inherits down.

Never turn on dedup. ZFS dedup is famously a foot-gun — the memory cost is enormous (rule of thumb: 5GB of RAM per TB of pool) and the performance penalty is severe. Modern versions of ZFS have a feature called Fast Dedup that significantly improves the picture, but for a 4-bay homelab the answer is still “do not bother.”

Special vdev: the cheat code for mixed workloads

A special vdev is a small NVMe-backed vdev that ZFS uses for metadata and (optionally) small blocks. This is the single biggest performance upgrade you can make to a HDD-based pool — directory traversal, ls -la on large directories, application startup that touches many files — all of this becomes effectively SSD-speed.

Recommended setup for a 4-bay homelab:

• 2× small (~500GB) enterprise NVMe drives as a mirror special vdev
• Set special_small_blocks=64K on datasets that benefit
• Critical: if a special vdev dies and is not mirrored, you lose the whole pool. Always mirror the special vdev.

This requires bays beyond the 4 main bays. A motherboard with at least 2 NVMe slots is needed — most modern boards have this. Used enterprise NVMe drives (Samsung PM9A3, Micron 7300, Intel S4510) are $80–$150 for 480–960GB.

Snapshots and replication: free reliability

ZFS snapshots are constant-time and almost-free. Set up sanoid to take snapshots automatically:

[Documents]
  hourly = 24
  daily = 30
  monthly = 12
  yearly = 5

Then replicate to a second machine or a USB-attached external drive with syncoid. This combination — snapshots plus off-pool replication — gives you point-in-time restore for ransomware, fat-finger deletions, and silent corruption that scrubs missed. There is no equivalent feature in any commercial NAS at this price point.

What I would actually buy in 2026

For a clean-slate 4-bay homelab build:

Operational hygiene

Three things to set up before the pool is more than a week old:

1. Scheduled scrubs. systemctl enable zfs-scrub-monthly@yourpool.timer (or equivalent). Once a month, ZFS reads every block and verifies the checksum. Catches bit rot before it matters.
2. SMART monitoring. smartd with email alerts for any drive showing reallocated sectors, pending sectors, or rising temperature. Drives almost always warn you before they die — if you are paying attention.
3. A documented restore. Test that you can actually restore from your replicated snapshot. Untested backups are not backups. Do this on the first weekend of every quarter.

The honest summary

The decisions in this guide are not about ZFS expertise; they are about not putting yourself in a position where the recovery path is harder than it needs to be. A 4-bay homelab can be the most reliable storage in your life if you set it up with mirror vdevs, mixed-vendor enterprise drives, a mirrored special vdev, sensible recordsize per dataset, monthly scrubs, and tested off-pool replication. Or it can be a single resilver away from data loss. The difference is the half day you spend up front making the boring decisions correctly.

Spend the half day.