Proxmox Deep Dive Part 10: Backup and Disaster Recovery

Part 9 covered Ceph. This part covers what happens after everything from Parts 1 through 9 is built and running: making sure it can actually be recovered when something goes wrong.

vzdump and its three modes.

vzdump is Proxmox’s built-in backup tool, and it supports three modes with genuinely different tradeoffs. Stop mode shuts the guest down, backs it up, and restarts it, the simplest and most consistent option, at the cost of real downtime for the duration of the backup. Suspend mode pauses the guest during backup rather than stopping it, shorter interruption than stop mode but still a pause. Snapshot mode, available on storage that supports it (ZFS and LVM-thin both do), takes a storage-level snapshot and backs up from that snapshot while the guest keeps running with no interruption at all, the practical default for anything that needs to stay up.

Retention scheduling that matches how backups actually get used.

Proxmox’s retention options (keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly) let a single backup job express a genuinely useful policy: keep every backup from the last few days for granular short-term recovery, then thin out to one per week for the past month, one per month for the past year, without needing separate jobs or manual pruning logic. The mistake worth avoiding is setting retention once and never revisiting it, a homelab’s actual recovery needs (how far back would a restore realistically be useful) are worth an honest second look rather than leaving whatever the first configuration happened to be.

Proxmox Backup Server: the recommended companion, not just a nicer vzdump target.

Proxmox Backup Server (PBS) is a separate product, its own install, that vzdump can target instead of a plain directory or NFS share, and it changes the backup model in a way that’s worth understanding rather than treating as a drop-in destination swap. PBS backups are chunk-based: data gets split into content-defined chunks, and deduplication works by only storing chunks that don’t already exist in the datastore, reused across every backup of every guest that shares the same underlying data. In practice this means block-level deduplication cuts storage consumption 5 to 10 times over on typical VM workloads, and after the first full backup, every subsequent backup is effectively incremental forever, only genuinely new or changed chunks get transferred and stored, without ever needing a separate “full” backup job to anchor the chain the way older incremental-backup models require.

Pruning and garbage collection are two different operations, not one.

This distinction trips people up specifically because it’s not intuitive from the vzdump-only world: pruning removes backup snapshots according to the retention rule, deciding which backup records to keep, while garbage collection is a separate job that reclaims the actual disk space from chunks no longer referenced by any remaining snapshot after pruning. Running prune without ever running garbage collection leaves the datastore not actually shrinking even though old backups have been “removed,” the chunks are still on disk until GC gets around to reclaiming them. A homelab PBS install needs both jobs scheduled, not just retention configured.

Checking the deduplication ratio is a genuine health signal, not just a curiosity.

PBS’s datastore summary shows the current deduplication ratio, typically somewhere between 2:1 and 10:1 depending on how similar the backed-up guests actually are to each other. A ratio that’s dropped sharply from its usual range is worth investigating, it can indicate a guest’s data has changed unusually heavily (expected after something like a major OS upgrade) or, less benignly, something unexpected writing far more data than normal.

Restore testing, and the 3-2-1-1-0 shape worth aiming for.

A backup that has never been restored is a hope, not a plan. Testing an actual restore periodically, not just checking that backup jobs complete without error, is the only way to know the backups are genuinely usable when they’re needed. The commonly cited 3-2-1-1-0 rule (three copies of data, on two different media types, one copy offsite, one copy offline or immutable, zero errors on the last verification) is a reasonable shape to aim toward even at homelab scale, PBS’s own verify jobs cover the “zero errors” part directly, and a second PBS instance or an offsite sync covers the “one copy offsite” part without needing a second full backup pipeline to maintain.

Part 11 moves to a completely different subsystem: PCI and GPU passthrough, handing real hardware through to a VM directly.