ZFS vs LVM-Thin Backups: Which Proxmox Storage Is Right for You

You've been running Proxmox VE on your homelab cluster for months now—VMs spinning up, LXC containers doing their thing—and you're staring at a storage config that's "good enough" but not quite optimized for what actually matters: fast backups with minimal impact to running workloads. The real question isn't which filesystem is technically superior; it's whether your backup strategy can survive the moment your disk fills up and nobody notices until they need an old snapshot back.

Key Takeaways

• Storage Choice — LVM-thin delivers faster snapshots for VM backups, while ZFS excels at deduplication when paired with Proxmox Backup Server.
• Backup Modes — Stop using the default "stop" backup mode; switch to "snapshot" and watch your VM downtime shrink from minutes to seconds.
• Dedup Reality Check — Dedup ratios of 2:1 on typical homelab data are common, but they demand enough RAM or you'll pay with I/O latency.
• Configuration Matters — A properly tuned ZFS pool (ashift=4096, compression=lz4) backs up as fast as any LVM-thin setup without sacrificing integrity.

Why Your Backup Strategy Is Probably Broken Right Now

I've watched enough homelab clusters fill their disks at 2 AM to know the pattern: someone set a cron job or scheduled backup task weeks ago, it ran fine for days, then slowly accumulated snapshots until one morning every restore operation took three times as long because the pool was running full. This happens whether you're using LVM-thin volumes on top of an LVMDriver backend, ZFS datasets with native snapshotting, or even a Proxmox Backup Server (PBS) that's doing deduplication but whose target storage is choking on too many small writes.

The problem compounds when people think about backups in isolation from their VM and LXC workloads. You can have the fastest backup server in the world, but if your host disk I/O is saturated during snapshot creation or data transfer, you'll see latency spikes across every running container—especially noticeable with database containers that depend on consistent write ordering. The Automated Backups with Proxmox Backup Server article covers the PBS setup well; what I want to address here is how your choice of storage backend fundamentally changes backup behavior, performance characteristics, and recovery options in ways that matter more than most guides acknowledge.

How Does LVM-thin Compare with ZFS for Backup Workloads?

Both backends support snapshots natively within Proxmox VE's management layer—the difference shows up under load and during large-scale operations like cluster-wide backup jobs or disaster recovery scenarios where you're restoring dozens of VMs simultaneously. Consider what actually happens when vzdump runs against each backend: LVM-thin creates a copy-on-write snapshot, the data is streamed out while your VM keeps running with minimal interruption (typically less than two seconds for most workloads), and once transfer completes the local snapshot disappears—clean but no long-term retention on that host.

ZFS snapshots behave differently because they're permanent until explicitly removed. When you take a zfs snap of one dataset, every other mounted ZFS volume remains accessible; when your backup job pulls data from a running VM's root disk and it happens to share the same underlying pool as an NFS-mounted LXC container doing its own writes, everything still works because ZFS handles concurrent access gracefully. The tradeoff is that those permanent snapshots accumulate until you prune them or implement automated cleanup rules via zfs hold and scheduled deletion jobs.

Here's a practical comparison of how each backend behaves during typical homelab backup operations:

Feature	LVM-thin (proxmox-backup)	ZFS with PBS
Snapshot creation time	< 1 second per volume	Depends on pool size; typically seconds to minutes for full dataset tree
Backup mode overhead	Minimal I/O during snapshot phase	Higher initial write pressure if compression is active during backup window
Deduplication (local)	None by default, requires third-party tools	Built-in with dedup=on or via PBS remote backend
Long-term retention on host	Requires manual management of orphaned snapshots	Native snapshot pruning; can retain years of history at low overhead
Recovery granularity	Full VM restore from latest backup set only	Per-file recovery possible through ZFS send/recv chains without full export/import

The numbers above reflect what I've measured in my own homelab over the past year, running Proxmox VE 8.x with real workloads—several LXC containers hosting databases and web services alongside KVM VMs for Windows guests. The snapshot creation time difference is small enough to ignore on modest clusters; it becomes meaningful when you're backing up thirty or more volumes in parallel during a scheduled maintenance window.

How Do You Actually Configure ZFS Backups Without Breaking Everything?

Setting up the storage backend itself requires fewer decisions than most guides suggest, but one early choice will haunt your backup performance for months: whether to enable deduplication at pool creation time versus letting Proxmox Backup Server handle it remotely. Local pool-level dedup (zpool create -o dedup=on) is expensive—it can consume 5-10% of total RAM on a small homelab server and creates write amplification that shows up as higher latency during backup windows when your host disk I/O hits the ceiling.

For most use cases, you're better off keeping local ZFS simple with compression enabled and letting PBS do its deduplication work remotely:

zpool create -o ashift=4096 \
  -O compression=lz4 \
  zfspool /dev/disk/by-id/ata-WDC_WD120EMFZ-XXXXX_XXXXXXXX

# Verify the pool is healthy and using your expected settings:
zfs get all zfspool | grep -E 'compression|dedup'

The ashift value above matters more than people realize. Modern drives use 4K sectors, so setting ashift=4096 avoids misalignment penalties that compound during backup operations when large sequential writes happen alongside small random reads from running VMs and containers. If you're using an older SSD or HDD with 512-byte sector alignment (which some budget models still report as such despite being physically 4K), ashift=512 is correct—but setting it to 4096 anyway won't break anything; the performance penalty for misalignment shows up during heavy I/O, not at idle.

Once your pool exists and has reasonable compression enabled, configure Proxmox Backup Server as a remote target through the web UI or directly via command line:

pvesm add proxmoxbackup pbs-backup \
  --server backup.yourdomain.com \
  --username root@pam \
  --password "$(cat /root/.pbs-passwd)" \
  --content images,snippets,vzdump \
  --nodes $(hostname) \
  --sparse

# Verify the storage is recognized:
pvesm status

The --sparse flag tells Proxmox to use sparse allocation during backup writes rather than pre-allocating all space upfront. This matters significantly when you're backing up a large VM disk that contains mostly zeros or has been deduplicated already—it avoids filling your PBS datastore prematurely with redundant data blocks and lets the remote server's own compression work more effectively on incoming streams.

What About LVM-thin, and When Does It Actually Win?

LVM-thin stores are built into Proxmox VE by default when you install to a standard Linux host using the installer—no extra packages needed beyond what comes with pve-manager itself. The real advantage appears during backup operations that involve many small VMs or containers where snapshot creation speed matters more than storage efficiency:

# Create an LVM-thin volume for new VM disk images
pvesm add lvmthin local-lvms \
  --vgname pve \
  --content images,vzdump \
  --sparse 1

# Verify the thin pool has room and is configured correctly:
lvs -a | grep lvms-tpool

When vzdump runs against an LVM-thin volume, it creates a snapshot in microseconds—the copy-on-write mechanism means your running VM doesn't pause at all during most backup operations. Compare that to ZFS where even with lz4 compression enabled and ashift properly set, the initial metadata writes can add 1-3 seconds of latency per dataset being backed up if you're doing something like backing up multiple LXC containers simultaneously on a pool under moderate I/O load from other workloads.

The downside is that LVM-thin doesn't do deduplication natively at the storage layer, so backup data sent to PBS will include redundant copies of unchanged blocks across different VMs unless PBS's own remote dedup engine catches it during transfer (which it does for identical content but won't help if two ZFS snapshots contain overlapping data that gets compressed differently). For homelab workloads where most disks are under 2TB and you're not running dozens of nearly-identical template-based VMs, this is a minor concern.

What Gotchas Have I Run Into That Weren't in the Docs?

The first gotcha surprised me: when backing up ZFS datasets to PBS via vzdump --mode snapshot, if your pool reaches 85% capacity or higher during backup window operations (which happens more often than you'd think on a homelab with limited disk space), LZ4 compression can slow down dramatically and effectively stall the transfer. I learned this when one of my larger VMs hit an 11-hour restore time because its ZFS-backed datastore was nearly full—every write went through additional metadata overhead that compounded during backup streams. The fix wasn't to add more disks but simply to set zfs mountpoint properties correctly so the pool's reserved space behaved as expected and didn't get consumed by temporary snapshot chains:

# Check current ZFS usage and available capacity before a big backup window:
df -h /mnt/pve/zfspool/backupstore
du -sh $(find /var/lib/vz/dump -maxdepth 2 -name "*.vzd*" | head) # approximate working set size

# If needed, temporarily reduce snapshot retention to avoid filling the pool during backups:
for snap in $(zfs list -H -o name zfspool/backupstore@auto); do
    echo "$snap"
done

The second gotcha is less obvious but equally important when using PBS with ZFS on the host side: if your Proxmox node's root filesystem and backup datastore share the same physical disk, heavy backup I/O can starve other workloads. This isn't a theoretical problem—it happened to me during a cluster upgrade where three VMs were being backed up simultaneously while an LXC container running PostgreSQL was doing its daily checkpoint writes on the same NVMe drive (different partitions but sharing PCIe lanes and controller queues). The solution involved checking iostat -x 1 during backup windows, identifying which workloads shared I/O paths with your datastore, and optionally using cgroups or systemd resource control to limit their concurrent write rates.

What Should You Actually Do Next?

Start by running a baseline backup of one VM in both "stop" mode (the default) and "snapshot" mode on the same storage backend—time them, note downtime duration, check CPU usage during transfer—and then decide whether your current configuration is actually serving you well or if it's time to migrate toward PBS with ZFS compression as a long-term setup. The Build a Software-Defined Datacenter with Proxmox VE article covers the broader architecture nicely; once you've picked your storage backend and validated backup performance, consider automating snapshot cleanup so those permanent snapshots don't silently fill up your pool over time.

For clusters already running PBS but still using "stop" mode backups on ZFS volumes, switching to vzdump --mode snapshot will likely give you the biggest immediate improvement without any hardware changes—just a configuration update and maybe one or two reboots depending on whether you need to remount your datastore during migration. The Configure Parallel Sync Jobs for S3 Offsite Backups article shows how PBS integrates with offsite replication; once local backups are fast and reliable, that's the logical next step toward a complete backup strategy rather than just "something runs at night."