Using Namespaces in Proxmox Backup Server

A Proxmox Backup Server namespace is a folder-like subdivision inside a datastore. Snapshots in different namespaces are kept apart for listing, permissions, retention, and sync, while still sharing one deduplicated chunk store underneath. Namespaces arrived in PBS 2.2 and are the right tool whenever one datastore holds backups from more than one place.

Why use them

• Several clusters, one datastore. Two clusters can both have a VM with ID 100. Without namespaces their backups would collide; with cluster-a and cluster-b namespaces they cannot.
• MSPs and consultants. Give each client a namespace and a token scoped to it. Clients see only their own snapshots, and you can set different retention per client.
• Production vs. staging, or sites within one company — anything you want to prune, verify, or report on separately.
• Sync targets. A sync job can land an entire remote datastore inside one namespace, so a hosted PBS can hold offsite copies from many sources without mixing them.

Namespaces nest up to eight levels deep (for example clients/acme/site-tampa) and use plain ASCII names. Deduplication is datastore-wide, so identical chunks are stored once no matter how many namespaces reference them.

Targeting a namespace from Proxmox VE

When you add the PBS storage in Proxmox VE (Datacenter → Storage → Add → Proxmox Backup Server) there is a Namespace field. Enter the namespace path and every backup job that uses that storage writes there. Want two clusters in two namespaces? Add the storage on each cluster with a different namespace value — same server, same datastore, same token if you like.

Permissions

PBS access control paths include the namespace: /datastore/<store>/<namespace>. Granting a token DatastoreBackup on /datastore/main/clients/acme lets it back up and restore inside acme only. This is how an MSP can hand out per-client credentials safely.

Retention and verification per namespace

Prune jobs and verification jobs can be scoped to a namespace (and optionally its children, via max depth). That is what lets you keep 30 days for one client and a year for another inside the same datastore. Garbage collection, which reclaims space, runs for the datastore as a whole.

Namespaces and sync jobs

A sync job specifies a source namespace and a target namespace, plus a max depth. Common patterns:

• Push your whole on-prem datastore into offsite/hq on the hosted server.
• Pull only clients/acme from a hosted datastore back to a client-owned PBS.

See Push vs. Pull Sync Jobs in Proxmox Backup Server for the direction and permission details.

Namespaces on Pay As You Grow

Pay As You Grow does not include the PBS web interface, so namespaces are created by OneColo's admins. Open a support ticket with:

• the namespace names (and nesting) you want;
• whether you need a separate token per namespace, and which existing token should keep access to what;
• any retention you want applied per namespace.

Once created, point each Proxmox VE storage entry or sync job at its namespace and you are done. On a reserved instance you can manage namespaces yourself under Datastore → Content → Add Namespace.

Gotchas

• Moving existing snapshots between namespaces is not a built-in operation; the practical route is a sync job from the old namespace to the new one, then pruning the old.
• Deleting a namespace removes its snapshot indexes; the space comes back after the next garbage collection.
• Keep names stable — Proxmox VE storage entries, sync jobs, and token ACLs all reference them by path.

New to hosted PBS? Start with adding the storage to Proxmox VE, then request your namespaces.