As @Forrend correctly pointed out, there are two things:
- Support within restic to not remove specific snapshot based by information within the snapshotfile independent from any
forgetpolicy. I personally would call this delete protection aslockis typically associated with a storage backend capability. This is not implemented in restic but actually quite easy to add. (And I know some people dislike me pointing to rustic, but it does implement this functionality using adeletefield in the snapshot file which allows to be set asNever) - Support within restic to use and set some locking capabilities within the backend, e.g. by an ACL-based access restriction or some compliance-supporting locking capabilities. I would see this on-top of what I called delete protection (if restic knows, that a user wants this snapshot be extra-protected by the storage backend, it makes no sense to try to remove it as this would anyway just give a backend error), but actually it is more complex: To ensure that not only the snapshot file is locked but also the content that snapshot references, the backend should lock the needed pack files also. So, this would mean to handle locks (in the sense of storage backend locks) also for pack files which is more involved as this requires handling of this withing
prune.