PBS for MSPs: Multi-Tenant Backup Service

You run an MSP. You manage dozens of client environments. Each one needs backups, and each client thinks their data is the most important thing in the world. They're right. The problem? Most backup platforms charge per-socket, per-agent, or per-VM licensing that eats your margins before you've even started.

Proxmox Backup Server changes that equation. No per-seat licensing. Chunk-level deduplication across every client. Client-side encryption that keeps you out of legal trouble. And an API that lets you automate everything from onboarding to billing.

Why PBS Works for MSPs

Most backup vendors price their products to extract maximum revenue from managed service providers. Per-socket fees. Per-agent charges. Tiered licensing that punishes you for growing. Veeam and Acronis both follow this model, and the math gets ugly fast when you're managing 50+ client environments.

Proxmox Backup Server takes a different approach. The software is open source with optional enterprise support subscriptions. Your cost is storage and compute, not license keys. That means your margins stay healthy as you add clients.

But cost isn't the only advantage. PBS handles VMs, containers, bare-metal Linux, and Windows machines from a single platform. You don't need separate products for different workloads. One tool, one interface, one API.

The deduplication engine works at the chunk level using content-addressable storage. When two clients back up identical OS base images or common application files, PBS stores those chunks once. Across a portfolio of 30+ clients running similar stacks, dedup ratios of 3:1 or better are common. That's real storage savings you can reinvest or pass on.

Then there's client-side encryption. Each client's backup agent encrypts data with AES-256-GCM before it leaves their network. The encryption key never touches your PBS server. You're hosting encrypted chunks you physically cannot read. That's not just good security practice; it's a legal shield. When a client asks "can you see our data?" the honest answer is no.

Multi-Tenant Architecture

The first decision when building a multi-tenant PBS service: how do you separate client data?

Datastore-Per-Client vs Shared Datastores

PBS supports namespaces within datastores, which might tempt you into a shared-datastore model. Resist that temptation for production MSP deployments.

Separate datastores give you clean boundaries for everything that matters: billing, access control, garbage collection, and client offboarding. When a client leaves, you delete their datastore. No surgical namespace removal. No risk of touching another client's data.

User and Permission Model

PBS uses realms to separate authentication domains. For each client, create a dedicated user in the pbs realm and issue an API token scoped to their datastore.

The permission model supports granular roles:

For most clients, assign DatastoreBackup and DatastoreReader. This lets them push backups and restore, but not delete snapshots or modify datastore settings. You keep control of retention policies and pruning.

Network Topology

Each client needs a secure path to your PBS infrastructure. Two common options:

WireGuard tunnel per client. Each client gets a dedicated tunnel with its own subnet. Clean isolation, easy firewall rules, per-client bandwidth monitoring. More tunnels to manage, but WireGuard is lightweight and stable.

Shared VPN concentrator. All clients connect through a single VPN endpoint with ACLs enforcing datastore access. Simpler to manage at scale, but you lose per-client network isolation.

For most MSPs, WireGuard tunnels win. The overhead is minimal and the isolation is worth it.

Onboarding a New Client

Client onboarding should take under 15 minutes. Here's the repeatable process.

Step 1: Create the Datastore

# Create the backing directory
mkdir -p /mnt/backup-storage/clients/acme-corp

# Create the datastore via CLI
proxmox-backup-manager datastore create acme-corp \
    --path /mnt/backup-storage/clients/acme-corp \
    --gc-schedule "Sat 03:00"

Naming convention matters. Use lowercase slugs that match your client identifiers: acme-corp, contoso-ltd, client-042. This makes scripting and billing integration straightforward.

Step 2: Create User and API Token

# Create a dedicated user
proxmox-backup-manager user create acme@pbs \
    --comment "Acme Corp backup account"

# Generate an API token
proxmox-backup-manager user generate-token acme@pbs client-token
# Output: acme@pbs!client-token = <secret-value>

The token format is user@realm!tokenname. Hand the client their token value and your PBS server's fingerprint. They never need the PBS web UI.

Step 3: Set Permissions

# Grant backup + read access on their datastore only
proxmox-backup-manager acl update /datastore/acme-corp \
    --auth-id acme@pbs!client-token \
    --role DatastoreBackup

proxmox-backup-manager acl update /datastore/acme-corp \
    --auth-id acme@pbs!client-token \
    --role DatastoreReader

Step 4: Client-Side Encryption Key

The client runs this on their own machine. You never see the key.

# Generate the encryption key
proxmox-backup-client key create --kdf scrypt /etc/pbs-encryption-key.json

# Back up the key separately (paper, password manager, etc.)

Stress this to every client: if they lose the encryption key, their backups are unrecoverable. You cannot help them. Include this in your onboarding documentation and service agreement.

Step 5: First Backup Job

# Configure environment
export PBS_REPOSITORY="acme@pbs!client-token@your-pbs-server:acme-corp"
export PBS_ENCRYPTION_PASSWORD="<passphrase>"

# Run a test backup
proxmox-backup-client backup root.pxar:/ \
    --keyfile /etc/pbs-encryption-key.json \
    --exclude /proc --exclude /sys --exclude /dev --exclude /run

For Proxmox VE clients, configure the backup job through the PVE web UI instead, pointing at the remote PBS storage.

Step 6: Monitoring

Set up monitoring and alerting for every client from day one. Check that backups complete, verify chunk integrity weekly, and alert on missed schedules. The PBS API exposes task logs and datastore status, making it easy to integrate with your existing monitoring stack.

Billing and Metering

PBS exposes datastore metrics through its API. Used space, dedup ratio, snapshot count, and last backup time are all queryable. This feeds directly into automated billing.

# Get datastore status for billing
curl -s -k -H "Authorization: PBSAPIToken=billing@pbs!metrics:$(cat /etc/pbs-billing-token)" \
    "https://localhost:8007/api2/json/admin/datastore/acme-corp/status" \
    | jq '{used: .data.used, total: .data.total, dedup: .data."deduplication-factor"}'

A simple billing script loops through all datastores, pulls usage, and generates invoices. Bill per TB of used space (post-dedup) or per TB of source data (pre-dedup), whichever model works for your pricing.

For a detailed breakdown of backup storage costs, the cost comparison guide covers how PBS stacks up against commercial alternatives.

Scaling Considerations

A single PBS node handles dozens of clients before you hit limits. But planning ahead keeps growth smooth.

When to Add Nodes

One PBS node per 50-80 client datastores is a reasonable target, depending on concurrent backup load and disk throughput. When you notice GC cycles taking hours or backup windows consistently running late, it's time for another node.

Geo-Redundant Replication

Use PBS sync jobs to replicate client data to a secondary site. Sync jobs support --encrypted-only mode, which means the target PBS node receives only encrypted chunks. Even your DR site can't read client data.

This is a strong selling point: geo-redundant, zero-knowledge backups across multiple datacenters.

Storage Tiering

Not all backups need fast storage. A practical approach:

• NVMe/SSD for the most recent 7 days of snapshots (fast restores)
• HDD arrays for monthly and yearly retention (cost-effective archive)

PBS doesn't manage tiering natively, but you can create separate datastores on different storage pools and use sync jobs to move older snapshots to the archive tier.

Retention Policies

Let clients choose their retention within your minimums. A good baseline for pruning configuration:

proxmox-backup-manager datastore update acme-corp \
    --keep-last 3 \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6

Enforce minimums in your service agreement (e.g., at least 7 daily snapshots). Clients who want longer retention pay for the extra storage.

Security and Compliance

Security sells. Especially to clients who've been burned before.

Zero-Knowledge Architecture

With client-side encryption, your PBS infrastructure stores encrypted chunks. You don't hold keys. You can't access content. This is genuine zero-knowledge hosting, not a marketing claim.

For the full technical details on how PBS encryption works, see the client-side encryption deep dive.

GDPR and Data Residency

If you serve EU clients, data residency matters. Keep PBS nodes in EU datacenters. Document which client data lives where. When a client exercises their right to deletion, you delete their datastore and all associated chunks. Clean, auditable, done.

Audit Logging

PBS logs every API call with timestamps and user identity. Who accessed what datastore, when they ran backups, what they restored. These logs feed into compliance reports and incident investigation.

Immutability as a Selling Point

Immutable backups are a top concern for clients worried about ransomware. PBS doesn't have a built-in immutable snapshot flag. Immutability comes from architecture: separate credentials per client, no delete permissions on backup tokens, network isolation between client environments and PBS storage. When a client's network gets compromised, the attacker can't reach or delete the offsite backups because the backup credentials only allow pushing new data, not removing existing snapshots.

This architectural approach is actually stronger than a simple "immutable" checkbox because it eliminates the attack surface entirely rather than relying on a single software flag.

Getting Started

Two paths to launch your MSP backup service:

Self-host PBS for full control over hardware, pricing, and architecture. Follow the datastore setup guide to get your first node running. Good for MSPs who already manage infrastructure and want maximum margins.

Use remote-backups.com as your managed offsite target. We handle storage, redundancy, and infrastructure. You handle clients. Works well as a second copy in a 3-2-1 strategy where you run local PBS and replicate encrypted to us.

For MSPs who want their own brand on the service, the white-label reseller program gives you branded portals, custom pricing, and dedicated support. Your clients see your brand, not ours.

Wrapping Up

Proxmox Backup Server gives MSPs something rare in the backup market: a technically strong platform with no per-seat licensing traps. Separate datastores per client, scoped API tokens, client-side encryption, and built-in metrics cover the hard parts of multi-tenancy. The rest is process and automation, which is exactly what good MSPs excel at.