View the full Proxmox Backups and Proxmox Backup Server →
For Proxmox VE users, PBS turns routine guest backups into a repository with usable recovery history rather than a collection of repeated disk images. It can reduce the storage and transfer cost of frequent backups, but it only improves resilience when the repository is separate from the systems it is expected to recover.
Rather than writing large, mostly identical VM images to a target night after night, PBS retains reusable data chunks and transfers what has changed. For a Proxmox VE environment with regular guest backups, that can shorten backup windows, reduce network traffic and leave more room for recovery history.
It is not a magic resilience box. Proxmox Backup Server (PBS) is a separate backup application and datastore, not a setting that makes local storage into a backup. It still needs reliable disks, sensible access controls and a plan for losing the Proxmox host, the PBS host or the site itself. When deployed appropriately, it is a practical advantage of Proxmox VE.
This opens the planned three-part Proxmox Backups and Proxmox Backup Server series. It explains what PBS does and where it fits. Part 2, How to Build a Reliable Proxmox Backup Strategy, covers schedules, copies, capacity and recovery discipline. Part 3, Proxmox Backup Server vs Traditional VM Backups, compares PBS with conventional approaches.
It sits alongside Proxmox VE, not in place of it
Proxmox VE is the virtualisation platform: it runs KVM (Kernel-based Virtual Machine) virtual machines and LXC (Linux Containers) containers, manages clusters, storage and networking, and schedules guest backups. PBS is the dedicated server that receives and manages those backups in purpose-built datastores. Add a PBS datastore to Proxmox VE as a storage target and administrators can protect VMs and containers through the familiar backup workflow. Native web-interface and API (application programming interface) integration has been present since Proxmox VE 6.3. (pbs.proxmox.com)
The separation matters. A backup held on the same physical Proxmox host can help after an accidental deletion or bad guest update, but it does little for a host failure, controller fault, theft or destructive attack against that machine. PBS gives the repository its own operating system, storage stack, permissions and maintenance jobs. That is a separate failure domain — provided it is actually deployed separately.
For a small business, that may mean a modest dedicated server with appropriately protected storage. For a homelab, an older but dependable machine with enough disk capacity may be enough. Running PBS as a VM on the only Proxmox host and keeping its datastore on that host’s only disk is useful mainly for learning. It is not the architecture most people mean when they say their workloads are protected.
Backup design belongs in any wider Proxmox decision, alongside guest compatibility, storage behaviour and operational ownership. Those are central to the practical checks before a Proxmox VE 9 migration.
Incremental transfers, full restore points
PBS stores a backup as a snapshot: the metadata, indexes and data chunks needed to represent the protected workload at a particular time. A new job does not need to retransmit every unchanged block. The client compares data with the previous backup and can send references for chunks PBS already holds, while each completed backup retains references to everything required for a full restore. (pbs.proxmox.com)
This is more useful than the shorthand of “a full backup every night” implies. An administrator can choose an older recovery point without reconstructing a long incremental chain in the way some traditional systems require. The storage efficiency comes from shared data chunks; at restore time, the selected snapshot represents the whole guest.
That model suits Proxmox VE well. A VM or container may have a large operating-system disk that changes little day to day and a smaller area of application data that changes constantly. PBS still has to examine the source well enough to identify changes, so backup performance is never free. But it avoids repeatedly sending and storing stable data when the relevant chunks already exist.
The word snapshot needs some care. In PBS documentation, it means the resulting backup state in the datastore. During a Proxmox VE backup, the hypervisor can also use snapshot-based handling for running guests. That can reduce disruption, but it is not an application-aware recovery guarantee. A database that needs transaction-log handling, consistency controls or point-in-time recovery still needs those measures. A clean VM backup is valuable; it is not automatically a database strategy.
What deduplication and compression change
Deduplication means keeping one stored copy of identical data chunks and allowing multiple snapshots to refer to it. PBS identifies chunks using SHA-256 digests, cryptographic identifiers calculated from the data, so its datastore indexes can reuse chunks across backup snapshots rather than write duplicate copies. (pbs.proxmox.com)
The immediate benefit is often better retention rather than an eye-catching disk-usage figure. Efficient backups make it more realistic to keep useful daily, weekly and monthly recovery points instead of deleting history whenever a volume fills. Repeated backups of largely stable machines also avoid consuming the network bandwidth of repeated full-image copies.
There are limits. Deduplication ratios depend on the workload. A fleet of similar Linux VMs may share a great deal of unchanged data; already-compressed media, encrypted guest disks and high-churn database files may offer much less. Don’t size a production repository on the assumption that every terabyte of VM storage will collapse into a tiny fraction of a terabyte. Measure representative workloads and leave capacity headroom.
PBS also uses Zstandard, commonly called zstd, to compress backup blobs. Compression can reduce the space and traffic needed for data that remains compressible, but it consumes CPU and cannot meaningfully shrink data that is already compressed or encrypted. Compression and deduplication complement each other; neither is a guarantee. (pbs.proxmox.com)
Encryption only works if key recovery does too
PBS transfers backup data over TLS (Transport Layer Security) and supports client-side encryption using AES-256-GCM, an encryption standard. Client-side is the important part: data can be encrypted before it reaches the backup server, which is useful when the repository or a remote location is not fully trusted. Encryption is not enabled by default. (pbs.proxmox.com)
That capability adds a responsibility to the backup design. If the encryption key and its recovery material are lost, the backup may still exist but be unusable. PBS supports a master key that retains an encrypted copy of a backup encryption key alongside the backup, which can make recovery more manageable. It is still not a substitute for documented, controlled key custody. (pbs.proxmox.com)
For a homelab, encryption may make sense where backups leave the house or sit with a third-party host. For an organisation, it is often appropriate where the backup team, infrastructure team and storage operator do not all need access to application data. Enabling it because it appears on a security checklist, without deciding who can recover keys during an incident, can create a secure archive of unavailable data.
Retention is not just deletion
PBS retention policies can preserve the latest backups plus a rolling set of hourly, daily, weekly, monthly and yearly points. The policy keeps the most recent applicable snapshot within each period, a practical way to retain a longer operational history without keeping every run forever. The software also offers a dry-run option to check what a pruning policy would remove. (pbs.proxmox.com)
The operational wrinkle is that pruning a snapshot removes its references and metadata first. Chunks may still be shared by other snapshots, so PBS later uses garbage collection, a process that identifies unreferenced chunks for removal, to reclaim the associated space. A successful prune job is not proof that a nearly full datastore has instantly gained enough room for the next large backup. (pbs.proxmox.com)
It is a sensible design, but it needs attention. Retention should reflect the rate of change, the likely delay before an incident is noticed and the recovery points the organisation actually needs. “Keep as much as possible” is not a policy if the repository reaches capacity at the worst possible moment.
What PBS is particularly good at: regular protection of Proxmox VE guests where repeated backups, useful recovery history and efficient use of backup storage matter more than the apparent simplicity of copying full VM images to a share.
Where Proxmox Backup Server earns its place
In a small Proxmox environment, PBS centralises a task that otherwise tends to become improvised: local disks, manually copied archives and uncertain retention. It provides a dedicated interface for datastores, backup content, access control, pruning, verification and synchronisation, while Proxmox VE remains responsible for the guests. PBS can also protect physical hosts through its backup client, though its strongest integration remains with Proxmox VE. (pbs.proxmox.com)
For a larger estate, the appeal is not just incremental backups. Routine VM and container recovery stays in the same ecosystem as the virtualisation platform, including single-file restoration and live restore for PBS-held VM backups. Live restore can start a VM while the remaining data is copied in the background, prioritising the chunks the VM accesses. That may reduce outage time, but it does not make repository performance irrelevant. (proxmox.com)
PBS is also an option for a self-hosting household that has outgrown ad-hoc backup scripts. The software is not restricted to enterprise hardware, and its open-source model may appeal to users who want to understand the system they run. The low licence barrier, however, is no excuse for weak standards around disks, monitoring or power protection. Backups are one of the least forgiving places to economise blindly.
Where it is unnecessary — or insufficient on its own
If there is one small VM running disposable services with no data that cannot be recreated, PBS may be more administration than the problem warrants. A straightforward export or a well-managed application-level backup can be enough. Likewise, a business already committed to another backup platform for regulatory, application-aware, multi-hypervisor or endpoint requirements may reasonably keep its established operational model rather than introduce another repository.
PBS is not a complete answer to resilience. It does not remove the need for an off-site copy, a separate recovery plan, protected credentials, monitoring or restoration practice. Nor does it turn weak storage into dependable storage. PBS documentation recommends fast local storage with good random-I/O performance; where hard disks are used, it recommends a metadata cache, and its datastore implementation relies on a suitable Unix filesystem such as ext4, XFS or ZFS. (pbs.proxmox.com)
That hardware point is easy to underestimate. Deduplicated repositories are metadata-heavy and involve random reads and writes, verification and garbage collection. Cheap, slow disks can work for light workloads, but they can make the repository the bottleneck as the environment grows. A larger capacity number is not automatically the better backup target.
Platform choice is still contextual. Organisations with deeply Windows-centric operations may find Microsoft tooling and Hyper-V the more natural fit, while Proxmox often has a cleaner case for Linux-first stacks and licensing-conscious teams. The practical distinction between Hyper-V and Proxmox deployments matters more than any single feature in the backup layer.
The sensible verdict
Proxmox Backup Server can make frequent Proxmox VE backups more efficient without turning each completed backup into an opaque, fragile incremental chain. Deduplication, compression, retention controls and encryption options are useful in day-to-day operation. The integration is a practical advantage rather than merely a product-page feature.
But PBS is a backup repository, not a backup strategy in a box. Give it separate, resilient storage; decide who controls its credentials and encryption keys; and be honest about whether its recovery points are far enough from the systems they protect. The next instalment, How to Build a Reliable Proxmox Backup Strategy, addresses those decisions. Readers weighing PBS against conventional VM backup products should continue to Part 3, Proxmox Backup Server vs Traditional VM Backups.
Spot an error?
If something factual looks wrong, outdated or misleading, flag it here. Corrections are reviewed separately from normal article comments and reader questions.