3-2-1 backup with Proxmox Backup Server: storage costs decomposed
What a 3-2-1 backup really costs with PBS once deduplication enters the picture, decomposed copy by copy, with real per-TB numbers.
A client came to us last quarter sizing their backup budget on a simple rule of thumb: three copies of 4 TB of virtual machines, so plan for 12 TB and multiply the storage bill by three. The number scared them enough to keep postponing the offsite copy. They were wrong by roughly a factor of five, and the copy they kept delaying would have cost less than what they spend on coffee in a month. The 3-2-1 rule is sound. The way most teams price it is not, because they reason in raw data, and Proxmox Backup Server does not store raw data.
So let me decompose what a 3-2-1 setup actually costs on PBS, copy by copy, with the numbers we charge today.
What 3-2-1 looks like on PBS
Three copies of your data, on two different media, with one of them offsite. On PBS the mapping is direct. Copy one is your primary datastore, on disks you already own. Copy two is a second datastore on different hardware or in a different location, reached with a sync job, push from the source or pull from the target. Copy three is an offsite copy on object storage, ideally immutable.
PBS gives you the two mechanisms that matter here out of the box: datastore-to-datastore sync for the second media, and object storage integration for the offsite copy. You are not scripting your own plumbing, you are configuring jobs. Storage synchronization and object storage sync cover the setup itself.
Why three copies don’t cost three times the data
PBS splits every backup into chunks, deduplicates them, and compresses what is left. A snapshot is not a full copy. It references the chunks already in the datastore and adds only what changed since the last run. Keep ninety daily snapshots of a VM and the datastore does not grow ninety times. It grows by the daily delta.
The consequence for your budget is the whole point of this article. The figure that lands on your storage bill is the effective deduplicated footprint of the entire retained chain, not the raw size of a VM times the number of snapshots times three copies. Get that wrong and you overestimate by an order of magnitude, which is exactly how an offsite copy ends up looking unaffordable when it is the cheapest insurance you will ever buy.
The catch nobody budgets for: encryption
There is one variable that moves the bill more than any other, and it is the pattern we see most consistently across our datastores: client-side encryption.
Encrypted chunks are high-entropy by design, so PBS cannot compress them. The compression half of the ratio drops to almost nothing. And because the chunk digests are keyed, identical data encrypted under two different keys no longer deduplicates against each other, so you lose the cross-source savings too. The result is easy to state and easy to forget: an encrypted datastore stores noticeably more for the same protected data than a cleartext one.
Ratios across a fleet are erratic, they depend entirely on the workload, and I will not pretend we have one clean number for 300 datastores. But that gap between encrypted and cleartext is the steadiest thing we observe. If you encrypt client-side, and for sensitive data you should, budget for a lower ratio and a higher bill. It is a real security-versus-cost tradeoff, and it deserves to be in the decision rather than discovered on an invoice.
Decomposed, copy by copy
Take a concrete case: 2 TB of running VMs, with a retention of fourteen daily, eight weekly and six monthly snapshots. I will run it twice, because encryption is the variable that matters. An unencrypted datastore landing around an 8:1 effective ratio, and a client-side encrypted one closer to 3:1. Treat these ratios as illustrative, yours will differ, but the structure holds.
| Copy | Role | Where | Effective size (8:1 / 3:1) | Monthly cost |
|---|---|---|---|---|
| 1 | Primary | Your own PBS and disks | ~256 GB / ~683 GB | already owned |
| 2 | Second media | Cloud-PBS, datastore sync | ~256 GB / ~683 GB | 6 € / 10 € |
| 3 | Offsite, immutable | Cloud-PBS object storage | ~256 GB / ~683 GB | 6 € / 10 € |
The first copy sits on hardware you already run, so it adds nothing to the cloud bill. The two that do are the second media and the offsite copy, and on Cloud-PBS storage at 12 € per effective TB per month they come to about 12 € a month unencrypted, about 20 € encrypted, for 2 TB of protected VMs. Restores read back from object storage with no egress charge, so a recovery never surprises you on the next invoice.
Now the naive version, the one my client used. Three copies of 2 TB of raw data is 6 TB to store, and at the same 12 € per TB that is 72 € a month, before you have even decided where the copies live. Same rule, same data, five to six times the budget, purely because the estimate ignored what PBS does to the data on the way in.
From 3-2-1 to 3-2-1-1-0
If you are going to size this properly, size it for where backup strategy is heading. The extra “1” is one immutable copy: object lock on the offsite tier, so a compromised admin account or a ransomware payload cannot rewrite or delete it. The “0” is zero recovery errors, and that is where PBS verify earns its keep. A scheduled verify reads the chunks back and checks them, so the copy you are paying to keep is a copy you can actually restore. Paying for storage you have never tested is not a backup strategy, it is a hope.
Size your backup budget on effective storage, not on raw capacity, and the offsite copy stops being the line item you defer. For 2 TB of VMs you are looking at the price of two lunches a month for a genuine second media and a genuine offsite copy, egress included. Start from your own measured ratio if you have one. If you do not, run a month on a single datastore and read the number straight off the dashboard before you commit to a tier. You can do exactly that on a Cloud-PBS trial, where the per-TB tiers used above are the ones you will actually pay.