One PBS Datastore for Many Proxmox Clusters

You run three Proxmox clusters and a couple of standalone nodes. The obvious move is one Proxmox Backup Server datastore per cluster, so everything stays tidy. Then you look at the disk usage and notice you are storing the same Debian base image four times over, once in each datastore, because deduplication never crosses a datastore boundary. Namespaces let you fold every cluster and node into a single datastore where the dedup engine sees all of it at once.

This is the single-operator counterpart to our multi-tenant namespaces guide. That post covers isolating separate clients with ACLs. This one covers consolidating infrastructure you already own into one storage pool for maximum dedup.

Why One Datastore per Cluster Wastes Space

Proxmox Backup Server deduplicates at the datastore level. Every chunk is content-addressed by its SHA-256 hash, and identical chunks are stored exactly once, but only within a single datastore. The moment you split your fleet across separate datastores, that shared chunk pile splits with it. Our chunk store deep dive walks through the on-disk mechanics if you want the full picture.

Picture a typical fleet. Cluster A runs 20 VMs on Debian 12. Cluster B runs 15 VMs, also Debian 12, with a similar package set. A pair of standalone nodes run the same base image for edge workloads. Across all of it, the kernel, libc, systemd, and most package metadata are byte-for-byte identical.

With one datastore per cluster, those identical chunks live in every datastore independently. The base OS gets stored three or four times. With a single consolidated datastore, the first backup uploads those chunks once and every other cluster references them at zero additional cost.

Namespaces Give You Structure Without Splitting Storage

A namespace is a hierarchical path inside a datastore. It groups backup snapshots under a label without creating a separate chunk store. Think of it as a folder for organization, while the heavy chunk data stays in one shared pile underneath.

For a single-operator fleet, the natural layout maps namespaces to physical topology:

# One datastore, one namespace per cluster and standalone node
proxmox-backup-manager namespace create fleet cluster-prod
proxmox-backup-manager namespace create fleet cluster-staging
proxmox-backup-manager namespace create fleet cluster-dev

# Standalone nodes get their own top-level namespaces
proxmox-backup-manager namespace create fleet edge-node-01
proxmox-backup-manager namespace create fleet edge-node-02

# Nest by node inside a cluster if you want finer grouping
proxmox-backup-manager namespace create fleet cluster-prod/pve-01
proxmox-backup-manager namespace create fleet cluster-prod/pve-02

Keep nesting to two levels at most. A flat cluster-prod, cluster-staging, edge-node-01 scheme is easier to script against than a deep tree. List what you have with proxmox-backup-manager namespace list fleet.

Pointing Each Cluster at Its Namespace

Proxmox VE 7.2 and later accepts a namespace when you add PBS storage. Each cluster gets one storage entry that targets its assigned namespace. Backup jobs on that cluster land in the right place with no per-VM configuration.

# Run on cluster-prod
pvesm add pbs fleet-backup \
    --server pbs.example.com \
    --datastore fleet \
    --namespace cluster-prod \
    --username backup@pbs!fleet-token \
    --password <token-secret> \
    --fingerprint 64:d3:ff:3a:50:38:...

# Run on cluster-staging (same datastore, different namespace)
pvesm add pbs fleet-backup \
    --server pbs.example.com \
    --datastore fleet \
    --namespace cluster-staging \
    --username backup@pbs!fleet-token \
    --password <token-secret> \
    --fingerprint 64:d3:ff:3a:50:38:...

In the PVE web UI the same field lives under Datacenter > Storage > Add > Proxmox Backup Server, in the Namespace box. Since this is your own infrastructure rather than isolated tenants, a single API token with datastore-wide access is fine. If you do want each cluster locked to its own namespace, scope the token per namespace exactly as the multi-tenant guide describes.

Consolidated vs Split: The Tradeoffs

Folding everything into one datastore is the right default for a single operator, but it is not free of tradeoffs. Here is the honest comparison.

The operational simplification is real. One garbage collection schedule, one verify job, one datastore to size and monitor. The one thing you give up is isolation of the underlying storage: every cluster's snapshots share the same chunk pile, so a datastore-level problem touches everything at once.

Retention Still Works Per Namespace

Consolidation does not force a single retention policy on the whole fleet. Pruning is namespace-scoped, so your production cluster can keep long history while dev keeps almost nothing.

# Production: keep a long tail
proxmox-backup-manager prune-job create prod-prune \
    --store fleet \
    --ns cluster-prod \
    --keep-daily 14 \
    --keep-weekly 8 \
    --keep-monthly 12 \
    --schedule "daily"

# Dev: keep almost nothing
proxmox-backup-manager prune-job create dev-prune \
    --store fleet \
    --ns cluster-dev \
    --keep-last 2 \
    --keep-daily 3 \
    --schedule "daily"

Pruning a namespace only removes snapshots and their index files within that namespace. Disk space does not come back until garbage collection runs, and GC is datastore-wide. A chunk that any namespace still references stays on disk. The mechanics are the same as any PBS setup; our pruning and garbage collection guide covers the scheduling tradeoffs.

One Verify Job, One Sync Job

The same consolidation applies to integrity checks and offsite replication. A single verify job covers every namespace, so you are not tracking one per cluster. And if you replicate offsite, a sync job can either mirror the whole datastore in one pass or target a specific namespace when you only want part of the fleet to leave the building.

# Mirror the entire consolidated datastore offsite
proxmox-backup-manager sync-job create fleet-offsite \
    --remote source-pbs \
    --remote-store fleet \
    --store offsite-fleet \
    --schedule "daily" \
    --remove-vanished true

# Or replicate only production offsite
proxmox-backup-manager sync-job create prod-offsite \
    --remote source-pbs \
    --remote-store fleet \
    --remote-ns cluster-prod \
    --store offsite-fleet \
    --ns cluster-prod \
    --schedule "daily"

Because the source is one deduplicated datastore, the offsite copy inherits the same dedup structure. You transfer each unique chunk once, not once per cluster. Our sync jobs guide has the full offsite setup.

When to Keep Datastores Separate

Consolidation is the right default, but not every fleet should collapse to one datastore. Keep a cluster on its own datastore when:

• You need failure isolation. One shared chunk store means one shared failure domain. If a cluster carries data you cannot afford to have caught up in a datastore-wide problem, give it its own storage.
• Backends genuinely differ. If one cluster's backups belong on fast NVMe and another's belong on cheap spinning disk, that is two datastores on two backends, not one.
• A single cluster dominates the store. If one cluster's pruning and GC patterns would dictate performance for everything else, isolate it.
• Compliance requires physical separation. Some standards want data on separate storage paths or devices. Namespaces share the underlying pile.

A hybrid works well. Consolidate the clusters that share OS images and retention needs into one dedup-friendly datastore, and split off the one or two that have genuinely different requirements. For sizing the consolidated store, the capacity planning guide walks through the buffer math.

Wrapping Up

If you run several Proxmox clusters and standalone nodes, one datastore per cluster quietly duplicates every shared chunk and multiplies your operational overhead. A single datastore with per-cluster namespaces keeps each cluster's snapshots organized and separately retained, while the deduplication engine treats the whole fleet as one pile. You store shared OS and package chunks once, manage one GC and one verify job, and still tune retention per cluster. Split a datastore off only when isolation, backend, or compliance genuinely demands it.