For a bit of background, I initially stood up my PBS install on one of my PVE hosts and used root@pam to get it up and running with minimal fuss over accounts et. al. Now, I'm going back through and looking to figure out what might be the 'official' approach to migrate that configuration over to a dedicated backup-only account (while adding a second PBS install to sync to, testing read only access to that store, etc)... preferably without re-creating the storage definition and updating the pile of backup jobs using it, rebuilding the PBS datastore, etc. Down the line, even just the need to rotate that password occasionally comes to mind as something that might cause some issues in a production deployment.
Looking through the PVE UI (6.2-10), there doesn't seem to be a good way to edit the user/password used to communicate with PBS, and the PBS UI doesn't appear to give a password force-change/reset option for its integrated user management (there's a hint to changing the password via the CLI in the docs, at least). I did find the password stashed in PVE's
I then ran into issues with the owner of the backup groups in PBS being the old user, even when all snapshots in a VM's backups had been manually forgotten via the PBS UI (since the vm/ID/owner file persists in the datastore even after all the related backups for the group have been forgotten and a GC pass run) and the Backup Group listing for it is hidden in the UI, so there's nothing there to hint at the issue. Looking at the resulting ownership from a sync job (backup@pam) run on a secondary PBS instance, and a quick test to verify it, it looks like even just using a sync job to migrate to a new PBS server while retaining the old backups won't work out, as PVE won't write new backups for those Backup Groups from a different account (they do at least work to restore from, as long as the account used to access them has DataStoreReader permissions).
Since the only mention of backup ownership so far in the PBS docs is just about permissions for DataStoreBackup/DatastorePowerUser, I suspect the only way to switch that ownership is a manual change in the owner tag file per backup group, and a quick test of changing the owner tag on a vm's backup group showed that it appears to work at least. I still took the opportunity to re-build the datastore on its own zfs mount for easier tracking of size, though, since I'd run into the above issues and wanted a clean start (backups is the last place to toy with a risk of obscure problems later, even though I'm 99% sure I've found a fix for everything I tripped over).
Since ownership is so tightly woven into access on the backup groups, changing the username via the PVE UI seems like it would lead to more unanticipated issues than it would solve (as shown by my adventures), so only having it work via the manual process I figured out there isn't too big of a deal, I suspect (and "recreate the storage entry" is a reasonable enough requirement for the average, sane, user). The ability to change the password in the PBS UI might be useful, though, and the ability to update it in PVE would go hand in hand with that. The ability to change ownership of a backup group in the PBS UI, though, almost seems like an essential capability in the long run, especially when looking at things like migrating between backup servers (particularly when spinning everything back up out of an off-site PBS instance that's been pull-syncing from the live primary, if the primary site as a whole goes down). It might also be useful to be able to bulk-change multiple (and bulk-forget multiple snapshots). Retaining the listing for all known backup groups (and the ability to remove those completely, ownership and all) in the UI may help with such issues too.
The only other UI oddity I've found, completely unrelated to the saga above, is that "overlapping" naming, like VM IDs 100 and 10003 both get caught in PVE's "Filter VMID" backup list feature (it seems to just search for
For a beta, even with self induced issues in what I was doing, though... nothing *really* broke (and all of what did break was fixable with a little poking around on command line), it's been stable as a rock so far, and it's *way* better than the hacky dependency on vzdump hook scripts and rsync that I rigged together to distribute backups between a couple nodes in the past (let alone the space savings from proper dedup).
Thanks for (a very good start of) another great product!
Looking through the PVE UI (6.2-10), there doesn't seem to be a good way to edit the user/password used to communicate with PBS, and the PBS UI doesn't appear to give a password force-change/reset option for its integrated user management (there's a hint to changing the password via the CLI in the docs, at least). I did find the password stashed in PVE's
/etc/pve/priv/storage/<storage-name>.pw and the username where it'd be expected in /etc/pve/storage.cfg. Disabling the storage, updating storage.cfg and the .pw file there, and re-enabling the storage worked fine as a by-hand method for it on the PVE end.I then ran into issues with the owner of the backup groups in PBS being the old user, even when all snapshots in a VM's backups had been manually forgotten via the PBS UI (since the vm/ID/owner file persists in the datastore even after all the related backups for the group have been forgotten and a GC pass run) and the Backup Group listing for it is hidden in the UI, so there's nothing there to hint at the issue. Looking at the resulting ownership from a sync job (backup@pam) run on a secondary PBS instance, and a quick test to verify it, it looks like even just using a sync job to migrate to a new PBS server while retaining the old backups won't work out, as PVE won't write new backups for those Backup Groups from a different account (they do at least work to restore from, as long as the account used to access them has DataStoreReader permissions).
Code:
ERROR: VM 5201 qmp command 'backup' failed - backup connect failed: command error: backup owner check failed (pve-restoreonly@pbs != backup@pam)
ERROR: Backup of VM 5201 failed - VM 5201 qmp command 'backup' failed - backup connect failed: command error: backup owner check failed (pve-restoreonly@pbs != backup@pam)Since the only mention of backup ownership so far in the PBS docs is just about permissions for DataStoreBackup/DatastorePowerUser, I suspect the only way to switch that ownership is a manual change in the owner tag file per backup group, and a quick test of changing the owner tag on a vm's backup group showed that it appears to work at least. I still took the opportunity to re-build the datastore on its own zfs mount for easier tracking of size, though, since I'd run into the above issues and wanted a clean start (backups is the last place to toy with a risk of obscure problems later, even though I'm 99% sure I've found a fix for everything I tripped over).
Since ownership is so tightly woven into access on the backup groups, changing the username via the PVE UI seems like it would lead to more unanticipated issues than it would solve (as shown by my adventures), so only having it work via the manual process I figured out there isn't too big of a deal, I suspect (and "recreate the storage entry" is a reasonable enough requirement for the average, sane, user). The ability to change the password in the PBS UI might be useful, though, and the ability to update it in PVE would go hand in hand with that. The ability to change ownership of a backup group in the PBS UI, though, almost seems like an essential capability in the long run, especially when looking at things like migrating between backup servers (particularly when spinning everything back up out of an off-site PBS instance that's been pull-syncing from the live primary, if the primary site as a whole goes down). It might also be useful to be able to bulk-change multiple (and bulk-forget multiple snapshots). Retaining the listing for all known backup groups (and the ability to remove those completely, ownership and all) in the UI may help with such issues too.
The only other UI oddity I've found, completely unrelated to the saga above, is that "overlapping" naming, like VM IDs 100 and 10003 both get caught in PVE's "Filter VMID" backup list feature (it seems to just search for
vm/100 rather than vm/100/).For a beta, even with self induced issues in what I was doing, though... nothing *really* broke (and all of what did break was fixable with a little poking around on command line), it's been stable as a rock so far, and it's *way* better than the hacky dependency on vzdump hook scripts and rsync that I rigged together to distribute backups between a couple nodes in the past (let alone the space savings from proper dedup).
Thanks for (a very good start of) another great product!
