PBS Capacity Planning for Multi-Client

You signed a new client. They have 30 VMs, a vague idea of how much data they produce, and they want a quote by Friday. You need to tell them how much storage their backups will consume on your Proxmox Backup Server infrastructure. Guess too low and you're buying emergency drives mid-contract. Guess too high and you're eating margin on unused capacity.

PBS deduplication makes this harder than you'd expect. Raw data size tells you almost nothing about actual storage consumption. The real number depends on workload type, retention policy, change rate, and how much overlap exists across VMs. This post gives you the math to estimate it.

Why Capacity Planning Matters

Storage is the single largest cost in a PBS-based MSP operation. Get sizing wrong and the consequences hit fast.

Underestimate and you're scrambling. Datastores fill up, garbage collection fails because it needs working space, backup jobs start failing, and you're calling your storage vendor for expedited drives on a Saturday.

Overestimate and the waste is quieter but real. Unused capacity sits idle. Capital you could have deployed elsewhere is locked in spinning rust or flash that won't see data for months.

The challenge is that Proxmox Backup Server's chunk-level deduplication makes naive estimation useless. A client with 10 TB of raw VM data might consume 2 TB of actual storage. Or 6 TB. The difference depends on factors you can measure and predict, but only if you know what to look at.

Understanding PBS Deduplication Impact

PBS breaks every backup into fixed-size 4 MB chunks and stores each unique chunk exactly once. This deduplication happens at two levels, and understanding both is critical for sizing.

Same-VM Deduplication

When you back up the same VM on consecutive days, most chunks are identical. The OS didn't change. Most application files didn't change. Only the chunks containing modified data are new. This same-VM dedup ratio is typically 85-95% across snapshots, meaning each incremental snapshot adds only 5-15% of the VM's total size in new chunks.

Cross-VM Deduplication

When multiple VMs share common content, PBS deduplicates across them too. Ten VMs running Debian 12 share most of their OS chunks. The dedup benefit here depends entirely on how similar the workloads are.

Database servers dedup poorly because transaction logs and data files change constantly. File servers are worse, especially when users are actively creating and modifying documents. Template-based VM fleets are the sweet spot.

How to Check Dedup Ratios

proxmox-backup-manager datastore list --output-format json-pretty

The output includes used, avail, and the dedup factor per datastore. Compare used against the sum of all snapshot sizes to see how much dedup is saving you.

Retention Policy Storage Math

Retention is where most sizing estimates go wrong. People multiply daily change rate by retention days and call it done. That ignores dedup entirely.

Here's the actual formula:

storage_needed = (total_raw_data / dedup_factor)
               + (daily_change_rate × unique_retention_days)

The first term is your baseline: all current data after deduplication. The second term is the incremental cost of keeping history. But even the incremental snapshots dedup against each other, so the real cost of adding retention days flattens over time.

Let's run real numbers. A client has 10 TB of raw VM data, a dedup factor of 4x, and a 2% daily change rate.

Notice the jump from 7-day to 30-day + 12-monthly is not 4x more storage. Deduplication across snapshots means older monthly snapshots share most of their chunks with newer ones. The incremental cost of keeping a 6-month-old snapshot is tiny compared to the first week.

Client Onboarding: Sizing New Accounts

When a new client signs up, you need two numbers: how much storage the initial seed will consume, and what the steady-state looks like after dedup kicks in.

Initial Seed

The first full backup is always the most expensive. Dedup has nothing to compare against, so every chunk is new. For a client with 5 TB of raw data and a 3x expected dedup factor across their VMs, budget roughly 1.7 TB for the initial seed. Use the initial seed calculator to estimate transfer time.

Steady-State

After 7-10 days of backups, the dedup index is populated and storage growth drops sharply. The delta between day-1 and day-10 storage is dramatic for clients with homogeneous VM fleets.

These ranges are wide because workload mix matters enormously. A 20-VM fleet of identical web servers will land at the low end. A 20-VM fleet of database servers, file servers, and custom applications will hit the high end.

Safe Padding

Always add 20-30% on top of your steady-state estimate. Clients add VMs. Applications grow. That padding absorbs normal growth without triggering emergency expansions.

Forecasting Growth

Sizing the initial deployment is half the job. The other half is predicting when you'll need more.

Monthly Growth Tracking

Pull datastore usage monthly for every client. A simple script against the Proxmox Backup Server API gives you what you need.

for ds in $(proxmox-backup-manager datastore list \
    --output-format json | jq -r '.[].name'); do
  echo "=== $ds ==="
  proxmox-backup-manager datastore show "$ds" \
      --output-format json-pretty | jq '{
    name: .name,
    used_bytes: .used,
    total_bytes: .total,
    usage_pct: ((.used / .total) * 100 | floor)
  }'
done

Log this output to a file or push it into your monitoring stack. Month-over-month trends tell you more than any point-in-time snapshot.

Identifying High-Growth Clients

Not all clients grow at the same rate. A marketing agency uploading video files will outgrow a static web hosting client 10:1. Flag any client whose monthly growth exceeds 5% of their current allocation and review whether their sizing assumptions still hold.

When to Add Capacity

Thresholds matter. Running a Proxmox Backup Server datastore above 80% is asking for trouble because garbage collection needs free space to work, and a failed GC means orphaned chunks never get cleaned up.

Practical Example: 20-Client MSP

Let's walk through a real scenario. You're an MSP onboarding 20 clients onto a single PBS server with 50 TB of usable storage.

Client breakdown:

• 8 clients with 5-10 VMs each (mostly web servers, standard Debian): ~400 GB raw each
• 6 clients with 10-20 VMs (mixed workloads): ~3 TB raw each
• 4 clients with database-heavy stacks: ~5 TB raw each
• 2 large clients with 40+ VMs: ~15 TB raw each

Raw total: ~71 TB across all clients.

Dedup-adjusted estimate:

• Web server clients (high dedup, 5x factor): 8 × 400 GB / 5 = 640 GB
• Mixed workload clients (3x factor): 6 × 3 TB / 3 = 6 TB
• Database clients (1.8x factor): 4 × 5 TB / 1.8 = 11.1 TB
• Large clients (2.5x factor): 2 × 15 TB / 2.5 = 12 TB

Baseline storage: ~29.7 TB

With 7d + 4w retention and 2% daily change: add roughly 15-20%, so ~34-36 TB.

With 25% growth padding: ~43-45 TB.

That fits your 50 TB server with room to breathe. But it's tight enough that you should be monitoring monthly from day one and planning your next storage expansion before you hit 70%.

Common Mistakes

Sizing from raw data alone. A prospect says "we have 20 TB of VMs" and you provision 20 TB. After dedup, they use 6 TB. You overpaid.

Ignoring change rate. Two clients with 5 TB of VMs but wildly different change rates will have completely different storage profiles at 90 days.

Treating all VMs equally. A Windows AD controller barely changes. A busy PostgreSQL server churns constantly. Estimate per workload type, not per VM count.

Skipping the monitoring loop. You sized correctly at onboarding, then never checked again. Eighteen months later, three clients doubled their VM count and nobody noticed.

Wrapping Up

Capacity planning for Proxmox Backup Server in multi-client environments comes down to three things: understand the dedup math for each workload type, factor in retention policy costs, and monitor growth relentlessly. Get the initial sizing close enough with the tables and formulas in this post, then let real data refine your projections after the first month.

The biggest risk isn't getting the initial estimate wrong. It's failing to track growth and adjust. Build the monitoring loop from day one and you'll never be caught off guard.