PBS stores data far more efficiently than you’d naively expect. When the GUI shows you 50 snapshots of 100 GB each, you think: 5 TB. In reality that often occupies just 200–400 GB. Here’s why.
How PBS stores with deduplication
PBS splits every backup into chunks of roughly 4 MB. Each chunk gets a hash (SHA-256) and is stored in the pool under that hash. If a second backup snapshot contains the same data block (same hash), it is not stored again — the second snapshot simply references the existing chunk.
This happens automatically and across the board:
- The daily backups of one VM share 95–99% of their chunks (only each day’s difference is new).
- Different VMs with the same operating system often share 30–50% of their chunks (Linux kernel files, the /usr directory, standard packages).
- Back up the same snapshot twice → exactly 0 extra storage.
Where you see the storage usage
In the PBS GUI, in three places:
1. Datastore summary
Datastore → <your-datastore> → Summary: shows used/free in GB plus a usage graph of the last weeks.
That is the amount of data actually occupied on disk — after deduplication. The most important number for you.
2. Snapshot sizes
Datastore → Content → <vm> → click a snapshot: each snapshot shows a “Size”.
Careful: that is the uncompressed, non-deduplicated data volume of the backup. If you add those up, you get the naive number (50 snapshots × 100 GB = 5 TB) — which has nothing to do with the actual disk usage.
3. Status via CLI — from your PVE
proxmox-backup-manager only runs on the PBS host itself — and you don’t have shell access there. What you use instead: the client on your PVE.
proxmox-backup-client status --repository 12345@pbs@pbs01.xaweho.de:12345Shows:
- Total: total disk size
- Used: actually occupied
- Avail: free
You find the deduplication factor in the GUI in the datastore summary. A Deduplication factor: 8.5 means: without deduplication, the datastore would need 8.5× more storage.
How much storage a typical setup needs
Rule of thumb:
- 1 VM with 100 GB of data, daily backups, 30 days retention → 130–180 GB disk usage.
- 5 VMs of 100 GB each, daily backups, 30 days retention → 400–700 GB disk usage (much less than 5×130 GB, because VMs share chunks).
- 10 VMs of 50 GB each, daily backups, 6 months retention → 600–900 GB disk usage.
Variations:
- Database VMs with a high change rate: higher usage (more “new” chunks per day).
- Static file servers: lower usage (little change).
- VMs with the same OS: heavily deduplicated.
What counts for your plan size
What counts for your plan is the actual disk usage (after deduplication) — that is, what the datastore really occupies after dedup and compression, not the nominal size of your VMs. If the datastore fills up, you upgrade in 1 TB steps.
If you permanently use more than your plan allows, you simply upgrade to the next size — the tiers go in 1 TB steps up to 25 TB, and your backups stay in place. Prices are on the product page.
When usage doesn’t drop after prune
Classic scenario: you pruned 30 snapshots and the datastore is still full. What now?
- Garbage collection hasn’t run yet: prune only marks, GC does the actual cleanup. Check when the next GC run is.
- Start GC manually: Datastore → Prune & GC → Run garbage collection.
- Usage stays high even after GC: the pruned snapshots shared chunks with other snapshots. Those chunks stay, because they’re still needed.
The only way to truly shrink a datastore: delete snapshots until nothing references the chunks anymore. That’s usually unrealistic — you want to keep backups, after all.
More on this in garbage collection.
Frequently asked questions
What are “index size” and “chunk size”?
Index files (.fidx) are small and describe which chunks belong to which snapshot. Chunks are the actual data blocks — the bulk of the usage.
How do I see which VM uses the most storage?
Hard to say directly — because of deduplication, a chunk doesn’t uniquely “belong” to one VM. Approximation: in the GUI under Content, group by VM node and add up the snapshot sizes. Or via CLI from your PVE: proxmox-backup-client list --repository 12345@pbs@pbs01.xaweho.de:12345 (shows all backup groups).
Does it make a difference whether I delete snapshots all at once or spread over several days? No. What counts is the final set of referenced chunks after GC. The order of deletion doesn’t matter.
Why do I sometimes see “Out of space” during a backup even though there’s storage left? Sometimes a reporting delay. It can also come from temporary storage during writing that is larger than the finished backup. For frequent out-of-space errors: open a ticket and we’ll check the disk usage.
How can I free storage manually? Delete snapshots (manually or via prune), then run GC. There are no other levers — PBS manages this fully automatically.
Why is my backup size per snapshot constant even though the VM barely changes anything? The snapshot “Size” in the GUI is the uncompressed size of the snapshot — it would be just as large if it shared not a single chunk with others. The actual disk usage is much smaller. Look at the datastore summary, not the individual snapshot size.
Can I disable deduplication? No. Deduplication is core PBS architecture — without it, storage usage would be unrealistically high.
What’s next
First login to the Proxmox Backup Server — what you see in the GUI
After ordering, the login mail arrives. Here's an overview of the most important areas of the PBS GUI — datastore, sync, tape, users, notifications.
Setting up the datastore as a backup target in Proxmox VE
Add your xaweho PBS datastore to your Proxmox VE in a few clicks — via GUI or CLI, with fingerprint and login.
Creating an encryption key for PBS and storing it safely
Enable client-side encryption with AES-256-GCM. Generate the key, store it safely and register it in the PBS storage.
Running your first backup to the PBS — step by step
A manual test backup of a single VM to check that the datastore is connected correctly and everything works.