Use Restic with insecure source server

Hello together :wave:

I installed Restic a few weeks ago and am basically very satisfied. It’s easy and does what it’s supposed to do pretty well. But I was thinking the other day about what Restic’s protecting me against.

  • User / software deletes data: :white_check_mark:
  • Hardware error / Server failure: :white_check_mark:
  • Someone with root access or malware is doing bad things: :no_entry_sign:

My backup is at backblaze. The backup runs 1x per day per cronjob, for this reason the API key for backblaze and the restic password are stored in plaintext. So, Malware could also delete the backup with the API key. So, my question is:

Do you take the risk consciously or do you solve it differently? If so, how?

(Of course I don’t expect it, but I still want to cover all cases.)


Hey @markus and welcome to the restic community :slight_smile:
It’s great to hear that you are having a first good impression of restic and that it helped you backup your data.

Great question! This is what’s called a Threat Model.
Restic has documented its threat model and you can read all about it here: Docs - Threat Model

To put it short: if you have someone on your box as the system user which can access to credentials to B2 and the repository, then this is out of scope of restics threat model.

Let us know if you still have questions after reading up on that. :slight_smile:

1 Like

B2 supports application keys, which can be configured to disallow deleting files.

However, note that (similar to other object storage systems like S3) the permission to upload a new file also includes the ability to overwrite an existing file. The solution to this is to use object versioning (supported by B2 and S3) which means that overwritten files are never totally lost; there is a prior version that you can roll back to.

An appropriately-configured application key would be able to overwrite objects (thereby creating a prior version) but could not totally delete objects or prior versions.

Note that this complicates the prune operation. Pruning a repo in a versioned bucket will actually increase the amount of storage space you’re using.