You don’t have just one Proxmox VE host, you have several — maybe a cluster, maybe two sites, maybe a test host and a production host. All of them should send their backups to the same PBS datastore. That works fine — you just need to watch a few things so the backups don’t trip over each other.
Option 1: All hosts equal, shared datastore
The simplest setup when all hosts back up the same pool of VMs:
- All PVE hosts use the same PBS storage entry (same server URL, same user, same datastore).
- VM IDs are unique across a cluster anyway.
- Snapshots from all hosts land under
vm/<vmid>/<timestamp>in the datastore.
Careful with standalone hosts and overlapping VM IDs: if host A has a VM with ID 100 and host B also has a VM with ID 100 (different setup), both would land under vm/100/... — the snapshots don’t overwrite each other, but the list gets confusing, and the restore view shows VMs from both hosts mixed together.
The fix: namespaces.
Option 2: Namespaces for clean separation
PBS namespaces are like virtual sub-datastores inside a datastore. You can create one namespace per host (or per customer, per use case) and isolate the backups there.
Example:
Datastore "12345"
├── (root namespace) <- cluster backups
├── ns/host-zuhause <- standalone host at your place
└── ns/test-environment <- test cluster
VM IDs can overlap between namespaces — the snapshots stay separate.
Creating a namespace
In the PBS GUI:
- Datastore → <your-datastore> → Permissions or Content (depends on the PBS version).
- Add Namespace.
- Pick a name, e.g.
host-zuhause.
Using the namespace in the PVE storage
When adding or editing the PBS storage in PVE:
- Namespace field: enter
host-zuhause.
All backups from that PVE host now land in the host-zuhause namespace instead of the root.
Option 3: Separate users for separate hosts
If you also want to separate permissions (say a colleague should only see his host’s datastore):
- Configuration → Access Control → Users → Add.
- Create a new user per host, e.g.
host-zuhause@pbs. - Grant permissions on the datastore (or a specific namespace).
- Use that user in the PVE storage of the respective host.
That way each host can only write into its own area.
Permission model per namespace
PBS supports fine-grained permissions at the namespace level:
Datastore.Backup— may write new backups and read, restore and delete its own backup groups.Datastore.Modify— may delete and prune all backups.Datastore.Read— may read backups (for restore).Datastore.Verify— may run verify jobs.
Best practice for an IT service provider setup:
- One PBS user per customer host.
- Its own namespace in the datastore.
- The user only gets
Datastore.BackupandDatastore.Readon its namespace — no Modify, so no touching anyone else’s backups and no namespace-wide prune. The owner can still delete his own backup groups, though — real deletion protection only comes from a sync to a second PBS or the protected flag. - Prune and GC run datastore-wide as admin.
Scheduling in a multi-host setup
If several hosts back up to the same datastore:
- Don’t run backups in parallel: five hosts pushing 100 GB at once will bring the connection to its knees.
- Stagger them at night: host 1 at 02:00, host 2 at 02:30, host 3 at 03:00.
- Bandwidth limits per host: if things have to run in parallel, cap each host to a fraction of the connection.
Frequently asked questions
Do I need namespaces if I only have one host? No. With a single host, the root namespace is enough.
What if two hosts use the same VM ID?
Without namespaces: both write into vm/100/... — snapshots get sorted in chronologically, mixed. The restore view shows a combined list, which is usually confusing. With namespaces: give each host its own namespace and the snapshots stay cleanly separated.
Cluster with shared VM IDs — do I need namespaces there?
No. In a Proxmox cluster, VM IDs are unique anyway — all hosts see the same VM pool. Backup snapshots get stored correctly under vm/<vmid>/....
Can one backup job write to two datastores in parallel? Yes, indirectly. You can create two backup jobs, each with a different storage target. Or you use sync jobs: the backup runs to the primary datastore, a sync pulls to the secondary datastore.
Does every host need its own API token? Recommended, yes. That way you can revoke individual hosts without affecting the others.
Which user ID do I use in the PVE storage?
Either the user login (e.g. 12345@pbs) with a password, or an API token (12345@pbs!hostname-token). Tokens are safer and revocable, so we recommend those.
Can I restructure namespaces later? Yes, but you have to move snapshots between namespaces manually or back up fresh. Existing snapshots don’t change their namespace automatically.
What’s next
First login to the Proxmox Backup Server — what you see in the GUI
After ordering, the login mail arrives. Here's an overview of the most important areas of the PBS GUI — datastore, sync, tape, users, notifications.
Setting up the datastore as a backup target in Proxmox VE
Add your xaweho PBS datastore to your Proxmox VE in a few clicks — via GUI or CLI, with fingerprint and login.
Creating an encryption key for PBS and storing it safely
Enable client-side encryption with AES-256-GCM. Generate the key, store it safely and register it in the PBS storage.
Running your first backup to the PBS — step by step
A manual test backup of a single VM to check that the datastore is connected correctly and everything works.