Proxmox Backup Server 2.2 available

A datastore can host many backups as long as the underlying storage is big enough and provides the performance required for one's use case. But, without any hierarchy or separation its easy to run into naming conflicts, especially when using the same datastore for multiple Proxmox VE instances or multiple users.

The backup namespace hierarchy allows you to clearly separate different users or backup sources in general, avoiding naming conflicts and providing well-organized backup content view.

So the main purpose of namespace is to avoid naming conflicts. Does namespace offer other benefits, such as better de-duplication than separate datastores?
 
So the main purpose of namespace is to avoid naming conflicts. Does namespace offer other benefits, such as better de-duplication than separate datastores?
Sure, the main purpose of namespaces is to avoid naming conflicts while staying in a single deduplication domain (= a datastore).
This also allows more fine-grained access control to what an, e.g., API token can work with without the need for separate datastores.
 
  • Like
Reactions: hanru
Hello all,

I've tried upgrading a R320 to PBS 2.2, but it wouldn't boot on kernel 5.15. Switched back to 5.13, and it is now working as intended.

The errors were showing up as DMAR errors, but as I don't have logs, I cannot give you precise feedback right now, but I can reproduce if it can help.

This is more of a fyi than anything else.
 
The errors were showing up as DMAR errors
check-out the known-issues page from the PVE 7.2 release (it shares the kernel with PBS 2.2)
I'd assume that either:
* updating the BIOS and all firmware of the server
* adding `iommu=pt` to the kernel commandline
* adding `intel_iommu=off` to the kernel commandline
(in order in how I'd try them)

should resolve the issue:
https://pve.proxmox.com/wiki/Roadmap#7.2-known-issues
 
  • Like
Reactions: Taledo
to expand on what Thomas already posted - you obviously need to point your clients (including PVE) at the namespace. to actually "move" (copy) the backup groups and snapshots, you can use a sync job (with the remote pointing to the same PBS instance) or a one-off proxmox-backup-manager pull. when moving from datastore A root namespace to datastore A namespace foo, only the metadata (manifest and indices and so on) will be copied, the chunks will be re-used. when moving from datastore A to datastore B the chunks that are not already contained in B will of course be copied as well, no matter whether namespaces are involved at either side ;).
I have a question on this:

I have 2.9T of backups I want to move to a namespace, but only 1.7T free.
Is this going to work, or does a pull "copy" all the data in which case I need more free space?
 
I have a question on this:

I have 2.9T of backups I want to move to a namespace, but only 1.7T free.
Is this going to work, or does a pull "copy" all the data in which case I need more free space?
When doing a sync within the same datastore between different namespaces this won't consume additional storge as no chunk needs to be saves twice because of deduplication. You basically just got multiple index files (which won't be more then a few MB/GB) pointing to the same chunks.
 
  • Like
Reactions: flames
exactly like @Dunuin says - within a datastore, no chunk will be saved twice even if referenced by multiple groups/snapshots, even in multiple namespaces (that's one of the points of namespaces after all ;)). when crossing a datastore boundary, you need twice the space at least temporarily, as datastores are completely independent.
 
  • Like
Reactions: flames
Looks lke that it got added meanwhile. :)
yes. existing jobs from datastore.cfg should be automatically moved to the new config file on upgrade, and it's possible to define multiple jobs per datastore now, including with optional restrictions to a namespace (subtree) :)
 
  • Like
Reactions: Neobin
exactly like @Dunuin says - within a datastore, no chunk will be saved twice even if referenced by multiple groups/snapshots, even in multiple namespaces (that's one of the points of namespaces after all ;)). when crossing a datastore boundary, you need twice the space at least temporarily, as datastores are completely independent.
Thanks and forgive me my ignorance, what is about the time to sync from root namespace to namspace xyz on same datastore? is it comparable to a verify job (slow), or like a garbage collection (fast), or something in between or out of those two comparisons? i am asking, because my root namsepace has ~58TiB used and is zfs raid10 with 18TB HDDs with two NVME special devices. could take a while, not?
 
a proper sync will be somewhere in the middle, similar to a GC (it will iterate over all the snapshots and chunks twice, but only the metadata will be written, the actual data will just be referenced once more).
 
  • Like
Reactions: flames
Sorry for the dumb question but I'm running PBS 2.1.1. Is there any detailed steps somewhere on how to upgrade to 2.2 ? I couldn't find anything.
 
Its a minor upgrade, so you usually you can upgrade your PBS just thorugh the "GUI: Administration -> Updates -> Refresh + Upgrade" or using the console with apt update && apt full-upgrade.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!