Proxmox Backup Server 2.2 available

[Jesus Blanco]

Finaly I had to downgrade to 2.1-8 because I can't upgrade my PVE nodes to 7.2 now. There is this bug with backing up large files:

https://forum.proxmox.com/threads/p...2-vm-freeze-if-backing-up-large-disks.109272/

And I can't asume that risk.

 

[JSEHV]

FYI, the documentation also includes a screenshot of how a datastore content looks with namespaces:

In the documentation is a typo, not sure where to report, so put it here.
Just to help out to make the namespace documentation a little better.

https://pbs.proxmox.com/docs/terminology.html?highlight=namesapce

As you can see, namesapce should be namespace in that part.

 

[hanru]

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?

 

[t.lamprecht]

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.

 

[t.lamprecht]

In the documentation is a typo, not sure where to report, so put it here.
Just to help out to make the namespace documentation a little better.

https://pbs.proxmox.com/docs/terminology.html?highlight=namesapce

As you can see, namesapce should be namespace in that part.

Thanks for the report, fixed in git with a few other typos https://git.proxmox.com/?p=proxmox-...ff;h=e87e4499fdcfe4c9862a7cd6f5bbb00b61a95d5e

 

[Dunuin]

Thanks for the report, fixed in git with a few other typos https://git.proxmox.com/?p=proxmox-...ff;h=e87e4499fdcfe4c9862a7cd6f5bbb00b61a95d5e

You forgot that one: https://forum.proxmox.com/threads/proxmox-backup-server-2-2-available.109724/post-472106

 

[t.lamprecht]

You forgot that one: https://forum.proxmox.com/threads/proxmox-backup-server-2-2-available.109724/post-472106

Can you really forget what you didn't know? But yeah, missed your post in the noise and the codespell tool is pretty dumb, at least it has almost never a false positive, so there's that.. Anyhow, fixed now too, thanks for the reminder!
https://git.proxmox.com/?p=proxmox-...9;hp=e87e4499fdcfe4c9862a7cd6f5bbb00b61a95d5e

 

[Taledo]

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.

 

[Stoiko Ivanov]

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

 

[Taledo]

intel_iommu=off did the trick. Thanks!

 

[Robstarusa]

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?

 

[Dunuin]

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.

 

[fabian]

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.

 

[Dunuin]

prune jobs with namespace support are on the roadmap

Looks lke that it got added meanwhile.

 

[fabian]

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)

 

[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.

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?

 

[Dunuin]

Should be similar to a GC as it mostly should access metadata and not data.

 

[fabian]

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).

 

[tlex]

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.

 

[Dunuin]

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.