Proxmox Backup Server stores backups in a fraction of the space they describe. In our lab, four backups of two 3 GiB VM disks cloned from one template described 12 GiB and took 2.344 GiB on disk. It also sent every distinct chunk of the second VM's disk over the network although the server already held 44% of them, kept a deleted backup's space for at least a day, and failed three backups over eight corrupted bytes. None of that is a reason to choose something else. All of it decides how you size the box, the uplink and the alerts.
CloudSpinx builds Proxmox clusters and the backup layer behind them for organizations in Kenya, and this Proxmox Backup Server review comes from a run rather than a feature list: version 4.2.8 on Debian 13, two VM disks cut from one Debian cloud image with 1 GiB of their own data each, backed up, synced to a second datastore, corrupted on purpose and restored. Proxmox VE was not in the loop. We drove the backup client directly, which writes the same 4 MiB-chunk image archive a VM backup writes, and read the source for the places Proxmox VE's own backup library could differ.
Does Proxmox Backup Server deduplicate across VMs?
On disk, yes. On the wire, no.
The second VM's first backup had to upload 1.824 GiB of its 3 GiB disk, 1.245 GiB after compression, exactly what the first VM had sent, and 206 of the 467 chunks in it were OS blocks the server already held. To rule out coincidence we backed up a third VM, byte for byte the second one, as a new guest: 1.26 GiB crossed the network and not one chunk was added to the datastore. The same guest backed up again seconds later moved about 100 KB in total.
The client skips a chunk only if it already sent it earlier in the same run or the previous backup of the same guest lists it, and the server stores each chunk once when it arrives. Proxmox VE's backup library builds that list the same way, so on our reading of the source a new VM's first backup sends every distinct chunk of its disk, however many siblings came from the same template. After that the network carries the churn. Writing 100 MiB of new data inside the guest touched 30 chunks on the next run, 120 MiB before compression and 101 MiB after, because a change is sent as whole 4 MiB chunks.
- chunks sent or pulled
- chunks new on disk
The client compares against the same VM's previous backup and the chunks already sent in the run, and the sync job against the target's last backup of the same VM. The encrypted run is a different case: its chunk digests include the key, so none matched the plain copies already stored.
Offsite pull sync moves each VM in full the first time
The pull sync job that copies a datastore to a second Proxmox Backup Server has the same blind spot. In the lab the target was a second datastore pulling through the server's own HTTPS API, the same path a sync from another site takes. Syncing the first VM's backups into it while empty pulled 1.344 GiB. Syncing the second VM straight after pulled 1.245 GiB in 467 chunks, every distinct chunk of its disk, although 206 were already there. The second datastore still ended at the same 758 chunks as the first. The sync code asks the target whether it holds a chunk only for chunks in that VM's last backup on the target.
That is arithmetic to do before you sign for the link to a disaster recovery site. We capped the second sync at 10 MiB/s, about 84 Mbit/s, and it took 2 minutes 12 seconds for 1.245 GiB. At that rate 1 TiB of compressed chunks is 29 hours, and the first sync of an estate adds up each VM's compressed chunks separately, with no credit for what the VMs share. Daily syncs after it carry only the churn. On our reading of the same code, a target that already holds a VM's last backup pulls only what changed, so for a large estate the first copy can travel on a disk: Proxmox Backup Server supports removable datastores, and one created on one server can be attached to another. We did not measure that step.
A copy abroad is also a cross-border transfer like any other, so the Data Protection Act's conditions on where data may go apply to the backup as much as to the primary. Planning a second site now? Send the VM count, the used disk across them and the link you have, and we will tell you how long the first sync runs and whether a disk should carry it.
Why deleting a backup frees no space for at least a day
We backed up the first VM again with client-side encryption, deleted that snapshot and ran garbage collection at once. It removed nothing: Removed garbage: 0 B and Pending removals: 1.341 GiB (in 490 chunks).
That is the design. Garbage collection marks every chunk the remaining backups use by updating its access time, then deletes only chunks untouched for 24 hours and 5 minutes, a grace period Proxmox's maintenance documentation ties to filesystems mounted with relatime. A datastore at 95% does not get room back today by pruning. The cutoff is tunable (gc-atime-cutoff, in minutes, minimum 1), and a second run with it at one minute removed all 490 chunks. We set it back afterward. On our reading of that cutoff, with garbage collection running daily, a chunk the last run marked is still inside the grace period at the next one, so size the datastore for a day or two of pending removals and set the alert low enough to leave that room.
Encrypted backups do not deduplicate against plain ones
That encrypted run is the second finding. Same disk, every unencrypted chunk of it already stored, and it added 490 new chunks and 1.342 GiB, because an encrypted chunk's digest is computed from the plain data together with the key. A key and no key, or two keys, are two separate copies on disk.
Encrypt anyway for any copy that leaves your building, and treat the key as the backup. Proxmox's own guidance is that backups are inaccessible without it, so a key stored only on the host it protects dies with that host. Print it with paperkey, keep one copy in a password manager and the paper in a safe away from the servers. Version 4.2 added encryption on push sync jobs, so the copy sent to a less trusted offsite server can be encrypted on the way out even when the local datastore is not.
One corrupt chunk failed three backups
Deduplication means one stored chunk belongs to many backups. That is the saving, and it is also the blast radius. We overwrote 8 bytes in one 4 MiB chunk that none of the first VM's backups used. A verify of the whole datastore failed three snapshots across two guests (the third VM was a copy of the second) and renamed the chunk to .0.bad.
- failed verify
- passed verify
VM C was a byte-for-byte copy of VM B, which is how one chunk reached two guests. Guests built from one template share their unchanged OS chunks the same way, and that sharing is where the cross-VM disk saving comes from.
The repair is the part we like. The next backup of that VM ignored the failed snapshot, logged No previous manifest available, sent all 467 of its chunks again and wrote the damaged chunk back intact. A full re-verify then passed all seven snapshots, including the three that had failed. Verify does more than report rot: it is what makes the next backup repair it. On our reading of the client, a store nobody verifies keeps pointing new backups at the bad chunk, because the client skips it as known.
A verify proves the chunks match their checksums. It does not prove the guest starts. Restoring the first VM's newest backup on the lab VM gave back 3 GiB in 9 seconds with the same SHA-256 as the source disk, and Proxmox's documentation still asks you to restore into a new guest and boot it, on a schedule. High availability does not replace any of this: it restarts a VM elsewhere when a node dies and does nothing for one somebody deleted.
Who should run Proxmox Backup Server
Anyone whose servers are Proxmox VE guests or Linux machines, and anyone moving off VMware, where the backup is the last step of the move. The software is AGPLv3 and free to install, but Proxmox does not recommend its free repository for production, and the published subscriptions are per backup server per year: EUR 560 for the Community plan, which Proxmox positions for non-production use, and EUR 1,120 to EUR 4,480 for the plans with support. Every feature works at every level. If you still run 3.x, it reached end of life in August 2026 by Proxmox's own table.
It is the wrong product when most of what you protect is not a Proxmox guest. The FAQ's answer to which platforms can be a backup source is Linux, so Windows laptops, a Windows file server on bare metal and Microsoft 365 mailboxes need something else, and an estate made mostly of those should buy one product that covers them rather than run two. It also wants fast disks. The documentation recommends enterprise SSDs for the datastore and a ZFS special device mirror on spinning disks, and garbage collection alone walks every chunk in the store each run.
What we switch on before the first backup
- A verify job every day for new snapshots, and a monthly re-verify of everything, which is Proxmox's own advice.
- Garbage collection daily, with the capacity alert set so a day or two of pending removals still fits.
- One API token per cluster holding only the
DatastoreBackuprole on its own namespace, with pruning done by a prune job on the server, so a compromised host can write backups and cannot delete them. - The offsite sync with
remove-vanishedleft off, so a deletion at the source does not reach the copy. - The encryption key printed with
paperkeyand stored away from the cluster. - A restore of a real VM into an isolated network every quarter, with the time it took written down.
One host with a handful of VMs and someone who reads logs? Put Proxmox Backup Server on a separate box, apply that list and you do not need us. Past that, the backup design is part of every cluster we design, and the redundant clusters we build carry a 99.99% HA uptime SLA. Send the VM count, the used disk across them, the link to your second site, and the last garbage-collection and verify task logs if you already run a backup server, through the Proxmox scoping form or on WhatsApp at +254 713 403 044. We send back how long the first offsite sync will take, the datastore headroom you need and which of those six your setup is missing. The answer is free, and you are under no obligation to use us.