PBS 4.2 introduces a very useful new move feature for backup groups and namespaces. Being able to move backup groups between namespaces directly in PBS is a great improvement, especially for reorganizing datastores, cleaning up namespace structures, or consolidating backup layouts without having to re-upload or recreate backups.
However, the current default behavior appears risky: when the target backup group already exists, the GUI/API defaults to merging the source group into the existing target group.
This can be problematic in real-world PBS environments. Many installations use namespaces to separate different PVE clusters, hosts, customers, departments, or environments. In those setups, identical VMIDs or CTIDs are common and do not necessarily refer to the same guest. For example, vm/100 in namespace cluster-a may be a completely different virtual machine than vm/100 in namespace cluster-b.
If such groups are moved and merged by default, unrelated backup histories can be combined into one backup group. Even if PBS performs technical checks such as owner matching and non-overlapping snapshot timestamps, this does not guarantee that the backups belong to the same VM or CT from a semantic/admin perspective. The result could be confusing, hard to detect later, and potentially dangerous during restore operations.
The move feature itself is excellent and very welcome. The concern is mainly the default behavior and the lack of a safer conflict-handling workflow.
Possible improvements:
However, the current default behavior appears risky: when the target backup group already exists, the GUI/API defaults to merging the source group into the existing target group.
This can be problematic in real-world PBS environments. Many installations use namespaces to separate different PVE clusters, hosts, customers, departments, or environments. In those setups, identical VMIDs or CTIDs are common and do not necessarily refer to the same guest. For example, vm/100 in namespace cluster-a may be a completely different virtual machine than vm/100 in namespace cluster-b.
If such groups are moved and merged by default, unrelated backup histories can be combined into one backup group. Even if PBS performs technical checks such as owner matching and non-overlapping snapshot timestamps, this does not guarantee that the backups belong to the same VM or CT from a semantic/admin perspective. The result could be confusing, hard to detect later, and potentially dangerous during restore operations.
The move feature itself is excellent and very welcome. The concern is mainly the default behavior and the lack of a safer conflict-handling workflow.
Possible improvements:
- Change the GUI default to not merge existing target groups.
- If the target group already exists, require an explicit confirmation before merging.
- Offer a third option: move the backup group to a new/free VMID or CTID in the target namespace.
- Show a clear warning that identical VMIDs/CTIDs across namespaces may represent unrelated guests.
- Ideally, display source and target group details before confirming, such as namespace, group ID, owner, snapshot count, and time range.
- If the target group does not exist: move normally.
- If the target group exists: stop and ask the user what to do.
- Available choices:
- cancel
- merge explicitly
- choose another free ID
- enter a custom target ID
