beginner’s question: I am setting up restic with backblaze b2 for daily backups of a laptop. I’ve read a bit about object lock / lifecycle settings, and am confused.
I can configure the b2 bucket to delete hidden files after, say, 30 days, to be safe against a ransom attacker deleting my data + backup. I assume that in this scenario, the attacker deletes (forget --prune) all my restic snapshots, such that I am only left with the hidden files in the bucket, marked for deletion.
Now, given this scenario, how can I restore the data from the hidden files?
Does this question even make sense? There is probably a misunderstanding.
My repos are so small (< 100 GB) that I can simply run rclone sync … —b2-version-at in case I want to revert a local copy of my repositories back in time. You can find here how to pass parameters to rclone via restic to try to access previous versions of your B2 repository.
More expensive solution. I use rclone to sync my local repo to rsync.net, which has rolling 7-day immutable ZFS read-only snapshots. They also support using restic directly or with rclone. Login can be limited to ssh key only.
What you are missing is all objects lock periodic extension. Otherwise only your latest files are protected - not all repository. Files older than your defined locking time won’t have lock set any more.
I’m certainly missing something here. My B2 bucket setup is as follows: object lock is off, application key cannot delete objects but can only hide them, and hidden files are retained for a few weeks before being permanently deleted. I already tested reverting my repositories to any specific point in time within those few weeks, and everything seemed to work fine.
then effectively you are not using lock protection but restricted keys one. Which is often good enough but it is not the same. Somebody with access to your B2 keys can not truly delete anything. But what if they get hands on your B2 login credentials? Then they can delete anything what is out of original lock. Or create extra pair of keys with delete rights.
With lock protection (especially in compliance mode) there is NO way to truly delete anything (things can be hidden only like with restricted keys). There are no and can’t be created (knowingly or by bad actor) any keys/logins/access rights with permission to delete locked object. This is often required in some regulated industries to guarantee that data can not be deleted for specified period of time. For individual users maybe it sounds like overkill, especially that they control all credentials. But situation is very different when there are multiple people having access (which is the case in many organizations). Mistakes can be made, some individuals can have malicious intents etc.
Full lock protection goes one step further than restricted keys and in case of restic requires keeping lock validity for all files (to guarantee repo integrity). It means that periodically all repo files lock have to be extended - this is actually only operation allowed on locked objects.