ZFS for Home Servers: A Practical Primer

Why people love ZFS

ZFS is a combined filesystem and volume manager built for one overriding goal: your data is exactly what you wrote, forever. It checksums every block, self-heals corruption, takes instant snapshots, compresses transparently, and does software RAID without the classic "write hole". For a home NAS or Proxmox host, it's a fantastic foundation — if you understand a few concepts first.

The building blocks

ZFS has a clear hierarchy:

vdev (virtual device) — a group of physical disks arranged for redundancy (a mirror, or a RAID-Z group).
pool (zpool) — one or more vdevs combined into a single storage pool.
dataset — a filesystem within the pool with its own settings (compression, quotas, snapshots).

Crucial rule: a pool's redundancy comes from its vdevs. Losing a whole vdev loses the whole pool, so each vdev must be redundant.

Choosing a layout

Mirror (RAID 1-like) — two (or more) disks holding the same data. Fast, simple, easy to expand by adding pairs. Great for small NAS builds and VM storage.
RAID-Z1 — single parity, like RAID 5. One disk of redundancy. Fine for 3–5 smaller disks, but risky with large modern drives (long resilver times).
RAID-Z2 — double parity, like RAID 6. The sweet spot for a 6–8 drive home NAS: you can lose any two drives.
RAID-Z3 — triple parity, for large arrays where resilver windows are long.

For most people: mirrors for VM/SSD pools, RAID-Z2 for bulk storage.

RAM and the ARC

ZFS uses free RAM as a read cache called the ARC, which is why ZFS "loves RAM". A rule of thumb is 1 GB RAM per TB of storage as a comfortable baseline, plus whatever your VMs and apps need. It runs on less, but performance improves with more.

ECC RAM is recommended for maximum integrity, though ZFS is still safer than most alternatives on non-ECC hardware. Don't let "no ECC" stop you from using ZFS.

Snapshots: your time machine

Snapshots are near-instant, space-efficient, read-only views of a dataset at a point in time:

# Create a snapshot
zfs snapshot tank/data@2026-07-16
 
# Roll back to it
zfs rollback tank/data@2026-07-16
 
# Browse files without rolling back
ls /tank/data/.zfs/snapshot/2026-07-16/

Automate them with a tool like sanoid for a schedule such as hourly/daily/weekly. Snapshots are perfect for undoing mistakes and ransomware — but they are not a backup, because they live on the same pool. Replicate them elsewhere with zfs send/receive for real protection.

Compression: turn it on

Modern LZ4/ZSTD compression is nearly free and often improves performance by reducing I/O. Enable it on your datasets:

zfs set compression=zstd tank/data

The special devices (know before you add them)

SLOG / ZIL — a SLOG only speeds up synchronous writes (NFS for VMs, databases) and needs power-loss-protected SSDs. It does nothing for a typical media NAS.
L2ARC — an SSD read cache that helps only specific workloads and consumes RAM to index. Add RAM before adding L2ARC.
Special vdev — stores metadata/small files on SSD; powerful but its failure can kill the pool, so it must be redundant.

Don't add these "just because". Most home pools need none of them.

When ZFS is worth it — and when it isn't

Use ZFS when: data integrity matters, you want snapshots and replication, and you have a few GB of RAM to spare. Ideal for TrueNAS and Proxmox.

Consider alternatives when: you're on very low-RAM hardware (a small Pi), or you want to mix random drive sizes and expand one disk at a time — where something like Unraid or Btrfs may fit better.

Maintenance

Scrub monthly: zpool scrub tank verifies every block and repairs corruption. Schedule it.
Watch S.M.A.R.T. and replace drives showing errors early.
Leave headroom: keep pools below ~80% full for consistent performance.

Next steps

Ready to build? Follow How to Build Your First NAS, then set up snapshot replication as the local half of your 3-2-1 backup strategy.