Proxmox ZFS Setup: The Only Guide Your Homelab Actually Needs

I've been running ZFS on Proxmox for about three years now. In that time, I've lost exactly zero VMs to data corruption. Zero. Compare that to the ext4 install I started with, which somehow managed to corrupt a Docker container's database within six months (don't ask - it was a learning experience).

If you're running Proxmox and still using LVM or ext4 for your VM storage, you're leaving a lot on the table. ZFS isn't just for enterprise NAS boxes anymore - it's the single most useful tool in a homelabber's storage toolkit. And setting it up is way easier than most guides make it look.

This guide covers everything - from choosing your hardware to creating your first pool, configuring datasets for VMs, and actually using the features that make ZFS worth the effort. No filler, no fluff, just the stuff you need.

Why ZFS on Proxmox?

Before we get into the how, let's talk about the why - because understanding this changes how you think about your storage.

ZFS is a combined filesystem and volume manager. That means it handles both the filesystem (where your data lives) and the volume management (how disk space is allocated and protected) in one layer. Traditional Linux storage stacks these separately - you have ext4 or XFS on top of LVM on top of your physical disks. ZFS replaces all of that with one coherent system.

The practical benefits for a Proxmox homelab:

• Checksumming - ZFS verifies every block of data it reads. If a bit flips (and they do, more often than you'd think), ZFS knows and can fix it using parity or mirror copies. This is how you get zero silent data corruption.
• Snapshots - Take a point-in-time snapshot of your VM disk in seconds. Roll back instantly if an update goes sideways. No more reinstalling from scratch because you forgot to snapshot before running apt upgrade.
• Compression - LZ4 compression is practically free on modern CPUs. You get 30-50% space savings on most VM data with zero measurable performance hit. That 1TB of VM disks? You're actually using 500-600GB.
• Copy-on-write - Writes don't overwrite existing data. This means snapshots are instant and space-efficient, and you never get a half-written state after a crash.
• RAID-Z and mirrors - Built-in redundancy without needing a hardware RAID controller. Your data is protected at the filesystem level, not the controller level.

If you've read our guide on Virtual Machines vs Containers, you already understand the value of running VMs on Proxmox. ZFS makes that VM layer bulletproof.

Hardware Considerations

ZFS has a reputation for being RAM-hungry. It's not wrong - ZFS uses RAM for its Adaptive Replacement Cache (ARC), and more cache means better read performance. But the "1GB per TB of storage" rule that gets thrown around is for enterprise setups with hundreds of drives.

For a homelab running 4-8 VMs on 2-4TB of storage:

• RAM: 16GB is the sweet spot. 8GB is the minimum - ZFS will work, but you'll notice slower I/O under heavy load. If you're buying a Proxmox server, budget for 32GB so you have headroom.
• Drives: Use SSDs for your VM storage. Seriously. ZFS on spinning disks works, but your VMs will feel sluggish. If you're on a budget, a 1TB NVMe drive for your VM pool and a separate HDD for bulk storage is the move.
• HBA Card: If you're using more than 4 drives, get an HBA (Host Bus Adapter) in IT mode - not RAID mode. The LSI 9211-8i is the gold standard for homelabs. It passes drives directly to ZFS without any RAID abstraction getting in the way.
• UPS: ZFS really, really doesn't like power loss during writes. A basic UPS for your Proxmox box and drives is non-negotiable if you care about your data.

Installing ZFS on Proxmox

Option 1: Install Proxmox with ZFS (Clean Install)

The easiest path. During the Proxmox VE installer, select "ZFS (RAID1)" or your preferred layout when choosing the filesystem. The installer will set up everything automatically - pool, datasets, and storage configuration.

This is the recommended approach if you're starting fresh. You get ZFS as your root filesystem, which means your Proxmox installation itself is protected.

Option 2: Add ZFS to an Existing Proxmox Install

More common scenario - you already have Proxmox running on ext4 or LVM and want to add ZFS storage. Here's how:

Step 1: Install ZFS utilities

apt update
apt install -y zfsutils-linux

Verify it's working:

zfs version

You should see something like zfs-2.1.5-pve1-2 or newer.

Step 2: Create your pool

This is where the real setup happens. Let's say you have two 1TB NVMe drives - /dev/nvme0n1 and /dev/nvme1n1 - and you want a mirrored pool:

zpool create -o ashift=12 rpool mirror /dev/nvme0n1 /dev/nvme1n1

Breaking that down:

• zpool create - creates a new ZFS pool
• -o ashift=12 - sets the sector alignment (12 = 4K sectors, use this for all modern drives)
• rpool - the pool name (you can call it whatever you want - tank, fast, vmpool, etc.)
• mirror - creates a mirrored vdev (like RAID1)
• The two device paths - your physical drives

For a RAIDZ1 setup with three 4TB drives:

zpool create -o ashift=12 rpool raidz1 /dev/sdb /dev/sdc /dev/sdd

Step 3: Enable compression

zfs set compression=lz4 rpool

Do this immediately after creating the pool. LZ4 is the default for a reason - it's fast, effective, and has essentially zero overhead. I've tested it on and off, and I've never seen a reason to disable it.

Step 4: Enable atime off

zfs set atime=off rpool

This disables access time tracking, which reduces unnecessary writes. Your VMs don't need to know every time a file was read.

Step 5: Add the pool to Proxmox

You can do this through the GUI or CLI.

GUI method:

1. Go to Datacenter - Storage - Add - ZFS
2. Select your pool name
3. Choose the content types (Disk image, ISO images, Container templates, etc.)
4. Click Add

CLI method:

pvesm add zfs rpool --content images,rootdir

This tells Proxmox to use rpool for VM disk images and container root directories.

Choosing Your Pool Layout

This is the question I get asked most. "Should I use mirrors or RAIDZ?" The answer depends on how many drives you have and what you're optimizing for.

Mirror Vdevs (2-4 drives)

Best for: Most homelabs. Simple, fast, easy to expand.

A mirror is two (or more) drives storing identical copies. You lose 50% of your total capacity but gain excellent read performance and dead-simple recovery.

# 2-drive mirror
zpool create -o ashift=12 tank mirror /dev/sdb /dev/sdc

# 4-drive mirror (two mirrored pairs)
zpool create -o ashift=12 tank mirror /dev/sdb /dev/sdc mirror /dev/sdd /dev/sde

Why mirrors are great for homelabs:

• Read performance scales with the number of drives (reads from both drives simultaneously)
• Rebuild times are fast - you're only copying one drive's worth of data
• You can add more mirrors later to expand the pool
• Failed drive replacement is straightforward

The tradeoff: You're paying 50% capacity for redundancy. Two 1TB drives give you 1TB of usable space. But for a VM server, the speed and simplicity are worth it.

RAIDZ1 (3-5 drives)

Best for: When you need more capacity and can tolerate slightly slower writes.

RAIDZ1 is ZFS's equivalent of RAID5 - single parity protection. You lose one drive's worth of capacity to parity.

# 4-drive RAIDZ1
zpool create -o ashift=12 tank raidz1 /dev/sdb /dev/sdc /dev/sdd /dev/sde

With four 4TB drives, you get 12TB usable (3 x 4TB). That's better than mirrors for raw capacity.

The caveats:

• Write performance is lower than mirrors (parity calculation overhead)
• Rebuild times are longer - you're reading the entire pool to verify parity
• Don't go above 5-6 drives in a single RAIDZ1 vdev - rebuild times get painful
• For VM storage specifically, the write performance hit matters more than you'd think

RAIDZ2 (4-6 drives)

Best for: When you can't afford to lose data and have enough drives.

RAIDZ2 is double parity - like RAID6. You can lose any two drives without data loss.

zpool create -o ashift=12 tank raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

Honestly, for most homelabs, RAIDZ2 is overkill. You're paying a lot of capacity (two drives' worth) for redundancy against a scenario that's extremely rare with modern drives. Mirrors or RAIDZ1 are usually the right call.

My Recommendation

For a homelab Proxmox server running VMs and containers:

Start with a 2-drive mirror. It's the simplest, fastest, and easiest to recover from. If you need more space, add another mirror vdev later - ZFS makes this painless.

If you have 4+ drives and need the capacity, go RAIDZ1 with 3-4 drives. Just know that your write performance will be lower than mirrors.

Configuring Datasets for VMs

Once your pool is created, you'll want to set up datasets - think of them as ZFS's version of folders, but with their own properties and quotas.

Create a dataset for VM disks:

zfs create rpool/vms

Create a dataset for container storage:

zfs create rpool/containers

Create a dataset for ISO images:

zfs create rpool/isos

Set per-dataset properties:

# VMs need sync=standard (or sync=disabled for better performance at the cost of safety)
zfs set sync=standard rpool/vms

# Containers can use sync=disabled if you're okay with the risk
zfs set sync=disabled rpool/containers

# ISOs don't need snapshots or special properties
zfs set compression=lz4 rpool/isos

Set quotas to prevent one dataset from eating all your space:

# Limit VM dataset to 500GB
zfs set quota=500G rpool/vms

This is useful if you're sharing the pool between VMs and containers and don't want a runaway container to fill up your VM storage.

Compression and Caching

Compression

Enable LZ4 on everything. Seriously.

zfs set compression=lz4 rpool

I've benchmarked this extensively on my homelab. On typical VM workloads (mixed reads/writes, databases, web servers), LZ4 reduces disk usage by 30-50% with less than 1% CPU overhead. That's not a typo - the CPU cost is essentially zero.

For datasets with highly compressible data (logs, text files), you might see 60-70% compression ratios. For already-compressed data (video files, compressed databases), it'll be closer to 0-5%.

The only time I'd consider disabling compression is on a dataset storing large binary files that are already compressed - and even then, the overhead is so low it's not worth the complexity of managing per-dataset settings.

Special Devices (L2ARC and SLOG)

If you want to go deeper, ZFS supports two types of special devices:

L2ARC (read cache): An SSD that caches frequently-read data from your main pool. If your main storage is on HDDs and you have a spare SSD, this can dramatically improve read performance for hot data.

zpool add tank cache /dev/sde

SLOG (write cache): A fast, power-loss-protected SSD that handles synchronous writes. This improves write performance for workloads that use sync=standard or sync=always.

zpool add tank log /dev/sdf

My honest take: For most homelabs running NVMe main storage, L2ARC and SLOG are unnecessary. Your NVMe drives are already fast enough that the ARC (RAM cache) handles most reads, and writes are already quick. I'd only add these if you're running spinning disks for your main pool.

Snapshot Management

This is where ZFS really shines for Proxmox homelabs. Snapshots let you take a point-in-time copy of your VM disk instantly, and then roll back to it just as quickly.

Take a snapshot:

# Snapshot a single VM disk
zfs snapshot rpool/vms/vm-100-disk-0@before-update

# List all snapshots
zfs list -t snapshot

# Roll back to a snapshot
zfs rollback rpool/vms/vm-100-disk-0@before-update

Pro tip: Name your snapshots with a convention. I use @pre- for pre-maintenance snapshots and @date- for periodic ones. Something like @pre-apt-upgrade or @2026-06-14-weekly. You'll thank yourself later when you're scrolling through a list of 50 snapshots trying to figure out which one to roll back to.

Automate snapshots with a cron job:

# Add to /etc/cron.d/zfs-snapshots
0 */6 * * * root /sbin/zfs snapshot -r rpool/vms@auto-$(date +\%Y\%m\%d-\%H\%M)

This takes a recursive snapshot of all VMs every 6 hours. Combined with Proxmox Backup Server, this gives you both instant rollback and long-term backup coverage.

Speaking of backups - if you haven't set up a backup strategy yet, check our Homelab Backups guide for the full picture. ZFS snapshots are one piece of the puzzle, but they're not a complete backup solution.

Common Mistakes (and How to Avoid Them)

After helping a bunch of people set up ZFS on Proxmox, here are the mistakes I see most often:

1. Using a single drive with no redundancy

Yes, ZFS works on a single drive. No, you should not do this for production VM storage. You get checksumming and compression, but zero protection against drive failure. If your VM disk dies, it's gone.

2. Forgetting to set ashift=12

The default ashift can be 9 (512-byte sectors) on some systems. Modern drives use 4K sectors. If you create a pool with ashift=9 on 4K drives, you get write amplification and reduced performance. Always set ashift=12 explicitly.

3. Using RAIDZ1 with too many drives

I've seen people create 8-drive RAIDZ1 vdevs. Don't. Rebuild times on a full RAIDZ1 with 8 x 4TB drives can take 24+ hours, and during that time your pool is vulnerable. Stick to 3-5 drives per RAIDZ1 vdev.

4. Not monitoring your pool

ZFS pools can degrade silently if a drive starts having problems. Set up monitoring:

# Check pool status
zpool status

# Check for errors
zpool scrub tank

Run a scrub monthly. It verifies all data and catches silent corruption early. If you're using Proxmox, you can set up a cron job for this.

5. Ignoring sync writes

By default, ZFS uses sync=standard for datasets. This means synchronous writes (like database transactions) are committed to the pool before the application gets confirmation. If you're running databases in VMs, this is correct behavior - don't disable it to chase benchmarks. You'll regret it when a power loss corrupts your database.

Connecting to Existing Homelab Infrastructure

ZFS on Proxmox plays nicely with the rest of your homelab stack:

• Docker containers running in VMs benefit from ZFS's copy-on-write when you're doing frequent container rebuilds. If you're still learning Docker, our Docker for Homelabs guide covers the basics.
• Proxmox networking matters for storage performance - if you're using NFS or iSCSI shares from your ZFS pool, make sure your network can handle the throughput. Our Cloudflare Tunnel vs VPN guide covers remote access patterns.
• Proxmox vs other hypervisors - ZFS integration is one of Proxmox's strongest advantages over ESXi and Hyper-V. The native ZFS support means no third-party plugins or awkward workarounds.

Quick Reference: ZFS Commands

Here's a cheat sheet of the commands you'll actually use day-to-day:

# Pool status
zpool status

# List all pools
zpool list

# List datasets
zfs list

# Take a snapshot
zfs snapshot pool/dataset@name

# List snapshots
zfs list -t snapshot

# Roll back to snapshot
zfs rollback pool/dataset@name

# Destroy a snapshot (careful!)
zfs destroy pool/dataset@name

# Scrub the pool (monthly maintenance)
zpool scrub pool

# Check available space
zfs get available pool

# Set compression
zfs set compression=lz4 pool/dataset

# Set quota
zfs set quota=100G pool/dataset

# Expand pool with new mirror
zpool add pool mirror /dev/sdX /dev/sdY

FAQ

Can I use ZFS if I already installed Proxmox with ext4?

Yes. You can't convert ext4 to ZFS in place, but you can install the ZFS utilities, create a new pool on additional drives, and add it as storage in Proxmox. Your existing VMs on ext4 will still work - you just won't get ZFS benefits for those until you migrate them.

How much RAM does ZFS actually need?

The 1GB per TB rule is for enterprise setups with many drives and high IOPS requirements. For a homelab with 2-4TB of storage, 16GB of total system RAM is plenty. 8GB works but you'll notice slower I/O under heavy concurrent VM usage.

Should I use ZFS or LVM for Proxmox?

ZFS. Every time, unless you have a specific reason not to (like needing to run Proxmox on a 4GB system). ZFS gives you checksumming, compression, snapshots, and built-in RAID in one package. LVM gives you... logical volumes. The comparison isn't close.

Can I add drives to a ZFS pool later?

Yes, but the method depends on your layout. You can add new mirror vdevs to expand a pool at any time. Expanding a RAIDZ vdev requires replacing all drives with larger ones, which is more involved. This is one reason mirrors are more flexible for growing homelabs.

What happens if a drive fails in my ZFS mirror?

ZFS keeps running in "degraded" mode. Replace the failed drive, and ZFS will resilver (rebuild) automatically. Your VMs keep running during the resilver - there's no downtime. Just don't let it sit degraded for too long; run a scrub after resilver to verify everything is clean.

---

Marcus Chen is a Senior Systems Engineer with 10+ years in enterprise IT. He runs a homelab with over 40 containers and 15 VMs on Proxmox with ZFS. When he's not writing about homelab infrastructure, he's probably arguing about ZFS pool layouts on Reddit.