Intermediate

Storage and ZFS

ZFS basics, pools, and snapshots - why it's worth the learning curve for a homelab that's starting to matter to you.

Storage Updated August 29, 2026

  • zfs
  • storage
  • snapshots
  • proxmox
Before this, read:

ZFS is available as a storage option directly in the Proxmox installer and in the web UI afterward, which is the main reason it's the practical default for this tier rather than a separate research project.

Why ZFS specifically

Regular filesystems (ext4, NTFS) trust the disk to report data correctly. Disks occasionally lie - bit rot, a failing sector that doesn't fail loudly, a bad cable - and a normal filesystem has no way to notice. ZFS checksums every block it writes and every block it reads back, so silent corruption gets detected (and, with redundancy, automatically corrected) instead of quietly living in your data until you notice a corrupted photo or a database that won't start.

The other reason it matters here: snapshots are nearly free. A ZFS snapshot doesn't copy data - it just freezes the current state of the filesystem's metadata, so it takes seconds and costs almost no space until data actually changes afterward. That makes "snapshot before I do something risky" a habit with basically no downside, which is exactly the safety net you want once you're running VMs and containers you'd be annoyed to rebuild from scratch.

Pools, vdevs, and redundancy

A ZFS pool is built from one or more vdevs (virtual devices), each made of one or more physical disks. The vdev layout determines your redundancy:

  • Single disk - no redundancy, same risk profile as any other filesystem. Fine for scratch/cache data, not for anything you'd miss.
  • Mirror (2+ disks) - full redundancy, any one disk can fail without data loss. The simplest, most homelab-friendly option - usable capacity is roughly one disk's worth per pair.
  • RAIDZ1/RAIDZ2 - parity-based redundancy across 3+ disks, more usable capacity per disk than mirroring, tolerates one (RAIDZ1) or two (RAIDZ2) disk failures. More CPU/RAM overhead and slower to resilver after a failure than a mirror.

For a first homelab ZFS pool, mirrored pairs are the easiest to reason about and expand later (add another mirror vdev to the pool rather than restructuring everything).

⚠️ Risk: ZFS redundancy protects against disk failure, not against deleting the wrong file, ransomware, fire, or theft. A ZFS pool - even a redundant one - is not a backup on its own. Snapshots plus a real off-site copy (see Proxmox Backups and Backups 101) are still required.

RAM expectations

ZFS uses RAM for its own read cache (ARC - Adaptive Replacement Cache), which is why "ZFS wants a lot of RAM" is a common warning. Realistically for a homelab: 8GB is a reasonable floor if ZFS is sharing the host with VMs/containers, and ZFS will use available RAM opportunistically but release it under memory pressure - it's not a hard reservation like VM RAM is. ECC RAM is often recommended for ZFS but not strictly required for a homelab; it reduces (doesn't eliminate) one narrow failure mode and is a "nice to have," not a blocker.

Setting up a pool in Proxmox

From the web UI: Datacenter > Storage, or per-node Disks > ZFS > Create: ZFS. Select your disks, choose the RAID level (Proxmox's UI term for vdev layout), name the pool, and create it. Proxmox then lists it as a storage target usable for VM disks, container volumes, or ISO/backup storage, depending on what you enable.

Command-line equivalent, for reference:

zpool create -o ashift=12 tank mirror /dev/sda /dev/sdb
  • ashift=12 matches modern 4K-sector disks - worth setting explicitly rather than trusting auto-detection, which occasionally gets it wrong on drives that lie about their sector size.
  • tank is just a pool name - call it whatever's meaningful to you.

Snapshots in practice

zfs snapshot tank/data@before-upgrade
zfs list -t snapshot
zfs rollback tank/data@before-upgrade

In the Proxmox UI, snapshots are also exposed per-VM/container (Guest > Snapshots > Take Snapshot) when the guest's storage is on ZFS - take one before any risky change (an OS upgrade, a config overhaul) and roll back in seconds if it goes wrong. Snapshots aren't free forever, though - they hold onto the data blocks that existed at snapshot time, so old snapshots on a filesystem with a lot of churn will accumulate real disk usage. Prune ones you don't need.

Next: Network Segmentation.