PBS and the immutable question

[andreisrr]

I've recently engaged in several conversations on backup solutions and backend storage solutions and because the much advertised "immutable backups" feature of some other solutions I've been repeatedly shunned whenever I mention PBS.

Perhaps my understanding is ls flawed, but ...
I did read the PBS documentation and some discussions online on the subject.

My understanding is the following:
* the much advertised "immutable backups" claim they protect you in case of a successful ransomware attack that encrypts your data.

Here is where I have several major questions of logic.
If an attacked has compromised your with ransomweare and encrypted your data, the following scenarios make sense:
- production data has been compromised. I have backups, to my knowledge new backup runs will update the backup the the current version of data, but as long as the cleanup jobs didn't delete the older versions of the data from the backup, data is still restorable.
In this scenario the storage that stores the actual backup data is not directly affected by the attack.
Where and how an immutble function significantly help ?

- the storage PBS uses for it's internal files is accessed directly. If this device has immutable function likely no data is ever overwritten but just added, so the backend data is safeguarded, right?
But if this actually happens, surely you have MUCH BIGGER problems and how much of the already attacked data would you really trust rather then revert to an offsite or offline backup and rebuild and restore from CLEAN setup?

- the only other situation that I could think of is a backup system that detects MAJOR changes in the data to be backup up (due to encryption) and considers this as a compromise indicator ? Also might be falsely trigered by actual legitimate major data changes?

How big of a deal and how much of a real-world help is the highly advertised "immutable" function for backup systems?

 

[LnxBil]

I have backups, to my knowledge new backup runs will update the backup the the current version of data, but as long as the cleanup jobs didn't delete the older versions of the data from the backup, data is still restorable.

and the retention settings

If this device has immutable function likely no data is ever overwritten but just added, so the backend data is safeguarded, right?

The only write once read many (WORM) I know are the identically named LTO tapes. As long as you secure your PBS properly, e.g. not attaching it to any AD/LDAP/OID to keep the attach surface small, you're safe. PBS acts as an appliance then. It is important that you create a user / token that can only read and add backups and is not able to delete. You can use PBS with ZFS and snapshots, but if the host is compromised, the snapshots are, too.

the only other situation that I could think of is a backup system that detects MAJOR changes in the data to be backup up (due to encryption) and considers this as a compromise indicator ? Also might be falsely trigered by actual legitimate major data changes?

Yes, you can use that and it's a good metric. You have to reverse engineer (or read the documentation) the way PBS stores its chunks and compute the amount of new data.

How big of a deal and how much of a real-world help is the highly advertised "immutable" function for backup systems?

It's just a marketing term. As long as you're not using really WORM storage, e.g. the WORM LTO tapes or optical mediums, you will not have real and total immutability. The immutability - depending on the implementations - is the clever use of different techniques and abstractions. This could be hardware secured appliances like Rubrik which need to be compromised too in order to get to the data. As long as you seperate the backup machines from your infrastructure completely and only allow a user over one port to send new data to the backup, you're fine. This is then considered immutability if you just can't access it. You can also use different technologies / protocols, e.g. for our consumers, we supply NFS/PBS/S3 storage than can be snapshotted on sync automatically (via hooks), so that the data is snapshoted on the storage side and only read including the snapshots, but you cannot delete data on the snapshots.

 

[Johannes S]

To quote myself from an earlier related discussion:

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.