Recommended Way to Convert Unencrypted Backup Job/Datastore to Encrypted Backup Job/Datastore?

Sep 1, 2022
438
167
48
41
Hello!

I've got a local PBS server, working great.

i was still learning when I set it up, and created unencrypted backups when I set up the job on the client-side.

I could just create a new datastore and start a new backup job with encryption properly set up, but I'm curious if there's a way to convert my existing unencrypted backups to be encrypted.

Thanks!
 
  • Like
Reactions: Johannes S
not at the moment, although we have discussed implementing an "encrypting" sync job - nobody started working on that yet though..
 
not at the moment, although we have discussed implementing an "encrypting" sync job - nobody started working on that yet though..
Thanks for letting me know. Sounds like the best thing to do is to start over and do it right this time. ;)

The encrypting sync job sounds like a great feature, though I suspect it's a bit troublesome to architect given that PBS is designed around client-side encryption--isn't the data encrypted before it ever leaves the client, so PBS doesn't have to do that work (or have the keys?).
 
  • Like
Reactions: Johannes S
it would only work for going from unencrypted to encrypted (which is a common use case - on-prem deemed "safe" to have unencrypted, off-site requiring encryption), or from encrypted-with-key-available to encrypted-with-another-available-key (e.g., to do a key rollover), yes.

technically you can already manually do such a migration, if you have enough free space:

- restore oldest snapshot in group, back it up again using same timestamp but with encryption and to a new namespace
- continue with next snapshot
- continue with next group
- repeat until namespace and original contents are completely synced up
- switch backup jobs over to namespace and encryption
- delete old unencrypted backups
- run GC

you could optimize this by having a custom client that doesn't actually restore but passes the data back to PBS right away (that's basically what the sync job would do - the pull/push/sync code is nothing more than a backup client packaged up nicely)
 
  • Like
Reactions: Johannes S
it would only work for going from unencrypted to encrypted (which is a common use case - on-prem deemed "safe" to have unencrypted, off-site requiring encryption), or from encrypted-with-key-available to encrypted-with-another-available-key (e.g., to do a key rollover), yes.

technically you can already manually do such a migration, if you have enough free space:

- restore oldest snapshot in group, back it up again using same timestamp but with encryption and to a new namespace
- continue with next snapshot
- continue with next group
- repeat until namespace and original contents are completely synced up
- switch backup jobs over to namespace and encryption
- delete old unencrypted backups
- run GC

you could optimize this by having a custom client that doesn't actually restore but passes the data back to PBS right away (that's basically what the sync job would do - the pull/push/sync code is nothing more than a backup client packaged up nicely)
Thanks for this procedure. I'm going to document it in case I ever need it.

I have way too much room vs. my actual requirements on my local PBS server (by about a factor of 8). I'm planning to grow into it, but in the meantime, it means it was pretty easy to just create a new namespace, add a new encrypted version of the same PBS server to Proxmox as a new Storage, and set up a new backup job.

It's running now and seems to be doing just fine.

I've disabled the old job, but I'm not going to manually prune it. I'll let my scheduled prune settings take care of it, so those backups will be there for a while in case something goes horribly wrong.

(I'm planning to redo how I store my VMs/LXCs and their data, so getting local encrypted backups in place and using those as the basis for my new Tuxis-based remote sync job before that felt like the way to go. ... Even if I honestly didn't really want to have to mess with my backup system; I configure it so rarely that I don't have a ton of confidence messing with it. :P)