One Proxmox Backup Server, Many Clusters: How Namespaces Keep Backups Organized

When your infrastructure grows to several Proxmox VE clusters plus a few standalone nodes, it’s tempting to give each one its own Proxmox Backup Server (PBS) datastore. That’s easy to reason about and gives you some separation, but it also splits the deduplication domain. Backup namespaces offer another layout: sort copies by cluster inside one datastore and share the chunk store that deduplication runs on.

PBS with multiple clusters in 20 seconds

• One datastore can take backups from several Proxmox VE clusters.
• Namespaces separate backups logically without creating separate chunk stores.
• Deduplication can reuse identical chunks across backups in the same datastore.
• Retention policies can be scoped per namespace.
• Consolidating everything also widens the failure domain, so a single datastore isn’t always the right call.

This layout pays off most when production, pre-production, development, and other clusters run similar operating systems, templates, or applications. Proxmox describes namespaces exactly as a way to reuse one deduplication domain across different sources, avoid naming clashes, and set more granular access controls.

Why multiple datastores can cut into deduplication

Start with how Proxmox Backup Server actually stores data.

A datastore isn’t just a folder where PBS drops whole VM files. It’s the logical unit that holds snapshots, indexes, and the chunks that contain the data.

PBS splits backed-up data into blocks and identifies them by their content. Chunks use SHA-256, so identical content produces the same identifier, and indexes from different snapshots can point at the same chunks.

The docs describe the store structure roughly like this:

/
├── .chunks/
├── vm/
├── ct/
└── host/

Chunks sit inside .chunks, and snapshots keep the references needed to rebuild each backup.

That explains an important PBS trait: backups go up incrementally and get deduplicated on the server, yet each snapshot still stands for a full backup. You don’t restore a traditional chain of full-plus-incremental backups to reach a given state.

Take an infrastructure laid out like this:

Production Cluster
 ├── 25 Debian VMs
 └── 10 Ubuntu VMs

Development Cluster
 ├── 15 Debian VMs
 └── 5 Ubuntu VMs

Pre-production Cluster
 └── 12 Debian VMs

Independent PVE Node
 └── 4 Debian VMs

A lot of these machines may share the exact same kernels, libraries, packages, and OS files.

If each environment uses its own datastore:

datastore-prod
datastore-dev
datastore-pre
datastore-edge

each keeps its own chunk store.

Use one instead:

datastore-fleet

and organize sources inside it with namespaces:

prod
dev
pre
edge

and the backups stay logically separate while living in the same deduplication domain.

This won’t deliver huge savings in every infrastructure. It depends on how much identical content actually exists across your workloads. Databases, encrypted files, compressed data, or machines with very different content may reuse far less than a fleet built from common images.

What are Proxmox Backup Server namespaces?

Namespaces were added specifically to organize multiple sources inside one datastore.

Think of them as a logical hierarchy for backups, though technically they aren’t independent datastores.

For example:

datastore: company

├── production
│   ├── vm/100
│   ├── vm/101
│   └── vm/102
│
├── development
│   ├── vm/100
│   └── vm/103
│
├── preproduction
│   └── vm/100
│
└── madrid-branch
    └── vm/200

Two clusters both having a VM 100 no longer collide, because each backup lives in a different namespace.

PBS also supports nested namespaces up to eight levels deep, counting the root as level one. Each level can hold backups of VMs, containers, hosts, and other namespaces.

That allows detailed structures like:

company
└── madrid
    ├── production
    └── development

Or:

infrastructure
├── cluster-pve-01
├── cluster-pve-02
├── cluster-pve-03
├── edge-node-01
└── edge-node-02

PBS allows eight levels, but short, recognizable hierarchies usually work better, especially in managed infrastructure.

Connecting each Proxmox VE cluster to its namespace

Next, point each Proxmox VE environment at the right namespace.

Conceptually it looks like this:

                 ┌── Production Cluster ──> namespace: prod
                 │
                 ├── Development Cluster ──> namespace: dev
                 │
PBS datastore ───┼── Testing Cluster ─────> namespace: test
                 │
                 └── Independent Node ──> namespace: edge

                     │
                     ▼

               Shared chunk store

From Proxmox VE, you can add PBS as a storage backend with a specific namespace.

For example:

pvesm add pbs backup-pbs 
    --server pbs.example.net 
    --datastore company 
    --namespace production 
    --username backup@pbs!cluster-prod 
    --password '' 
    --fingerprint ''

On another cluster, the same server and datastore can use a different namespace:

pvesm add pbs backup-pbs 
    --server pbs.example.net 
    --datastore company 
    --namespace development 
    --username backup@pbs!cluster-dev 
    --password '' 
    --fingerprint ''

From there, backup jobs from both clusters land in different logical spaces within the same datastore.

It’s also worth not reusing a single full-access credential just because everything belongs to the same organization. PBS can apply permissions at the namespace level, so separate tokens and privileges limit the blast radius of a compromised credential. The docs mention namespace-level permissions explicitly.

Different retention policies without new datastores

Sharing a datastore doesn’t force every backup to keep the same retention.

PBS prune jobs can target a namespace through the ns parameter, which also scopes the retention policy.

For production you might keep:

14 daily
8 weekly
12 monthly

For development, the policy could be:

last 2
3 daily

For example:

proxmox-backup-manager prune-job create prod-prune 
    --store company 
    --ns production 
    --keep-daily 14 
    --keep-weekly 8 
    --keep-monthly 12 
    --schedule "daily"

And:

proxmox-backup-manager prune-job create dev-prune 
    --store company 
    --ns development 
    --keep-last 2 
    --keep-daily 3 
    --schedule "daily"

Here it helps to separate pruning from garbage collection (GC).

Pruning removes snapshots according to the retention rules. But a chunk can’t physically disappear while another snapshot still needs it. Garbage collection later finds unreferenced chunks and frees the space.

In a consolidated setup this matters a lot: a block used by production can’t be deleted just because the development backup that also used it is gone.

A single datastore simplifies operations but widens the failure domain

Consolidation has operational upsides too: fewer datastores to manage.

Aspect	Cluster-specific datastore	Shared datastore + namespaces
Organization by cluster	Yes	Yes
Shared deduplication domain	No	Yes
Differentiated retention	Yes	Yes
ACL by environment	Yes	Yes, via namespaces
GC	Independent	Shared per datastore
Monitoring	Multiple datastores	Single main datastore
Failure domain	More isolated	More centralized

The last row is probably the most important.

Better deduplication shouldn’t be the only thing that shapes a backup platform.

If four clusters depend on the same datastore and that storage goes offline, all four lose access to the backup repository at once. A serious storage problem reaches further.

So there are cases where keeping datastores separate still makes sense.

A compliance-bound environment may require separation. Clusters that need different storage technologies or performance levels justify it too. And especially critical infrastructure can benefit from its own failure domain, even at the cost of some deduplication.

There’s a scaling angle as well. PBS docs note a datastore can hold many backups as long as the underlying storage has enough capacity and performance. Consolidation doesn’t erase the need for IOPS, bandwidth, CPU, memory, or maintenance windows.

A hybrid layout is often the sensible one

You don’t have to pick an extreme.

A company might run:

PBS
│
├── general-datastore
│   ├── namespace: development
│   ├── namespace: testing
│   ├── namespace: internal-services
│   └── namespace: edge
│
└── critical-datastore
    └── namespace: production

That way similar systems share deduplication while workloads with different needs stay apart.

And one more thing: a PBS datastore isn’t the same as a full data-protection strategy.

Proxmox Backup Server can set up remote servers and Sync Jobs to copy content between PBS instances. It also supports client-side encryption, which Proxmox notes isn’t on by default.

A fuller architecture might look like this:

Proxmox VE Cluster 1 ─┐
Proxmox VE Cluster 2 ─┼──> Main PBS ───> Remote PBS
Proxmox VE Cluster 3 ─┤       │
Independent Node ──────┘       │
                                     ├─ Namespaces
                                     ├─ Deduplication
                                     ├─ Pruning
                                     ├─ Verification
                                     └─ Garbage Collection

Deduplication saves storage. Namespaces organize the data. Verification jobs check integrity, and syncing to another PBS adds a second location. Related jobs, but not interchangeable.

When to use a single datastore with namespaces

This approach fits best when several clusters belong to the same organization, run similar operating systems and templates, and can reasonably share one storage domain.

Separate datastores stay preferable when:

• You need physical or administrative isolation;
• Storage or performance requirements differ;
• Regulations require data separation;
• A critical environment needs to depend less on the others;
• One workload’s size would stretch maintenance on a shared datastore too far.

So the right call isn’t simply one datastore per cluster or everything in one.

PBS gives you the pieces to build a middle path: datastores as storage and deduplication domains, namespaces to organize sources and permissions, and retention policies tuned to each part of the infrastructure.

Frequently Asked Questions

Does PBS deduplicate backups from different Proxmox clusters?

It can reuse identical chunks when the backups sit in the same datastore. Namespaces let you separate sources without creating entirely independent deduplication domains.

Can each namespace have a different retention policy?

Yes. Prune jobs can target a namespace with the ns parameter and set rules like keep-last, keep-daily, keep-weekly, keep-monthly, or keep-yearly.

Is a single datastore always better?

Not necessarily. Sharing a datastore improves deduplication and administrative simplicity but concentrates the failure domain. Separate datastores can be the better fit for performance, isolation, storage constraints, or compliance.

Are PBS backups incremental?

Data is sent incrementally, and PBS deduplicates on the server. Even so, each snapshot references all the chunks needed to represent a full backup.