I want nothing more than encrypted push sync

[Zappes]

I currently run a Proxmox PVE and PBS in my home environment, both on their own physical machines. While this is great for the mandatory on-site backup, it doesn't help with natural disasters and such, so I really want to add an off-site solution. Luckily, my parents just got really fast fiber internet, and they would let me put a bit of hardware in their basement.

My plan for this would be simple: Buy a UGreen DXP-4800+, put PBS and Netbird on it and sync my local PBS to that machine. There is a problem though: I don't have any influence on physical security at my parent's home and I wouldn't even dream of storing an unencrypted backup there.

My initial, naive assumption was that Proxmox PBS will surely support some kind of encrypted remote for syncing. Well, I do now know that this is a case where the Anakin/Padme meme fits really well. Synced remote backups can only be encrypted if the original local backup was encrypted. Which is a well-hidden feature in Proxmox PVE (i.e. not exposed on the GUI), and I also conciously chose not to use it because the official documentation clearly advises against it in a pure local trusted network situation like mine...

Now, I wil probably do something really ugly like putting a restic REST server on that NAS and then use restic to put an encrypted backup of my datastore there. This is really clumsy because restic's retention policy overlaps with that of PBS and it's a pure command line adventure, but well, it will work. Somehow. I hope.

So here is my plea to the developers: Please add an optional encryption key for push sync jobs. It obviously makes little sense for pull syncs as we want the key to reside on the trusted side, but it would probably be quite trivial to add to the push sync. And please, don't do this in a way that requires shell access and isn't exposed on the GUI. I suffer from heavy ADHD, and having to remember that there's something on the shell that I have to keep in mind is a major obstacle for me.

 

[Impact]

This belongs here: https://bugzilla.proxmox.com/enter_bug.cgi?product=pbs

 

[Zappes]

OK, I added it to Bugzilla as well. It might still be an interesting conversation topic for the community, though.

 

[Johannes S]

If you care about security why would you want to use push-sync in the first place? With push-sync your local PBS can access and write to the remote PBS. A pull-sync on the remote PBS allows to close incoming network traffic on the remote PBS except maybe one IP for a managment VPN from your notebook.
A alternative variant would be to backup to your local and the remote PBS but I wouldn't do this since it will make incremental backups longer and be worse from a security point of view (since you then need access to the remote PBS).

Which is a well-hidden feature in Proxmox PVE (i.e. not exposed on the GUI), and I also conciously chose not to use it because the official documentation clearly advises against it in a pure local trusted network situation like mine...

Since your remote PBS isn't in a "local trusted network" your situation isn't actually covered by it. I think you missunderstood the documentation it says:

Do not use encryption if there is no benefit from it, for example, when you are running the server locally in a trusted network. It is always easier to recover from unencrypted backups.
https://pve.proxmox.com/pve-docs/chapter-pvesm.html#storage_pbs_encryption

In your case however there is a clear benefit. So I would just encrypt everything right from the start and keep a backup of your encryption keys in different places.

Now, I wil probably do something really ugly like putting a restic REST server on that NAS and then use restic to put an encrypted backup of my datastore there. This is really clumsy because restic's retention policy overlaps with that of PBS and it's a pure command line adventure, but well, it will work. Somehow. I hope

This is a bad idea for a different reason. If you don't use PBS native sync mechanism you need to be really careful not to mess up your backups due to an inconstent datastore, see here:

Z

Thread 'Datastore synced with Rclone broken?'

Sep 20, 2024

I'm trying to set up a remote sync to a friend's RPI for my Proxmox Backup Server. I've been using this script that uses Rclone with an encrypted remote (Crypt) on a schedule:

#!/bin/bash

# A simple script to back up PBS to Crypt remote

_lock_file=/root/.tertiary_backup.lock

_schedule_time=1:30
_max_duration="7.5h"
_cutoff_mode="soft"

_datastore_dir_name=Primary_Backup
_datastore_dir_path=/mnt/datastore/$_datastore_dir_name
_config_dir=$_datastore_dir_path/host_backup

_remote_user=user
_remote_ip=tailscale-ip
_remote_port=22
_remote_name=Tertiary_Backup_Crypt...

• Zeash
• pbs rclone remote backup
• Replies: 11
• Forum: Proxmox Backup: Installation and configuration

S

Thread 'PBS appears not to write to disk'

Nov 20, 2024

Hello friends.

New user of Proxmox and PBS here. I'm evaluating it for use in a tech company that is starting to need virtualization of a few services. Right now I have a basic working config on a local server:

PVE - running 4 x VMs
PBS - also running as a VM inside PVE. Datastore is configured to point at a section of thin storage within PVE, not a dedicated disk (yet).

My short term aim is to sync the backups on PBS with a cloud storage provider using Rclone. I am having trouble reading the backup files off the disk inside PBS. The backup appears to go fine from PVE-PBS. I can...

• sublimebutbroken
• Replies: 3
• Forum: Proxmox Backup: Installation and configuration

That being said restic is a great backup software but for a different usecase ( I do this myself): Only use PBS for your vms/lxcs, keep the actual bulk data and PBS encryption keys outside (e.g. on a nas) and back it up with restic. This is especially handy if you (like me) have a tight backup since s3 is cheaper per TB than a vserver
It's also a good option for storing your encryption keys of PBS outside of your PBS backups or for having an additional vm backup with the regular (non-incremental) vzdump vma-Backups (which will need more storage than PBS but don't need it for restore, so it might be worth to keep a monthly copy or something like that of them).

 

[Zappes]

If you care about security why would you want to use push-sync in the first place? With push-sync your local PBS can access and write to the remote PBS. A pull-sync on the remote PBS allows to close incoming network traffic on the remote PBS except maybe one IP for a managment VPN from your notebook.
A alternative variant would be to backup to your local and the remote PBS but I wouldn't do this since it will make incremental backups longer and be worse from a security point of view (since you then need access to the remote PBS).

We may have a misunderstanding here. Let me describe the situation with a picture:



The reason why I want to use push here is because it really makes a lot of sense to only give the encryption keys to the (trusted) client, in my case the PBS/local.

Oh, and thanks for the information about restic being a problem here. I wasn't aware of that.

 

[Johannes S]

We may have a misunderstanding here. Let me describe the situation with a picture:

View attachment 95068

Yes and this situation isn't possible at the moment. You can only create encrypted backups from ProxmoxVE thus your PBS servers don't know the encryption key anyhow. If you use a pull-sync however, you could configure the firewall or netbird vpn on the remote pbs that neither the local pbs nor your PVE can access it. Only your managment node (aka your machine which you use to access the webinterface of PBS/remote) will be able to connect via netbird. If you ever need to restore you would temporary create an exclusion.

The benefit is, that even if some bad actor managed to take over your PVE and PBS/local server he wouldn't be able to do anything on PBS/remote since he can't connect to it.

The reason why I want to use push here is because it really makes a lot of sense to only give the encryption keys to the (trusted) client, in my case the PBS/local.

Oh, and thanks for the information about restic being a problem here. I wasn't aware of that.

The problem isn't about restic, it's the same for any tool (be it restic, rclone (like in the linked threads), rsync or whatever) you use to sync your datastore without using the native sync of PBS. The problem is, that the PBS might still write to the datastore during the transfer so you might get an inconsistent or broken datastore through the sync. People managed to get it to work by using filesystem-level snapshots of the datastore or temporary disabling the PBS services and remounting the datastore read-only but for me this always looked like to much hassle and error-prone. It's simply easier to relie on the incldued sync mechanisms. restic is a phantastic generic backup tool though this is why I recommend seperating between vm /lxc images (containing the operating system and application install+configuration, backup with PBS ) and actual data ( backup with restic or some other tool).