Is it possible to have th proxmox-backup-client-static in the latest version? Great job

I miss "u la la laaaa la" videos

Do you mean the dedicated pbs-client repo? It was indeed lagging behind, but the CDN sync there should be finished now.

exactly.

proxmox-backup-client-static_4.2.0-1_amd64.deb     28-Apr-2026 22:16             9296220

evrything is fine. thanks for the update.

Great work moving s3 across the finish line. Now the next (really important) step there is immutability. So far I'm holding out for that to get done rather than start using Veeam for our Proxmox systems but that's literally the level of tradeoff we're having to consider.

Another piece (for both PBS and PDM) is fixing authentication and authorization to the point where it's at the same level as PVE. Right now forcing the users to login, then wait for an admin to assign them to a group, then log back in is a management chore and a half - tolerable for PBS but causing PBM to be a nonstarter. My (possibly wrong) understanding is that PBS and PDM share much of their auth code so fixing one fixes both.

Great work moving s3 across the finish line. Now the next (really important) step there is immutability. So far I'm holding out for that to get done rather than start using Veeam for our Proxmox systems but that's literally the level of tradeoff we're having to consider.

Are you aware that you can already implement kind of immutability with an offsite PBS and pull-syncs? For this to work you don't even need to open any ports on the offsite PBS firewall as long as it can reach the port 8007 on your local PBS: https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
Basically you use a combination of said firewall rules and read-only access API tokens.
And if somehow an bad actor manages to get root/admin access to your veeam server he can also modify your "immutable" repository, in that regard there is no difference between Veeam or PBS.

And if somehow an bad actor manages to get root/admin access to your veeam server he can also modify your "immutable" repository, in that regard there is no difference between Veeam or PBS.

I was specifically talking about S3 immutability specifically, which you did not address.
To your point, if an attacker is in backend systems long enough to modify the retention policy in Veeam, wait for the retention to expire, and then delete stuff... yeah. At that point no amount of resilient design is going to overcome such an epic failure in monitoring, configuration management, etc. The same attacker would just as easily pwn the offsite PBS, so either way the data is gone.

• Server-side encryption/decryption for sync jobs

I have a question regarding the limitation to push-sync jobs:

• Server-side encryption for push sync jobs.Push sync jobs can now be configured to encrypt snapshots before sending them to remote datastores.For example, this can be used to push snapshots to Proxmox Backup Server instances in less trusted offsite locations.Furthermore, pull sync jobs can be configured to decrypt snapshots encrypted on the remote datastores.

This would mean that if I want to encrypt my backups I would have to use a push-sync job. This is something I would really like to avoid since pull-sync jobs allows to close all ports on my remote PBS except a VPN connection to the management client. Are there any ideas to implement something like encryption even for a pull-sync job? Of course I could always do a workaround with localhost as remote to first push-sync and encrypt to a local namespace "encrypt- first" before the pull-sync but this needs additional storage space and adds complexity.

f the backups are already encrypted though, AFAIK they just remain encrypted. The pull-sync/remote PBS knows they exist but doesn't have the key. If I understand (?), the new feature would be to encrypt an unencrypted backup before pushing.

Well I can imagine following usecases: You have a local PBS on trusted hardware for fast restores, you would like not to use encryption so even if somehow you lost the key you still have backups and also to reduce CPU load for compression on the PVE nodes. If however I want to pull these backups from a remote PBS I would like to be able to be able to encrypt it before since the pull since I might not be able to trust the hardware completely (due do it being a virtual cloud server or a PBS-as-a-service instance).

To your point, if an attacker is in backend systems long enough to modify the retention policy in Veeam, wait for the retention to expire, and then delete stuff... yeah. At that point no amount of resilient design is going to overcome such an epic failure in monitoring, configuration management, etc. The same attacker would just as easily pwn the offsite PBS, so either way the data is gone.

Not necessarily. If the remote PBS has no open incoming ports but is still able to open a connection to your local PBS it's basically impossible for any bad actor to access it. Because: No open port, no connection.
I agree with you on immutable s3 backups though.

the limitation is intentional - if you don't trust your remote PBS with unencrypted backups, you also cannot trust it with the key to encrypt, since that gives it access to the unencrypted backups.

Makes sense, thanks for the explaination. Now I'm feeling stupid I guess following scheme would be problematic for different reasons or did I miss something:
- Remote PBS initiates a pull-sync via API
- Local PBS will encrypt the pulled chunks if (and only if) a config flag "encrypt before pull" is set on the local datastore or in the API call

So the idea is that the encryption key will never leave your local PBS, is this idea feasible or problematich for different reasons e.g. that it might break other things?

Thanks for the further explainations, I'm fine with current state of things, after all a workaround via "localhost" as "remote" relay is possible

So, I noticed the new kernel 7 come up in my (non-enterprise) PBS. So I tried installing it. I have PBS with enterprise license, but this was an extra backup server I had on an old HP Microserver Gen 8.

So the installation went OK, and it rebooted. But then crashed within the day. It looks like it crashed in the middle of a backup job. I was at home when it crashed, so I logged in remotely to the ILO and managed to get it to reboot, but it was clearly having troubles with the 7.0 kernel. I pinned it back to the previous 6.17.13(??) kernel and it seems to be fine again. Just thought I'd provide that feedback.