How to Use a Single Proxmox Backup Server for Multiple Clusters Without Losing Order

When an infrastructure grows to have multiple Proxmox VE clusters and some independent nodes, it can be tempting to create a Proxmox Backup Server (PBS) datastore for each one. It’s straightforward to understand and provides some separation, but it also divides the deduplication domain. Backup namespaces enable a different architecture: organizing copies by cluster within the same datastore and sharing the chunk store over which deduplication operates.

PBS Keys with Multiple Clusters in 20 Seconds

• A datastore can receive backups from multiple Proxmox VE clusters.
• Namespaces logically separate backups without creating independent chunk stores.
• Deduplication can reuse identical chunks between backups stored in the same datastore.
• Retention policies can be limited per namespace.
• Consolidating everything also increases the failure domain, so using a single datastore isn’t always advisable.

This architecture is especially useful in organizations where production, pre-production, development, and other clusters run similar operating systems, templates, or applications. Proxmox defines namespaces precisely as a way to reutilize a single deduplication domain for different sources, while avoiding naming conflicts and enabling more granular access controls.

Why Multiple Datastores Might Reduce Deduplication

To understand this, first consider how Proxmox Backup Server actually stores data.

A datastore is not just a folder where PBS leaves complete VM files. It’s the logical unit where snapshots, indexes, and chunks containing data are stored.

PBS divides backed-up data into blocks and identifies them based on their content. Chunks use SHA-256, so identical content results in the same identifier. Indexes from different snapshots can then reference these same chunks.

Technical documentation describes the store structure as something like:

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

Chunks are located inside .chunks, while snapshots maintain references needed to reconstruct each backup.

This explains an important feature of PBS: backups are sent incrementally and deduplicated on the server, but each snapshot still represents a complete backup. There’s no need to restore a traditional chain of full plus incremental backups to get the corresponding state.

Consider an infrastructure with this distribution:

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

Many of these machines may have exactly the same kernels, libraries, packages, and OS files.

If each environment uses an independent datastore:

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

each maintains its own chunk store.

Alternatively, if you use:

datastore-fleet

and organize sources within it using namespaces:

prod
dev
pre
edge

the backups remain logically separated but are part of the same deduplication domain.

This does not guarantee huge savings in any infrastructure. It depends on how much identical content actually exists among loads. Databases, encrypted files, compressed data, or machines with very different content may offer much less reuse than a setup built from common images.

What Are Proxmox Backup Server Namespaces?

Namespaces were introduced precisely to organize multiple sources within a datastore.

They can be seen as a logical hierarchy for backups, although technically they should not be mistaken for 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

Different clusters having a VM 100 no longer causes conflicts because each backup belongs to a different namespace.

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

This allows for very detailed structures, such as:

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

Or:

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

While PBS allows up to eight levels, it’s often advisable to keep hierarchies short and easily recognizable, especially in managed infrastructure.

Connecting Each Proxmox VE Cluster to Its Namespace

The next step is configuring each Proxmox VE environment to send backups to the corresponding 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, PBS can be added as a storage backend with a specified namespace.

For example:

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

In another cluster, the same server and datastore could be configured with a different namespace:

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

From that point, backup jobs from both clusters end up in different logical spaces within the same datastore.

Also, it’s advisable to avoid reusing a single credential with full access just because all systems belong to the same organization. PBS allows applying permissions at the namespace level, so separating tokens and privileges reduces the impact of a compromised credential. The documentation explicitly mentions permissions at the namespace level.

Different Retention Policies Without Creating New Datastores

Sharing a datastore doesn’t mean all backups must be retained for the same duration.

PBS prune jobs can specify a namespace via the ns parameter, also limiting the scope of retention policies.

For production, you might retain:

14 daily
8 weekly
12 monthly

While 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’s important to distinguish between pruning and garbage collection (GC).

Pruning deletes snapshots based on retention rules. However, a chunk cannot physically disappear if still needed by another snapshot. Garbage collection later identifies unreferenced chunks and reclaims space.

In a consolidated architecture, this feature is especially important: a block used by production cannot be deleted just because the development backup that also used it has been removed.

A Single Datastore Simplifies Operations but Increases Failure Domain

Consolidation also offers operational advantages: it reduces the number of datastores to manage.

The last row is probably the most important.

Better deduplication should not be the sole design criterion for a backup platform.

If four clusters rely on the same datastore and that storage becomes unavailable, all four temporarily lose access to the backup repository. A serious storage problem has a broader impact.

Therefore, there are scenarios where maintaining separate datastores remains sensible.

A regulatory-compliant environment may require separation. Clusters needing different storage technologies or performance levels also justify separation. And especially critical infrastructure might benefit from an independent failure domain, even if it means sacrificing some deduplication.

There is also a scaling consideration. PBS documentation notes that a datastore can hold many backups as long as the underlying storage has sufficient capacity and performance. Consolidation does not eliminate IOPS, bandwidth, CPU, memory, or maintenance window requirements.

A Hybrid Architecture Is Often More Reasonable

You are not obliged to choose one extreme or another.

A company might use:

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

This way, similar systems share deduplication while workloads with different requirements remain separated.

And there’s still one more piece: a PBS datastore should not be confused with a comprehensive data protection strategy.

Proxmox Backup Server allows configuring remote servers and Sync Jobs to synchronize content between PBS instances. It also supports client-side encryption; Proxmox notes that this additional encryption is not enabled by default.

A more complete architecture could 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 optimizes storage use. Namespaces help organize data. Verification jobs check integrity, and synchronization to another PBS can add a secondary location. These are related issues but not interchangeable.

When to Use a Single Datastore with Namespaces

This approach is especially suitable when multiple clusters belong to the same organization, use similar operating systems and templates, and can reasonably share the same storage domain.

Sharing datastores remains preferable when:

• Physical or administrative isolation is required;
• Different storage or performance requirements exist;
• Regulations mandate data separation;
• A critical environment needs to reduce its dependency on others;
• The size of a load would excessively extend maintenance tasks for a shared datastore.

Hence, the right decision is not simply creating one datastore per cluster or consolidating everything into one.

PBS offers the tools to design a middle ground: datastores as storage and deduplication domains, namespaces for organizing sources and permissions, and retention policies tailored to each part of the infrastructure.

Frequently Asked Questions

Does PBS deduplicate backups from different Proxmox clusters?

It can reuse identical chunks when backups are stored in the same datastore. Namespaces allow separating sources without creating entirely independent deduplication domains.

Can each namespace have a different retention policy?

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

Is it always better to use a single datastore?

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

Are PBS backups incremental?

Data is sent incrementally, and PBS performs server-side deduplication. Still, each snapshot references all chunks necessary to represent a full backup.