Proxmox Backup Server 4.2 released!

still no immutability option, without a solid immutability option you still need another backup solution.
For regular datastores this is not easily implemented and requires the underlying storage to provide some mechanism to do so, see https://bugzilla.proxmox.com/show_bug.cgi?id=4293.

For datastores backed by S3, this might get implemented based on the discussion in https://bugzilla.proxmox.com/show_bug.cgi?id=6780 and the there linked forum thread, but I cannot give an ETA.

Edit: FYI, what you can already do is sync to offsite remotes or store to tape if the goal is ransomware protection https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
 
Last edited:
  • Like
Reactions: Johannes S
For regular datastores this is not easily implemented and requires the underlying storage to provide some mechanism to do so, see https://bugzilla.proxmox.com/show_bug.cgi?id=4293.
Adding to your link to the manual I want to point out, that for regular datastores it's not really needed since you can
  • Use tapes or usb discs ("removable datastores") as air-gapped backup target
  • Setup another PBS behind a firewall so neither the primary PBS nor the PVE nodes can access it. Then the remote PBS can do a pull-sync to the primary PBS.
I see the usecase for S3-backed datastores though.
 
I had some trouble installing 4.2 on old hardware - it seems the underlying Debian Trixie has dropped support for several components, I could not get the install to complete on a Dell R510 with H700 perc card. I fully understand this is way beyond ideal hardware but what I thought was a full HBA card in a failed newer system turned out to be one of those mini daughter cards (thanks Dell! ), so I have to make do with the H700 in an older chassis as a stop-gap solution. I'm using 2 x fast SSD in hardware raid1 for boot and then the remaining 6 bays each as a RAID0 volume of an enterprise quality SSD which is presented to PBS for ZFS (RAIDZ2) for the data pool. Like I say - not ideal. But I'm also putting in a NAS for 'colder' archive backups in a remote building.

I was getting squashfs errors and it looked like the boot media was faulty. I also suspected it was using EFI rather than Legacy on the older chassis but that wasn't the issue either. I tried a lot of different permutations but came to the conclusion it wasn't possible to install 4.2. What worked was install older PBS 3.2 and upgrade to 4.2 - that was very smooth and no problems. Resulting system seems to be working better than I expected of such old hardware. Smartctl can see the smart data using megaraid so it's reasonably robust.

Anyway, just thought I'd share that 3.2 and upgrading is very smooth if you are using older hardware in a home lab etc. Its my first time trying PBS and I have to say I'm already a huge fan.
 
I’m still playing around with it, but so far I’m happy with it.

I’m coming from Veeam, but Veeam doesn’t seem to work as well with Proxmox as it does with VMware.

I do miss immutability — that’s definitely a must-have — but for now I’m still testing things. Other than that, Veeam seems to work fine so far.
 
Last edited:
Hello,

I would like to point out that PBS 4.2 ISO installer seems to not boot on a Hyper-V host (Windows 11 25H2 laptop)

Legacy CSM boot is affected
UEFI boot also affected, regardless if Secure Boot is enabled or not

Symptoms :
Proxmox Backup Server installer Grub menu is displaying just fine
Actual boot using the GUI or Terminal UI options of Grub are not working

The kernel seems to boot fine but the installation media is somehow "not found" ?

Applied workaround :
Install PBS 4.1 and upgrade to 4.2 is OK

Thank you.
 
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.
Follow up. So I noticed an update to the kernel 7 to 7.0.2-2-pve, so I tried it on my PBS with the enterprise subscription (HP, gen 11). It's newer hardware so I figured it might be OK. And it has been fine. So I might try the newer kernel on the HP Microserver Gen 8 again and see what happens. Plus I see the kernel is up to 7.0.2-4-pve. So it may have addressed some issues. We'll see. Wish me luck.
 
And that's a hard no. The HP Microserver Gen 8 does NOT tolerate kernel 7.0.2-4-pve. As soon as I attempted a backup, a hard crash requiring power off and back on, reboot, and select a 6.17 kernel. We are now pinned to kernel 6.17.13-7-pve. And that's probably the way it's going to have to be. The HP server gen 11 seems to be tolerating the 7.0.2-4-pve kernel just fine though. Strange.
 
For regular datastores this is not easily implemented and requires the underlying storage to provide some mechanism to do so, see https://bugzilla.proxmox.com/show_bug.cgi?id=4293.
You can use a similar implementation to what Veeam did: XFS immutable storage located on a hardened server outside of PBS and attached as an XFS immutable repository.
For datastores backed by S3, this might get implemented based on the discussion in https://bugzilla.proxmox.com/show_bug.cgi?id=6780 and the there linked forum thread, but I cannot give an ETA.

Edit: FYI, what you can already do is sync to offsite remotes or store to tape if the goal is ransomware protection https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery

Having immutable S3 as an option will do, but tape is not a real option. It is not only expensive legacy technology, but it’s also not practical to rely on people to change tapes.
 
Last edited: