Repository: restic/restic

Issue #3195: Proposal: New command: protect snapshot
Created: 2020-12-27T16:44:19Z
Output of restic version
Not applicable
What should restic do differently? Which functionality do you think we should add?
I propose a new command "protect" which marks data for a given snapshot as immutable (to prevent deletion/modification)
restic protect --repo s3:https://s3.amazonaws.com/restic-demo --snapshot [snapshotid | latest if not given] 30d 
This would add an object lock for 30 days to all files in the repo needed to restore data from that snapshot. If no snapshot is given it would use the latest snapshot.
As far as I know only S3 and S3-compatible backends (backblaze, minio, etc) do support immutable data right now, so the command would only support these backends.
Additionally this could be added as an option to the backup command, so the protection is put directly in place.
If this is accepted, I would go forward and write the necessary pull request(s).
What are you trying to do? What problem would this solve?
We need to have immutable backups to protect the data from ransomware and I think using an explicit command makes the implementation much easier in the first step.
Right now we are using a second host running rclone with a forced ssh command, but that is clumsy at best and adds another dependency...
Did restic help you today? Did it make you happy in any way?
restic saved my day so many times - I really like it and I really appreciate the developments this year ;)

Duplicate issue #3759: Add flag to apply retention policy to objects stored in S3
Created: 2022-05-16T05:52:26Z
Output of restic version
restic 0.13.1 compiled with go1.18.1 on linux/amd64
What should restic do differently? Which functionality do you think we should add?
Add a flag to certain restic subcommands (at least backup and copy) to have restic apply a retention policy (PutObjectRetention docs) on objects it creates in S3 other than the lockfiles.
Two parameters would be required:

Mode: Governance (admin can override retention period) or Compliance (retention period cannot be overridden at all)
RetainUntilDate: When the immutability will expire. Ideally this could be provided either as an end date or a duration (where restic automatically calculates the end date).

It would also have to be determined whether restic should renew the retention period on objects referenced by the current backup, on all objects in the repo, or not at all. (And whether this should be configurable.)
Background:
S3 Object Lock is a useful feature that can help protect against ransomware by making objects in S3 immutable. From my understanding, it can either be turned on for an entire bucket (so all new objects have retention applied), or on individual files. The global solution would be ideal as it guarantees nothing is missed and would require no code in the client. However, restic creates lock files in the bucket which cannot be removed if retention is in place. Therefore, I propose that restic implement the ability to use the PutObjectRetention API to apply an object lock to its objects but not the lock files.
Did restic help you today? Did it make you happy in any way?
I'm finally getting to setting up backup again and I was incredibly impressed by restic's feature set. After reading up on it I decided to go all in with it as I'm confident in its stability and the fact that I'll actually be able to restore my backups when I need to. Also, I'm really happy about how little of my own automation I have to write around it :)

Closing comment (2022-05-16T19:24:43Z): Duplicate of #3195. Just refreshing object locks isn't really sufficient, we'll also need some additional sanity checks to prevent someone from breaking a repository without anyone noticing.