The Best Backup for Proxmox

Proxmox VE has become one of the most widely deployed open-source hypervisors for homelabs and small-to-midsize business infrastructure, and its backup story is one of the strongest arguments for choosing it over a proprietary alternative. Unlike many hypervisors where decent backup means buying a separate product, Proxmox ships with a capable backup tool out of the box and has a dedicated, free, open-source backup server designed specifically for it. This article looks at what actually works for backing up Proxmox VMs and containers, how the built-in tooling compares to Proxmox Backup Server, and how to structure a 3-2-1 strategy around a Proxmox host.

Want expert help putting this into practice? B-Backup Pro can guide you through it.

vzdump: the built-in baseline

Every Proxmox VE installation includes vzdump, a command-line and GUI-integrated tool that creates full backups of QEMU VMs and LXC containers. vzdump can write to a local directory, an NFS or CIFS share, or directly to a Proxmox Backup Server datastore, and it can be scheduled through the Proxmox GUI's backup job scheduler without any external cron setup. Out of the box, vzdump backing up to a directory or network share produces either a compressed archive (.vma.zst for VMs, .tar.zst for containers) or, when targeting Proxmox Backup Server, a deduplicated chunked format. The key limitation of plain vzdump-to-storage backups is that each run is effectively a full backup of the disk state at that point — there is no block-level incremental tracking unless PBS is in the loop, so backup windows and storage consumption scale with VM disk size rather than with the amount of actual daily change.

Snapshot, suspend, and stop: choosing a backup mode

Related: bbackup Best Practices: Secure and Efficient Backup Strategies.

vzdump offers three consistency modes, and picking the right one matters both for backup reliability and for how much the VM notices the backup is happening. Snapshot mode uses the underlying storage's snapshot capability (available on ZFS, LVM-thin, and Ceph RBD) to freeze a consistent point-in-time view of the disk while the VM keeps running, then streams that frozen state to the backup target. This is the mode most production Proxmox environments use, since it has no meaningful downtime and works well for most workloads, though databases benefit from being combined with an application-level flush or a QEMU guest agent that can freeze the filesystem at the moment the snapshot is taken. Suspend mode pauses the VM's execution for the duration of the backup, which guarantees a perfectly consistent disk image but causes a real, if usually short, service interruption. Stop mode powers the VM off entirely, backs it up, and restarts it — the safest option for absolute consistency, and the most disruptive, reserved for maintenance windows rather than routine nightly jobs. For containers (LXC), similar tradeoffs apply, with snapshot mode relying on the container's underlying storage supporting snapshots.

Proxmox Backup Server: incremental, deduplicated, and worth running

Proxmox Backup Server (PBS) is a separate, free, open-source product that turns Proxmox backups from periodic full copies into an efficient incremental system. Once a VM's disks are backed up to a PBS datastore, subsequent backups use a change-tracking mechanism — QEMU's dirty bitmap for VMs — so only the blocks that changed since the last backup are transferred and stored, dramatically cutting both backup time and storage growth after the initial full run. PBS deduplicates at the chunk level across the entire datastore, so multiple VMs sharing similar OS images consume far less space than their nominal disk sizes would suggest, and it supports client-side encryption so the PVE host encrypts data before it ever reaches the PBS server, which matters if the backup target isn't fully trusted or sits at a remote site. PBS also adds built-in retention policies (keep last N, keep daily/weekly/monthly/yearly), backup verification jobs that periodically re-read stored chunks to catch bit rot before you need a restore, and namespace support for separating backups from multiple PVE clusters on one PBS instance. Running PBS on even modest hardware — it doesn't need to be powerful, just have enough disk and reasonably fast storage — is close to a strict upgrade over vzdump-to-directory for anyone running Proxmox seriously.

Choosing and structuring backup targets

See also: bbackup Tips and Strategies for Efficient Data Management.

Where you point vzdump or PBS matters as much as which tool you use. A local directory on the same host as the VMs it's backing up protects against accidental deletion or a bad update, but not against the disk or the whole machine failing — that's not a backup, it's a snapshot with extra steps. A second Proxmox node, a dedicated PBS instance on separate hardware, or a NAS on the same LAN is a meaningful improvement, since it survives the failure of the primary host. But a copy that never leaves the building doesn't protect against fire, theft, flood, or a site-wide ransomware event that spreads across the LAN before backups are noticed. PBS supports sync jobs that replicate a datastore to a second PBS instance, which is the natural way to get an offsite copy: one PBS at the primary site receiving nightly backups, syncing on a schedule to a second PBS elsewhere or to a cloud-hosted target. For a homelab or small IT shop without a second physical site, replicating PBS datastores to an offsite or cloud-based backup service closes that gap without adding a second hypervisor to manage.

A practical 3-2-1 layout for a Proxmox host

Applied to Proxmox, the 3-2-1 rule looks like this in practice: three copies of your VM and container data in total (the live disks plus two backups), on two different types of media or storage systems (for instance, local ZFS storage plus a separate PBS server), with one of those copies offsite. A workable version for an SMB running a handful of Proxmox nodes is a local PBS instance for fast, frequent restores, combined with scheduled PBS sync jobs or a client-side-encrypted push to an offsite target for disaster recovery. Retention should reflect what you're actually protecting against: daily backups kept for a couple of weeks handle accidental deletion and configuration mistakes, while weekly or monthly backups kept for longer handle the slower-burning risk of ransomware that sat undetected for a while before triggering, since you need a restore point that predates the infection. It's worth testing a full VM restore from your offsite copy on a regular basis — a backup job that reports success but has never been restored from is an untested assumption, not a safety net.

Where a managed offsite target fits in

For teams that want the offsite half of 3-2-1 without standing up and maintaining a second PBS server at a colocation facility, syncing or streaming encrypted backups to a managed provider is a reasonable middle ground. B-Backup Pro, for example, focuses on secure, EU-data-sovereign cloud backup and disaster recovery, which fits naturally as the offsite leg for a Proxmox environment where PBS handles fast local incrementals and the managed service handles durable, geographically separate retention. The specific tool matters less than the discipline: use vzdump or PBS for reliable, application-consistent local backups, and make sure at least one full, restorable copy lives somewhere the local site's failure can't touch.