Proxmox Backup Server (PBS) is often presented as the obvious choice for Proxmox VE clusters. It usually is, but it is not a universal backup solution. This article compares PBS with traditional approaches, file-level backup tools and plain vzdump archives, so you can decide where each one fits.
What we mean by "traditional backup"
In this comparison, traditional backup covers two families of tools:
- Image archives: Proxmox's own
vzdumpwriting complete archives to a directory, NFS or CIFS share, or third-party tools that export whole VM disks. - File-level backup agents: software installed inside each server (VM or physical) that backs up selected files and folders, such as rsync-based scripts, Bacula, Bareos, restic or commercial agents.
Proxmox Backup Server sits between both: it works at the level of whole guests like an image backup, but stores data in deduplicated chunks and can also back up files from Linux hosts with proxmox-backup-client.
How Proxmox Backup Server stores data
PBS splits backup data into chunks and names each chunk by its SHA-256 digest. A backup snapshot is essentially an index listing the chunks it needs. If two VMs share the same operating system files, or if a VM changes only a small part of its disk overnight, most chunks already exist and are not stored again.
For running QEMU virtual machines, Proxmox VE keeps a dirty bitmap of changed blocks. The next backup reads only those blocks, which makes nightly backups of large VMs fast. Containers and file-level backups use a different archive format, but still benefit from chunk deduplication.
Side-by-side comparison
| Aspect | vzdump archives | File-level agents | Proxmox Backup Server |
|---|---|---|---|
| Unit of backup | Whole guest | Files and folders | Whole guest, or host files with the client |
| Transfer per run | Full archive | Usually incremental | Incremental (dirty bitmaps for running VMs) |
| Storage efficiency | Low: each archive is complete | Depends on the tool | High: global chunk deduplication |
| Restore of a full VM | Simple | Requires reinstalling the OS first | Simple, from any snapshot |
| Single-file restore | Extract archive first | Native | File browser for supported file systems |
| Integrity verification | Manual | Depends on the tool | Built-in verify jobs |
| Encryption | External | Depends on the tool | Built-in client-side encryption |
| Offsite replication | Copy archives yourself | Depends on the tool | Built-in sync jobs between PBS instances |
| Application awareness | Guest agent freeze only | Can run pre/post scripts per app | Guest agent freeze only |
| Non-Proxmox workloads | No | Yes | Linux hosts via the client; no native Windows file agent |
Advantages of Proxmox Backup Server
Fast and small nightly backups
With incremental VM backups and deduplication, keeping 30 daily snapshots of a VM often costs only a little more than a few full copies, depending on how much data changes. That makes long retention affordable.
Every snapshot is a full restore point
Unlike classic incremental chains, you never need to restore a full backup and then apply ten increments. Each snapshot references all its chunks, so restoring from yesterday or from last month takes the same steps.
Built-in verification and replication
Verify jobs re-read stored chunks and compare checksums, catching silent corruption on the backup storage. Sync jobs replicate datastores to another PBS, transferring only missing chunks, which is the foundation of a good offsite design.
Tight integration with Proxmox VE
Backup jobs, retention and restores are managed from the same interface you use for virtualization. Live-restore can start a VM while its data is still being restored, reducing downtime for large disks.
Limitations to keep in mind
- Crash consistency: a VM backup is only as consistent as the guest's state. Without the QEMU guest agent, it is equivalent to pulling the power cord. Even with file system freeze, databases may need their own dumps to guarantee transactional consistency.
- Dirty bitmap resets: after a VM restart or host reboot, the next backup reads the entire disk again. It still uploads only new chunks, but takes longer.
- Single product dependency: PBS snapshots are restored with Proxmox tools. That is fine inside a Proxmox environment, but plan accordingly if you might migrate to another platform.
- Chunk stores are not human-readable: you cannot browse a datastore with standard tools; you need PBS or its client to restore.
- Encryption key management: client-side encryption is excellent, but losing the key means losing every encrypted backup.
- Location: a PBS in the same rack as the cluster is not an offsite copy. Deduplication does not change the 3-2-1 rule.
When traditional tools still make sense
File-level backups inside the guest
Agents inside VMs remain useful for application-aware backups: running a database dump before backup, excluding caches, or restoring a single directory to a different server. They are also the natural choice for physical servers and for workloads outside Proxmox. Many teams combine both: PBS for the whole VM and an in-guest dump for the database, as described in our guides for MySQL and PostgreSQL.
Portable vzdump archives
A vzdump archive is a single file. It is easy to copy to an external disk, hand to someone else, or keep for years as an archival copy. For small environments with a few VMs and generous maintenance windows, plain archives on a NAS plus an offsite copy can be enough.
Choosing the right combination
| Situation | Recommended approach |
|---|---|
| Small lab or one node with a few VMs | vzdump to local or NAS storage, plus an offsite copy of the archives |
| Production cluster with many VMs | PBS on dedicated hardware, verify jobs, plus an offsite PBS or S3-backed datastore |
| Critical databases in VMs | PBS for the VM and scheduled database dumps for transactional consistency |
| Mixed physical and virtual servers | PBS for Proxmox guests and a file-level solution for the rest |
| Long-term archiving | Periodic vzdump archives or PBS snapshots copied to immutable storage |
A practical reference design
- Proxmox VE nodes back up every night to a local PBS on separate hardware (fast restores).
- Critical databases also produce a nightly logical dump inside the guest.
- An offsite PBS pulls the local datastore with a sync job, or a PBS datastore uses S3-compatible object storage in another region.
- Verify jobs run weekly on both sides; one restore test per quarter is documented.
- Encryption keys and the recovery runbook are stored outside both sites.
This design follows the logic of the 3-2-1-1-0 rule while keeping daily operations inside Proxmox.
Next steps
- Inventory your guests and mark which ones contain databases that need application-level dumps.
- If you still use only vzdump archives, test PBS on a spare machine and measure deduplication on your data.
- Define where the offsite copy will live and who can delete it.
- Read how to back up Proxmox virtual machines to the cloud for the offsite part.
The Backnix Proxmox backup page shows how Backnix plans to complement PBS with offsite storage, and the current status of that integration.