Writing archives to a directory works until retention costs more than the guests do, or until the day a restore turns out to be unreadable. A dedicated backup server changes the economics through content-addressed storage and adds the one thing a plain archive cannot offer, which is proof that what was written is still intact. Here is what it does and the three schedules that decide whether it works.
Proxmox VE can write backups to a directory, and for a while that is fine. The reasons to run a separate backup server are deduplication, verification and the fact that a backup living on the cluster it protects is not really a backup at all.
What It Does That vzdump Alone Does Not
The built-in backup writes a compressed archive per run. Full every time, or an approximation of incremental that still moves most of the data. Proxmox Backup Server changes the model to content-addressed chunks: a guest's disks are split into variable-sized chunks, each stored once and referenced by hash.
Three consequences follow, and they are the whole case for the extra component.
A daily snapshot costs what changed. Two hundred VMs from the same template share their base chunks. Retention of thirty daily backups does not cost thirty times one backup.
Backups can be verified. The server re-reads chunks and checks them against their hashes on a schedule, so bit rot and a truncated write are found while there is still a good copy, not during a restore.
A single file can be restored. The file-level browser reads inside a guest's disk image, which turns the common request, one deleted directory, into a two-minute operation rather than a full VM restore into a scratch space.
Sizing the Server
The datastore's performance characteristics matter more than its raw size, because chunk operations are small and numerous.
| Component | What to provide | Why |
|---|---|---|
| Datastore disks | Redundant, and prefer many spindles or SSD | Garbage collection and verification are IOPS-heavy |
| Metadata / special device | SSD or NVMe if the datastore is on ZFS | Chunk index lookups dominate small-file latency |
| RAM | Comfortable headroom, more with ZFS ARC | Index caching decides backup and GC speed |
| Network | 10 GbE or better to the cluster | First full backup moves everything once |
Do not put the datastore on the same storage as the guests it backs up. That defeats the point, and the failure that takes the storage takes both copies.
The Parts You Configure Once
Create a datastore, add it to Proxmox VE as storage of type pbs, then set three schedules that people routinely leave at defaults and later regret.
Prune. Decides which snapshots to keep by keep-last, keep-daily, keep-weekly and keep-monthly. Prune removes the snapshot's index entry, not its data.
Garbage collection. This is what reclaims space, by deleting chunks nothing references any more. Without GC scheduled, pruning appears to free nothing and the datastore fills.
Verification. Re-reads and re-hashes chunks. Schedule it, and schedule re-verification of older snapshots at a longer interval, so a corrupt chunk surfaces on its own rather than during an incident.
Prune without GC is the single most common operational mistake with this product. The second is scheduling GC and verification to run simultaneously with backups, on the same disks, and then wondering why the backup window grew.
Encryption and the Key You Must Not Lose
Client-side encryption means the VE host encrypts chunks before sending them, so the backup server stores data it cannot read. That is exactly what you want for a backup server in someone else's facility, and it moves the entire risk onto key custody.
The key lives on the VE host. Lose it and every encrypted backup is permanently unreadable, with no recovery path by design. Export the key, store it somewhere that is not the cluster and not the backup server, and test a restore on a host that does not already have the key cached, because a restore that only works on the original host is not a disaster recovery plan.
Our guide to backup encryption and key recovery covers the custody question in more detail, including the arrangements that survive the person who set them up leaving.
Off-Site With Sync Jobs
One backup server in the same rack as the cluster addresses deletion and corruption, not fire, flood or ransomware with domain credentials. Sync jobs replicate a datastore to a second server, and the direction matters.
Prefer a pull configuration, where the remote server reaches into the primary. The remote then needs no inbound access from the production network, so an attacker who owns the cluster cannot reach the off-site copy to delete it. A push from primary to remote gives the primary credentials that do exactly that.
Tape and removable media exist for the same reason, and so does keeping one copy where nothing automated can delete it. Our guide to immutable backups against ransomware covers why that last property is the one that matters when the credentials are compromised.
Restores Are the Only Test That Counts
A green backup job proves data was written. It does not prove a guest boots, that the filesystem is consistent, or that anyone knows the procedure under pressure.
Restore a real VM to an isolated network on a schedule. Boot it, log in, check that the application starts and the data is the age you expected. Write down how long it took, because that number is your actual recovery time objective and it is usually longer than the one in the plan.
Two failure modes only a restore finds: a guest whose bootloader or driver configuration did not survive, and a database whose files were captured mid-write so recovery replays a log and lands somewhere unexpected. For the second, add an application-aware dump alongside the image backup rather than relying on the snapshot.
Where This Fits With Managed Infrastructure
Running a backup server is a modest amount of work and an unbounded amount of judgement, most of it about retention, off-site placement and proving restores.
MassiveGRID runs Proxmox high-availability clustering with automatic failover over Ceph storage that replicates every block three times across independent NVMe drives, which handles hardware failure but is not a backup and does not protect against deletion. Backup services add that layer with block-level incremental backups, AES-256 encryption, and storage on RAID10 in Tier-3 and Tier-4 datacenters at $0.01 per GB, with two free VPS snapshots included and destinations in the US and EU. Proxmox support covers the cluster you run yourself, from $99 per node per month, including the backup and retention design if that is the part you would rather not own.
Infrastructure can be ordered across a partner footprint of more than 700 datacenters in 85 metros, 30 countries and six continents, with auto-provisioning in New York, London, Frankfurt and Singapore, which gives an off-site datastore somewhere genuinely separate from the cluster.