Proxmox VE has established itself as the virtualization alternative of choice for thousands of European companies, and with that growth comes an inevitable question: how do you properly protect a Proxmox environment? The native answer is called Proxmox Backup Server (PBS), an enterprise backup solution built by the same team that develops the hypervisor and designed from day one for virtual machines, LXC containers and physical hosts.
Unlike the classic vzdump built into Proxmox VE, which produces full copies on every run, PBS applies the principles of modern backup platforms: block-level deduplication, incremental forever backups, zstd compression, client-side encryption and scheduled integrity verification. The result: retaining weeks or months of history stops being a storage problem, and backup windows shrink to minutes.
In this guide we cover the PBS architecture, its retention policies and sync jobs, its Proxmox VE integration, the best practices for a solid 3-2-1 strategy and a brief comparison with Veeam.
What Is Proxmox Backup Server
Proxmox Backup Server is a product independent from Proxmox VE: it installs on Debian on its own hardware (or as a dedicated appliance) and exposes its own web interface, a REST API and a command-line client (proxmox-backup-client). Its core is written in Rust, which brings performance and memory safety to the critical data paths.
While its flagship integration is with Proxmox VE, it is not limited to it: the backup client can also protect physical Linux hosts at file level. The software is open source (AGPLv3 licensed) and the paid subscription grants access to the enterprise repository and official support without cutting any functionality.
Architecture: Datastores, Chunks and Deduplication
The storage unit of PBS is the datastore: a directory on a local filesystem (usually ZFS, ext4 or XFS) where backups are kept. Inside each datastore, data is not stored as monolithic image files but as chunks: blocks of roughly 4 MiB identified by their SHA-256 hash.
That content addressing is the foundation of block-level deduplication: if two VMs share the same operating system, their identical chunks are stored only once and every backup references them. In homogeneous environments, deduplication ratios of 10:1 to 30:1 are common. Each chunk is additionally compressed with zstd, an algorithm that delivers excellent ratios at a very low CPU cost, ideal for keeping the backup window short.
The third piece is client-side encryption: chunks can be encrypted with AES-256-GCM before they leave the source host, with a key that only the client holds. The PBS server stores data it cannot read, which makes it safe to use a remote or third-party-hosted PBS: not even the operator of the backup server can access the content. Safeguarding that key (plus a printed copy of the paper key) becomes part of your recovery plan.
PBS also ships namespaces: logical subdivisions within a single datastore to separate customers, clusters or environments without losing datastore-wide deduplication. They are the key building block for multi-tenant scenarios and service providers.
Incremental Forever and Verify Jobs
PBS implements the incremental forever model: after the first full backup, every subsequent copy transfers only the blocks that changed. For running VMs, Proxmox VE uses QEMU's dirty bitmap to know exactly which blocks were modified since the last backup, without re-reading the whole disk. The practical outcome: daily (or even hourly) backups that take minutes and consume minimal bandwidth.
Because each snapshot references shared chunks, there are no fragile incremental "chains" like in traditional schemes: every backup is self-contained for restore purposes, and deleting an old one never invalidates newer ones. The trade-off is that chunk health becomes critical — and that is where verify jobs come in: scheduled tasks that re-read the chunks, recompute their SHA-256 hashes and compare them against the indexes to detect silent corruption (bit rot). A verified snapshot is marked green in the interface; a corrupt one is flagged as failed, and the next backup re-uploads the damaged chunks.
Rule of thumb:
An unverified backup is a hypothesis, not a guarantee. Schedule weekly verify jobs (or after every backup on small datastores) and combine them with periodic re-verification of older snapshots. A restore that fails is always discovered on the worst possible day.
Prune, Garbage Collection and Retention Policies
Retention in PBS is handled in two phases. First, the prune job decides which snapshots to keep according to keep-* rules and removes the references to the rest. Then, garbage collection (GC) walks the datastore and physically frees the chunks no longer referenced by any snapshot, honouring a grace period of 24 hours and 5 minutes so it never interferes with running backups.
The retention rules combine with each other, grandfather-father-son style, and let you express complex policies with just a few parameters:
| Parameter | What it keeps | Example value |
|---|---|---|
| keep-last | The N most recent snapshots, regardless of date | 3 |
| keep-hourly | The last snapshot of each of the N most recent hours | 12 |
| keep-daily | The last snapshot of each of the N most recent days | 7 |
| keep-weekly | The last snapshot of each of the N most recent weeks | 4 |
| keep-monthly | The last snapshot of each of the N most recent months | 6 |
| keep-yearly | The last snapshot of each of the N most recent years | 2 |
A "3 last + 7 daily + 4 weekly + 6 monthly" policy covers most SME needs and, thanks to deduplication, uses a fraction of what full copies would cost. Remember that prune only marks: until GC runs (schedule it daily or weekly), the space is not actually freed.
Sync Jobs: Replicating to a Remote PBS and the 3-2-1 Rule
A backup that lives in the same building as the infrastructure it protects will not survive a fire, a flood or ransomware that reaches the local network. PBS solves the offsite copy with sync jobs: tasks that replicate snapshots between the datastores of two PBS servers, in pull mode (the remote pulls from the source — recommended for security) or push. Only the chunks missing at the destination travel over the wire, so replicating the daily increment of dozens of VMs consumes very reasonable bandwidth.
With a secondary PBS in another location, the classic 3-2-1 rule (three copies, two different media, one off-site) is fulfilled naturally: production + local PBS + remote PBS. As an alternative or complement, datastores can lean on S3 object storage as an additional layer for long-term archiving, and for those who need a physical air gap or multi-year regulatory retention, PBS includes native tape support, with media pools, cataloguing and LTO encryption.
At EasyDataHost we offer PBS repositories hosted in our datacenter in Spain and compatible S3 storage for that second or third copy; with client-side encryption enabled, your data reaches our infrastructure already encrypted with your own key.
Proxmox VE Integration: Live-Restore and File-Level Restore
The Proxmox VE integration is where PBS shines. The datastore is added to the cluster as a "Proxmox Backup Server" storage type, and backup jobs for QEMU VMs and LXC containers are scheduled from the PVE interface itself, with consistent snapshots (via the guest agent) and without shutting workloads down. Recent platform releases — which we cover in our article on what's new in Proxmox VE 9 — have kept polishing this integration.
For restores, PBS offers three game-changing modes. The classic full restore recovers the VM or container to any storage in the cluster. Live-restore boots the VM immediately while its disks are restored in the background: the service is back online in seconds, albeit with reduced performance until the copy completes. And file-level restore lets you browse the contents of a backup from the web interface and download individual files or directories without restoring the whole machine — even from VM disk images.
All of this works the same on your own infrastructure as on hosted platforms: our Proxmox-based private cloud is delivered ready to connect to a PBS datastore, so the backup strategy is born with the platform rather than bolted on afterwards.
Deployment Best Practices
PBS is easy to install, but a serious deployment requires a few architectural decisions:
- check_circle Separate hardware: run PBS on its own server, never as a VM inside the cluster it protects. If the cluster goes down, the backup must remain standing.
- check_circle Never use the same cluster as the only destination: a datastore on the protected cluster's own Ceph or ZFS turns any major failure into simultaneous loss of data and backups.
- check_circle Complete the 3-2-1 with an offsite copy: a sync job to a remote PBS (or S3 storage for archiving) in another physical location. The local copy speeds up restores; the remote one saves you from disaster.
- check_circle Encrypt client-side and safeguard the key: enable encryption for any copy that leaves your infrastructure, and store the key (and the paper key) outside the protected environment itself.
- check_circle Test your restores: schedule periodic drills of full restores and file-level restores. The verify job validates the data; the drill validates the procedure.
PBS or Veeam: Which One to Choose
It is the inevitable comparison, and the honest answer depends on the perimeter to protect. If your environment is 100% Proxmox, PBS is hard to beat: native integration, dirty-bitmap incrementals, live-restore, contained cost and the whole chain (hypervisor + backup) supported by the same vendor.
If your infrastructure is mixed — VMware or Hyper-V alongside Proxmox, physical Windows and Linux servers — Veeam remains the most complete platform: a single console, a single licensing model and advanced DR features that PBS does not cover. Veeam also supports Proxmox VE as a hypervisor nowadays, a valid option during migrations too.
At EasyDataHost we do not make the choice for you: we offer both paths — hosted PBS repositories for Proxmox environments and offsite backup with Veeam Cloud Connect for mixed environments — always on our own infrastructure in Spain with ISO 27001 certification and ENS compliance.
Frequently Asked Questions
Can I install PBS on the same node as Proxmox VE?
Technically yes, but it is not recommended in production: if the node fails, you lose the VMs and their backups at the same time. Best practice is separate hardware plus a sync job to a remote PBS to fulfil the 3-2-1 rule.
How much space does deduplication save?
It depends on how homogeneous the workloads are, but with many VMs running the same operating system, ratios of 10:1 to 30:1 or higher are common. Since each backup only stores new chunks, months of retention cost a fraction of the original data.
Does PBS replace Veeam?
In 100% Proxmox environments, PBS is the most efficient native option. In mixed environments with VMware, Hyper-V or physical servers, Veeam remains the most complete platform. EasyDataHost offers both paths, so you can combine the best of each.
Conclusion
Proxmox Backup Server has turned backing up Proxmox environments into a solved problem: modern technology, simple operation and contained cost. The keys to getting the most out of it:
- arrow_right Efficient architecture: deduplicated chunks, zstd compression and client-side encryption reduce storage and protect confidentiality, even on third-party repositories.
- arrow_right Incremental forever + verify jobs: backup windows of minutes and scheduled integrity verification against silent corruption.
- arrow_right Retention with prune + GC: expressive keep-daily/weekly/monthly policies and controlled space reclamation.
- arrow_right 3-2-1 with sync jobs: PBS on separate hardware plus offsite replication to a remote PBS or S3 storage. Never the same cluster as the only destination.
- arrow_right PBS for pure Proxmox, Veeam for mixed environments: two excellent tools with different perimeters. Choosing well avoids overpaying or falling short.
If you want to build a backup strategy for your Proxmox environment — an offsite PBS repository, a private cloud with backup included, or a combination with Veeam — contact our team: we will analyse your case and propose the architecture with no obligation.