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.still no immutability option, without a solid immutability option you still need another backup solution.
Adding to your link to the manual I want to point out, that for regular datastores it's not really needed since you canFor 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.
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.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.
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 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
Could you see any telling error messages? Maybe the persistent syslog has saved something so that you do not need to retry booting into 7.0 in your setup to gather those logs.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.
New LTO generations are still being released, autoloaders and libraries handle the swapping, and WORM media gives you actual physical protection-not just a software flag that can be cleared. Tape is cheap per TB over its whole lifetime and, more importantly, it doesn't share a failure domain with the credentials managing it. That's why 3-2-1-1-0 still (should) end in a "1" that's offline. Use immutable S3 by all means, but dismissing tape is how some people end up with a very modern backup set they can't restore when really facing such an attack.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.
chattr +i that root can reverse just as easily. Its real protection comes mostly from it living on a separate box, so an attacker who owns the backup server can't trivially nuke the data. You get basically (rather exactly) the same guarantee in PBS today by pushing to a remote with a user that can create but not delete-no XFS gymnastics required.Could you see any telling error messages? Maybe the persistent syslog has saved something so that you do not need to retry booting into 7.0 in your setup to gather those logs.
We use essential cookies to make this site work, and optional cookies to enhance your experience.