Almost nobody looks at their backups until the day they need them. Then every question arrives at once: does the copy exist? Is it intact? How old is it? How long does a restore take? Is it sitting in the same place as the system that just went down? And the worst one of all: has anyone ever proved that this actually works?
In Proxmox VE environments, Proxmox Backup Server (PBS) answers those questions better than most alternatives in the open source ecosystem. We already published an introduction to Proxmox Backup Server and how it fits with Stackscale’s Archive storage. This article goes one step further into the mechanics: what deduplication actually does, why verification is not optional, how prune and garbage collection differ, how one server can serve several customers without mixing anything up, how to recover a single file without touching the whole machine, and how all of that turns into design decisions when the infrastructure lives in a private cloud with storage in two Madrid zones more than 10 kilometres apart.
PBS is not “just another backup tool”
Proxmox Backup Server is a Debian-based Linux distribution, written largely in Rust and released under the GNU AGPLv3 licence. It is built for one job: storing and returning data from virtual machines, containers and physical servers. Version 4.2, released in April 2026, is based on Debian 13.4 “Trixie”, Linux kernel 7.0 and ZFS 2.4, and adds official support for S3-compatible object backends, encryption in sync jobs and concurrent processing of backup groups.
The practical difference compared with a traditional dump to disk or to a NAS comes down to three mechanisms working together: deduplication (how much space it takes), verification (whether it is usable) and retention (how long copies are kept and when space is actually released). Teams that understand those three size their environment properly. Teams that don’t end up with a full repository, backups nobody has ever checked and a restore that turns into an experiment.
Deduplication: why 30 copies don’t take 30 times the space
PBS does not store monolithic backup files. It splits data into blocks —chunks, averaging around 4 MiB—, calculates the SHA-256 digest of each one and stores it only once within the datastore. If that same block shows up again tomorrow, the backup simply records a reference to it.
Three consequences are worth having clear before sizing anything:
- Every backup is incremental, yet restores like a full one. After the first copy, each run only adds new blocks. When restoring there is no chain of incrementals to rebuild: any snapshot stands on its own.
- Deduplication is global within the datastore. It is not limited to a single VM: ten machines running the same operating system share the common part only once. And since namespaces live inside the same datastore, you can separate environments (production, staging, customers) without losing that saving.
- The “VM size × number of copies” calculation is useless. It is the sum everyone does in the first meeting, and it always produces an absurd number. Real consumption is a fraction of it, because what grows is not the number of copies but the volume of data that changes between them.
That last point changes the conversation. The useful question is not “how much does each backup take?”, but “how much data changes per day on this platform?”. A transactional database and a file server holding documents that barely move can be a similar size on disk and have very different backup storage needs.
On the hypervisor side there is a detail that speeds things up considerably: Proxmox VE uses QEMU dirty bitmaps to know which blocks of a VM have changed since the last copy, without re-reading the whole disk. That map lives in memory, so it is lost when the machine is shut down or migrated; on the next run PBS will read the full disk again, although it will only transfer and store what is genuinely new. An occasionally slower backup after a maintenance window is not a sign of trouble.
Verification: finding corruption while it still doesn’t matter
The problem with bit rot is that it gives no warning. A block can degrade on the media, a hardware or software failure can damage data that was already written, and nothing in the dashboard turns red. The backup still shows up in the list, with its date and its size. The day you need it, it doesn’t open.
PBS addresses this with schedulable verification jobs: they re-read the stored blocks, recalculate their digests and compare them with the originals. What this achieves is not preventing corruption, but bringing forward the moment it is discovered: from the middle of the night during a disaster to an ordinary Tuesday, while a good copy still exists somewhere else and there is room to react.
Two operational details make a real difference in large repositories:
- Verification can be configured to skip snapshots already verified in the last N days, so each pass focuses on what is new instead of re-reading the entire repository every week.
- A snapshot that fails verification is flagged. Make sure that flag reaches a person and not just a log entry: a backup marked as faulty and left unattended is exactly as useful as not having one.
That said, two things should not be confused. Verification proves the blocks are intact; it does not prove the service boots. Whether a database comes up, the application connects and the business can operate is only proven by an actual restore. Verification is the necessary condition; a periodic restore test is the sufficient one.
Retention and garbage collection: two different things everyone mixes up
Here lies the most common misunderstanding about PBS, and the one that fills repositories: prune does not free space.
- Prune applies the retention policy and decides which snapshots are no longer needed. It removes the reference to the backup, but it does not touch the blocks: they are deduplicated and very likely still in use by another copy.
- Garbage collection (GC) is what reclaims space. It walks the datastore, marks the blocks still referenced and removes the orphans. It works with a time safety margin so it never deletes blocks belonging to a backup being written at that moment, which is why freed space does not appear instantly.
Both processes are scheduled separately and both must be scheduled. An environment with a retention policy in place but no periodic GC keeps growing until somebody gets a disk-full alert, usually at the weekend.
As for the policy itself, PBS lets you build a pyramid with several levels: last N, daily, weekly, monthly and yearly. A reasonable starting point for a production platform:
| Level | Example | What it is for |
|---|---|---|
| Last | 3 copies | Undoing a recent mistake (a deployment, a deletion) |
| Daily | 7 | Going back to any day in the last week |
| Weekly | 4 | Covering the month with few restore points |
| Monthly | 6-12 | History and business requirements |
| Yearly | 1-5 | Legal or contractual obligations, where they apply |
The temptation to keep everything “just in case” is understandable, but retention is not a technical decision: it is a business decision and, in some sectors, a regulatory one too. It is worth agreeing it in writing with whoever is accountable for the data, rather than leaving it to whoever configures the job. We cover this in more detail in our article on the difference between backup and data retention.
Client-side encryption: what makes the remote copy viable
PBS encrypts on the client side, on the Proxmox node itself, before the data leaves the network, using AES-256-GCM. The backup server stores information it cannot read. That has two practical readings:
- It allows you to send copies to a remote location or to an object backend without the destination having to be a point of trust. The data travels encrypted and stays encrypted.
- Lose the key and you lose the backups. There is no recovery path. The key must be looked after like a critical asset: a copy outside the environment it protects, a printed version in a safe place and a written procedure covering who can access it.
One technical detail often catches people out: deduplication still works with encryption enabled, but only between backups sharing the same key. Using a different key per customer or per environment is a legitimate isolation decision; you simply need to know that it reduces the space saving, because those sets no longer share blocks.
Since version 4.2, sync jobs also handle encryption: push jobs encrypt before sending and pull jobs can decrypt remote data, with key management centralised alongside tape.
Taking the copy further away: sync jobs between locations
A single repository, however well verified, is still a single point of failure. PBS handles distribution with sync jobs between servers or datastores: in pull mode the destination collects, in push mode the source sends. Either way only the missing blocks travel, which makes a daily replica between locations perfectly manageable even with large volumes. Version 4.2 adds concurrent processing of several groups, which is especially noticeable when latency is involved.
One PBS for several customers: what namespaces are for
Namespaces are hierarchical subdivisions inside a single datastore, and they are the piece that turns a backup server into a multi-tenant platform. With them, one PBS instance can serve several customers, several business units or several clusters without anything getting mixed up.
- Isolation through permissions. Each namespace has its own ACLs. A customer, a partner or an internal team only sees its branch of the tree, and API tokens are issued with that scope: there is no way to list, restore or delete what sits next door.
- Policies of their own. Retention, verification and sync are configured per namespace. A customer keeping seven days of backups and another required to keep years can live in the same repository without one imposing its rules on the other.
- No extra storage cost. Deduplication remains global within the datastore, so separating customers does not multiply storage. If each customer encrypts with their own key, isolation is stronger but blocks are only shared within each set: that is the price of the separation.
- A target for sync jobs. A sync job can land each remote source in a specific namespace. That is the usual pattern when several clusters, branches or customers are centralised into a single PBS.
This is the architecture used by managed providers and partners offering backup as a service: one repository, many tenants, separate accounts. With two practical caveats. First, there are no hard quotas per namespace: growth is controlled through the retention policy and through monitoring, not by a limit that stops a customer who overshoots. Second, space reclamation (GC) applies to the whole datastore, so maintenance windows are planned globally rather than customer by customer.
In 4.2, groups and namespaces can also be moved between locations, which helps when the initial structure falls short —a customer that grows, an environment that needs splitting off— and things need reorganising without redoing backups.
Backups from inside the machine: proxmox-backup-client and single files
So far we have talked about whole-machine backups, which is what you launch from Proxmox VE. But PBS is not limited to that: there is proxmox-backup-client, a client installed inside the VM, the container or a physical Linux server, which backs up the directories you tell it to, with its own schedule, its own encryption and its own namespace.
That changes what can be recovered, and how quickly:
- Recovering a single file —an attachment deleted by mistake, a configuration file, an application’s data directory— without restoring the whole machine or spinning up a parallel copy just to pull one folder out of it.
- Protecting specific paths at a different frequency. An application’s data directory can be backed up hourly while the full machine backup stays daily.
- Covering servers outside that cluster: physical machines, legacy systems or hosts running elsewhere that send their data to the same repository, with the same encryption and the same retention.
The workflow is straightforward: install the client, point it at the repository and back up the chosen paths, which travel in pxar format and are deduplicated and encrypted like everything else.
proxmox-backup-client backup data.pxar:/var/www
--repository backup@pb*@*bs.internal:store
--ns customer-aThose archives can then be listed or mounted to extract only what is needed, without pulling down the whole set.
Think of it as a complement rather than a replacement. The whole-machine backup is what brings the service back after a disaster; the client inside the machine is what solves the “I’ve just wiped a file” moment on a Tuesday morning. For VM backups, Proxmox VE also offers file-level restore from the interface itself and live restore, which boots the machine while the restore continues in the background; between the three routes, almost every real incident is covered.
How this lands on a Proxmox private cloud at Stackscale
All the theory above boils down to one very concrete question: where do the blocks live. At Stackscale we build backup for Proxmox environments on Archive storage, accessible over NFS or through an S3-compatible API, and available in physically separate locations: two zones in Madrid, more than 10 kilometres apart, plus a third in Amsterdam.
That distance is not a brochure detail. It is what keeps two data centres out of the same physical incident —a fire, a flood, a power outage affecting one area— while maintaining metropolitan latencies, low enough that a daily sync, or several a day, never becomes a problem. It is the difference between “we have a copy in another rack” and “we have a copy in another risk zone”.
Reference architecture
| Layer | Where | Purpose |
|---|---|---|
| Primary datastore | Archive in Madrid, zone A (NFS or S3) | Reference copy. Every backup job writes here |
| Replica | Archive in Madrid, zone B (>10 km) or Amsterdam | Daily sync job. Survival if a whole location is lost |
| Fast layer (optional) | All-flash network storage | Most recent copies, for frequent restores and low RTO |
| Local disk on the PBS host | Backup server | A temporary buffer at most. Never the only repository |
The design principle is simple: the reference copy always lives on Archive, not on the disk of the server running the backups. A local repository depends on the health of one specific machine and adds no redundancy; if that server is lost in the same incident as the cluster, so is the ability to recover. Fast layers are a cache to speed up restores, not the source of truth.
With this setup, the 3-2-1 rule stops being a slogan: three copies (production plus two repositories), on different media and systems, with at least one outside the primary location. And all of it with the data in European data centres, something that has moved from a technical preference to a contractual requirement in quite a few sectors.
An operational calendar that works
More important than the architecture is having someone keep it alive. This is a sensible starting calendar for a production platform:
| Task | Indicative frequency | Note |
|---|---|---|
| VM and container backup | Daily, in a low-load window | With bandwidth limits if it shares the network with production |
| Sync to the second location | Daily, after the backup window | Only new blocks travel |
| Verification | Weekly, skipping what is already verified | With an alert to a person, not just to the log |
| Prune | Daily | Applies the policy; does not free space |
| Garbage collection | Weekly | This is what actually reclaims space |
| Restore test | Quarterly, and after significant changes | Restore and boot, not just verify |
Five mistakes that keep coming up
- Sizing by multiplication. Calculating storage as size times number of copies leads to unrealistic budgets and to retention policies that are far too short.
- Scheduling prune and forgetting GC. Space does not come back on its own.
- Confusing verification with a restore test. They are different controls and neither replaces the other.
- Keeping the encryption key inside the environment it protects. If the incident takes out the cluster, it takes the key with it.
- Designing only for the big disaster. Most real restores involve one file or one directory, not an entire data centre; without
proxmox-backup-clientor file-level restore, every minor incident means bringing up a full VM. - Leaving the only copy in the same building. A replica to a second location kilometres away is what turns a backup into a disaster recovery plan.
Frequently asked questions
How much space do I really need for 30 days of backups?
It depends on how much data changes, not on the total size of the machines. Because deduplication is global within the datastore and backups are incremental, keeping 30 days does not multiply consumption by 30: it is much closer to the size of the first copy plus the accumulated daily change. The sensible approach is to measure the real change rate for a few weeks before finalising the sizing.
What is the difference between prune and garbage collection?
Prune applies the retention policy and removes snapshots from the list, but it does not delete blocks, since they are usually shared with other copies. Garbage collection identifies the blocks no backup references any more and removes them, which is when space is reclaimed. Both need to be scheduled.
If I verify my backups, do I still need to test restores?
Yes. Verification checks that the stored blocks are intact; it does not check that the system boots, that the database is consistent or that the application works. A periodic restore test, with the service actually starting up, is the only control that validates the whole chain.
Is it safe to keep backups in a remote location?
With client-side encryption, yes: data is encrypted with AES-256-GCM on the Proxmox node before it leaves and the destination cannot read it. The trade-off is key custody: without the key there is no restore, so it must be stored outside the environment it protects.
Why does it matter that the two Madrid zones are more than 10 km apart?
Because it keeps both locations out of the same physical incident —fire, flood, an area-wide power cut— while maintaining metropolitan latencies. It allows copies to be synced daily, or several times a day, with no operational penalty, and it meets the geographic separation requirements of a continuity plan without leaving Spain.
Can I serve several customers from a single Proxmox Backup Server?
Yes, using namespaces. Each customer works in its own branch of the datastore, with independent permissions, API tokens, retention and verification, while deduplication stays global so you pay no storage penalty for separating them. Bear in mind that there are no hard quotas per namespace and that space reclamation affects the whole datastore.
Can I recover a single file without restoring the whole machine?
Yes, in two ways. On a VM backup, Proxmox VE offers file-level restore straight from the interface. And if you install proxmox-backup-client inside the machine, you can back up the paths you care about on their own schedule and then list or mount them to extract only what you need.
In short
Proxmox Backup Server does the hard part well: storing little, catching corruption in time and returning data quickly. What it cannot decide for us is how long things are kept, where the second copy lives, who holds the keys and how often a real restore is tested. Those four decisions are what separate a backup that gives peace of mind from one that only looks like it does.
At Stackscale we design the whole set —Proxmox cluster, PBS and Archive storage across several locations— as a single piece. If you are building or reviewing the backup strategy of your Proxmox environment, let’s talk it through.
