Proxmox Backup: The Complete 2026 Guide (PVE + PBS)

Proxmox adoption has exploded since VMware was acquired by Broadcom. Teams migrating in find a mature open source hypervisor, but they also inherit a topic many put off: the backup strategy. This guide sets the complete baseline for 2026, from vzdump through Proxmox Backup Server (PBS), via the 3-2-1-1-0 rule and restore testing. It is aimed at administrators already running Proxmox VE in production, at MSPs managing customer fleets, and at IT directors weighing VMware-inherited commercial backup tools against the native Proxmox ecosystem.

The guide covers theory, but most of all the concrete decisions: which tool for which need, how to size, how to test, and how to automate. Every figure and practice reflects PVE 8.x and PBS 3.x, the reference versions in 2026.

Why back up a Proxmox hypervisor

A hypervisor concentrates production. Losing a Proxmox node without backup means potentially losing dozens of VMs and containers at once. The causes are always the same: hardware failure (disks, RAID controller, power supply), human error (accidentally deleting a VM, a misplaced qm destroy), software corruption (filesystem, broken ZFS pool), and in recent years, ransomware. On that last point, professional APT groups encrypt virtualisation hosts as a priority because they know that is where value concentrates.

The quantifiable cost of a loss is well understood. RTO (Recovery Time Objective): how long your business can operate without its VMs. RPO (Recovery Point Objective): how much recent data you can tolerate losing. On a typical Proxmox fleet, target values sit around RTO 4 to 24 hours depending on criticality, and RPO 6 to 24 hours for standard production, 15 minutes to 1 hour for critical databases. These values drive your backup frequency and restore topology.

The regulatory framework also pushes teams to formalise the strategy. NIS2 has required essential and important operators since 2024 to demonstrate recovery capability. DORA does the same for the financial sector. GDPR has required appropriate technical measures for data protection since 2018, and several sector-specific guidelines (HDS for healthcare, PCI DSS for payments) explicitly call for immutable backups. The “we have RAID so we are protected” argument no longer holds in an audit.

The realistic entry threshold in 2026 is what we call the 5-2-1 minimum: five days of retention, two physically distinct copies, one offsite. That is the floor. A serious strategy quickly moves up to the 3-2-1-1-0 discussed below.

vzdump vs Proxmox Backup Server

Proxmox offers two native backup tools. Understanding their differences is the first strategic decision.

vzdump is the historical tool, built into Proxmox VE since the early days. It produces full archives (vma.zst, vma.gz or tar format) for each VM or container, written to a local or remote storage (NFS, CIFS, directory). Each run = one full archive file. No deduplication across runs, no fine compression, no native incremental. With PVE 8, vzdump does handle a snapshot mode that freezes an LVM or ZFS snapshot during the dump, limiting the impact on live VMs.

Proxmox Backup Server (PBS) is a separate application installed on a dedicated server or VM. Its architecture is fundamentally different: each VM file is split into 1 to 4 MiB chunks by a content-defined chunking algorithm. Chunks are indexed by their SHA-256 hash and stored exactly once, wherever they appear. The protocol between PVE and PBS is a binary HTTP/2 transport that only carries the chunks absent from the target datastore. From the second backup onwards, only the chunks actually modified cross the network, typically 2 to 5 % of an active VM per day.

Concretely this changes three things:

• Storage volume: on a mixed 20-VM Windows/Linux fleet, PBS reaches logical-to-physical ratios of 6 to 12 after a few weeks. 10 TB of logical backups can fit on 1 to 2 TB of physical storage.
• Daily backup time: a 500 GB VM that takes 40 minutes in vzdump takes 2 to 4 minutes in incremental PBS with CBT (Change Block Tracking) enabled.
• Granular restore: PBS mounts a datastore as a FUSE filesystem so you can pull a single file without restoring the entire VM. vzdump forces a full restore.

The sensible choice in 2026: PBS for production, vzdump only for marginal cases (one-off export, migration to another hypervisor, a one-shot backup before a risky operation). If your fleet has more than 5 VMs, PBS pays back its operational cost in a few weeks.

Installing and configuring PBS

Three deployment options: dedicated physical host, VM on a Proxmox cluster, or managed service like Cloud-PBS. We cover the self-hosted physical case here, which remains the base for understanding what runs under a managed service.

Realistic hardware prerequisites: 8 modern x86_64 cores, 16 to 32 GB of ECC RAM, and a disk pool that follows the “3x planned logical volume” rule. The recommended filesystem is ZFS with a RAIDZ2 topology for large pools (above 24 TB usable) or mirrors for smaller pools where performance dominates. An NVMe special vdev in mirror drastically accelerates metadata operations (garbage collection, verify); plan for about 0.3 % of the pool size in NVMe mirror.

Installation uses the official ISO available from proxmox.com. The installed system is a minimal Debian with the PBS packages pre-configured. The web interface listens on port 8007 over TLS. The first access prompts to create a datastore: this is the ZFS or ext4 directory that will hold your chunks. For production you always configure a ZFS pool separate from the system, with LZ4 or zstd-3 compression.

Once PBS is in place, three steps on the Proxmox VE side:

1. Add the remote datastore under Datacenter > Storage > Add > Proxmox Backup Server. Fill in the PBS address, the datastore name, and the user (backup@pbs or a dedicated API user).
2. Copy the TLS fingerprint from the PBS dashboard (Dashboard tab, Fingerprint field) and paste it into the PVE storage configuration. Without a valid fingerprint, the connection fails.
3. Enable client-side encryption if your data requires it. PBS generates an AES-256-GCM key that you download and store separately. Data is encrypted on the PVE host before transfer; PBS never sees the key. Losing that key makes your backups unrecoverable, so plan for a HSM or secret manager to store it outside your Proxmox infrastructure.

At this stage PBS is ready to receive its first jobs. A default daily schedule works to get started. Fine-grained optimisation (backup windows, VM groups, bandwidth throttling) can be refined over time.

Scheduling backup jobs

A PBS job has five parameters that shape your entire strategy: what to back up, when, with which retention, in which window, and with what network priority.

What: VMs and containers, individually or by group (Proxmox pool, tag, pattern). For a homogeneous fleet, tags are the most flexible tool: you label VMs backup-daily, backup-weekly, critical, and declare jobs that target those tags. Changing one VM’s strategy = changing its tag.

When: PBS schedules follow systemd syntax (daily, weekly, mon..fri 22:00, *-*-* 03:00). Frequency depends on the RPO target. For standard production, a daily backup at 22:00 or 2 AM works well. For databases, 6 to 8 runs per day is not excessive; PBS ingests them without a load spike thanks to the incremental protocol.

Retention: five rules that combine. keep-last N (always keep the N most recent), keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. A classic production profile: keep-daily 14, keep-weekly 4, keep-monthly 12, keep-yearly 3. That stores 33 unique snapshots per VM, about 4 to 6 times the logical volume of an active VM, for an effective 3-year retention. Our retention simulator computes this combinatorial visually.

Window: PBS can limit per-job bandwidth (bwlimit) and respects maintenance windows. On a site with a shared internet link, throttle out-of-hours backups to 50 % of the uplink. On a site with a dedicated PVE-to-PBS link, no throttling needed. Since PVE snapshots are taken instantly, the job duration does not block the VMs; only the I/O load matters.

Priority: a verify job should run weekly on every datastore. A garbage collection job daily or weekly depending on your write rate. A prune job aligned with each backup job. These three maintenance tasks are as critical as the backups themselves; an unverified PBS is worth no more than the hope that the hash still matches the data.

To precisely size storage against your volume and retention, the PBS storage calculator processes inputs in real time.

The 3-2-1-1-0 rule applied to Proxmox

The historical 3-2-1 rule said: three copies of your data, on two different media, one of which offsite. That was enough before modern ransomware; it is no longer. The 3-2-1-1-0 version adds two essential requirements:

• Three copies: production + two independent backups.
• Two media: not all copies on the same storage type.
• One offsite: at least one copy geographically separated.
• One immutable: at least one copy that nobody, even an attacker with admin rights, can alter.
• Zero errors: every backup must be verified, not just written.

Concrete implementation on Proxmox fits in three layers.

Layer 1, PBS on-premise or in a local datacenter. This is the primary target of daily backup jobs. Fast restore over the 10 Gbps LAN link. A PBS host physically separated from PVE hosts, on a different administration VLAN, with credentials that are NOT the PVE admin credentials.

Layer 2, PBS sync to a second remote PBS. Native to PBS, push/pull synchronisation replicates chunks to a second datastore. That second PBS is ideally with a different operator: another datacenter, another network carrier, another jurisdiction. The Cloud-PBS service is designed for exactly that role, with sites in France, Germany and the United States.

Layer 3, immutability. Two native options in 2026. First, protected snapshots in PBS 3.x let you mark a backup as undeletable until a given date. A pveum admin can lift the protection, but not a standard API user. Second, for true physical immutability, an offline copy on LTO tape or on an explicitly offline datastore only brought online during synchronisation windows. LTO tape finds its historical role again here: ransomware cannot overwrite media that is not mounted.

The “zero errors” dimension is too often neglected. A weekly verify job that re-reads every chunk and compares its hash to the manifest catches silent corruption before it blocks a restore. An actual restore-measure-restore drill every quarter on a random VM anchors confidence in the system.

To dig into managed positioning on this strategy, the Cloud-PBS vs self-hosted comparison details the concrete trade-offs at each layer.

Restore: methods and testing

An untested backup is not a backup. That sentence is too recent in marketing discourse to be a harmless cliché yet: almost every team we audit has never run a formal restore test.

PBS supports four restore methods, from the most granular to the most massive.

File-level restore. You mount a backup as a FUSE filesystem from the PVE interface, navigate the tree, copy what you want. Ideal for pulling a specific file without rebooting the VM. Under the hood, PBS only serves the chunks requested, not the whole archive.

Individual disk. You restore one virtual disk of a multi-disk VM. Useful when only the data disk is corrupted and the OS is healthy.

Full VM. Classic restore of an entire VM to a target PVE storage. Duration scales with size: plan for 5 to 15 minutes per 100 GB on a 10 Gbps PBS-to-PVE link, more on 1 Gbps.

Live restore. PBS 2.4+ lets you start a VM while its restore is still running. Reads point to PBS as long as blocks are not yet locally present; writes go to the target storage. Effective RTO reduced to a few minutes for a 500 GB VM, at the cost of a temporary I/O performance degradation.

Tests should follow a systematic plan. We recommend a quarterly cadence with three scenarios:

1. File-level: restore a specific file, measure time from request to file availability. Target: under 2 minutes for a file smaller than 100 MB.
2. Standard VM: restore a random production VM to a test node, verify boot, test a business service. Target: RTO matches the declared RTO.
3. Disaster scenario: simulate the loss of a complete PVE node, restore 5 critical VMs from PBS to a new node. Target: global RTO under 4 hours.

Scenario 3 is the one that uncovers gaps: missing credentials, absent documentation, forgotten network dependencies. It runs from a runbook, not from improvisation. For teams who cannot spare the time to formalise it themselves, the Cloud-PBS Managed Restore service provides both the runbook and on-call assistance.

Automating with the REST API

Both PBS and PVE expose a documented REST API. In 2026, automating backup operations is no longer an exotic option; it is the professional norm.

Authentication. Create a dedicated user (automation@pbs) with an API token. The token appears only once at generation; store it in your secret manager. Granular permissions let you authorise only backup creation and status reads, not deletion. Revoke obsolete tokens at every team rotation.

Key endpoints. GET /api2/json/admin/datastore/{store}/status for volumes, GET /api2/json/admin/datastore/{store}/groups to list backup groups, POST /api2/json/admin/datastore/{store}/prune to trigger a manual prune. On the PVE side, POST /api2/json/nodes/{node}/vzdump starts an on-demand backup.

Orchestration tools. Ansible with the community.general collection includes a proxmox_kvm module but no native PBS module yet in 2026; calls go through ansible.builtin.uri for PBS. Terraform with the bpg/proxmox provider handles the PVE side, not the PBS side directly. For advanced workflows, a Python wrapper around the proxmoxer client remains the most flexible path.

Monitoring. PBS metrics are exposed as native Prometheus on /api2/json/admin/metrics. A standard Grafana dashboard tracks per-datastore volume, dedup ratio, job failure rate, and the duration of the last verify. A simple alert: if no backup has succeeded for a given group in the last 36 hours, page the on-call.

For a Grafana dashboard template and automation scripts, the docs/advanced section of the site lists several maintained versions.

FAQ

Is PBS deduplication as efficient as Veeam? On a homogeneous Proxmox workload, yes and often more. Veeam excels on VMware and Hyper-V where it uses vendor-specific CBT. PBS uses PVE’s native CBT through QEMU combined with content-defined chunking, with typical ratios of 6 to 12 on mixed fleets. The 25:1 or higher figures Veeam advertises refer to very specific datasets (desktop VMs, identical templates). On standard production workloads, both solutions produce ratios of the same order of magnitude.

Can I back up LUKS-encrypted VMs on PBS? Yes. PBS works at the block level; it does not read the encrypted content of your VMs. LUKS encryption inside the VM and PBS client-side encryption are complementary and independent. Both combined give you encrypted-at-rest in production AND in the backup.

One PBS per site, or one central PBS? Depends on the topology. Below 3 sites and 100 VMs, a central PBS works if the inter-site network supports the incremental backups. Above that, you deploy one PBS per site (local LAN collection) + one central PBS that syncs via PBS remote replication. The bandwidth required is typically 2 to 5 % of the daily volume once the initial seed is through.

How do I move from vzdump to PBS without losing history? Keep your existing vzdump storage read-only for 3 to 6 months after the PBS switchover, the time to validate restores from the new system. The vzdump history is not convertible to PBS format, but it remains restorable via the PVE interface as long as the source storage is mounted. After the validation period, archive the oldest .vma.zst and delete the rest.

Can PBS back up things other than Proxmox? PBS also exposes a proxmox-backup-client client that can back up arbitrary Linux hosts (files, entire directories). The mechanics are similar: chunking, deduplication, client-side encryption. It does not replace a real file-level backup tool like restic or BorgBackup for very specific uses, but it is enough to consolidate VM backups and physical server backups in a single datastore.

Is upgrading PBS disruptive? No. PBS follows the Debian release model; patch updates are non-disruptive (services reload without interrupting in-flight jobs). Major upgrades (2.x to 3.x, 3.x to 4.x) require a 15 to 30-minute maintenance window, usually performed outside backup hours. The Cloud-PBS service takes care of those upgrades on the managed side.

Taking action

If you are starting a Proxmox backup strategy, the logical order is: install PBS (or subscribe to a managed instance), configure a first backup job, verify that restores work, then refine retention and add the offsite layer.

Cloud-PBS is designed for that second part: you receive a managed PBS instance in France, Germany or the United States, point it as a remote datastore in your Proxmox VE, and your sync jobs push your backups offsite. The official Proxmox Authorized Reseller partnership guarantees alignment with upstream, and support is delivered by engineers who have been running production PBS instances for 12 years.

The 7-day free trial lets you test on your own workload before any commitment. To quantify the cost on your fleet, the TCO vs self-hosted calculator compares the two approaches over three years.