Immutable backups are often overlooked. At borgbase.com, we call this “append-only” mode and the large majority of repositories uses it. With S3 (or similar) you would add some policies to disable deletions. So it’s usually doable, but needs to be considered when setting up the backup process.

Does the append-only mode you have in borgbase fix the issues of the append-only mode in Borg itself? https://borgbackup.readthedocs.io/en/stable/usage/notes.html... Because the way it works in Borg isn't really workable in practice, it only seems to be good to check a box.

We use the same public version of Borg, so those limitations apply. It’s still quite workable. Just prune from a different machine or once a year when the repo gets too large.

We may move to reject destructive commands from append-only repos in the future, but this will break existing workflows. Discussion on this here: https://feedback.borgbase.com/posts/28/reject-delete-and-pru...

That’s all well and good for weather data, but if anything in your backup is in any way related to user behaviors or transactions, immutability is a crime.

Immutability in this context doesn't mean "kept forever", it just means the permission to hard-delete is separate from soft-delete.

GDPR requires that good data-stewards keep backups:

the controller and the processor shall implement... the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident

https://gdpr-info.eu/art-32-gdpr/

For more details on GDPR and backups, see https://www.backup-systems.co.uk/blog/6-gdpr-implications-on...

It would be inappropriate, for instance, to store user data on the blockchain.

It also requires that user data can be hard-deleted on command. The ability to wipe data from backups needs to be kept close at hand.