Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

b2: Add optional secondary key for locks #2887

wants to merge 2 commits into from


Copy link

@ongardie ongardie commented Aug 12, 2020

This enables a configuration that prevents restic from deleting its own files.
See the explanation in doc/030_preparing_a_new_repo.rst

What does this PR change? What problem does it solve?

This enables a configuration that prevents restic on Backblaze B2 from deleting its own files (either by mistake or as the result of a key compromise). It allows the user to configure two B2 keys: one can read and write but not delete files, and the other can read+write+delete but only under the locks/ directory.

An alternative implementation approach would be to allow two entire backends: one used for most files and the second used only for locks. This would be more general and may enable other useful configurations, but it seems significantly harder for the user to set up.

Was the change discussed in an issue or in the forum before?

I haven't open any discussions before. This is related to and probably conflicts with #2398.

Here's a related discussion for Wasabi, which seems to support finer-grained access policies: As far as I can tell, Backblaze only allows a coarse list of permissions per key.


  • I have read the Contribution Guidelines
  • I have enabled maintainer edits for this PR
  • I have added tests for all changes in this PR
  • I have added documentation for the changes (in the manual)
  • There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
  • I have run gofmt on the code in all commits
  • All commit messages are formatted in the same style as the other commits in the repo
  • I'm done, this Pull Request is ready for review

This enables a configuration that prevents restic from deleting its own files.
See the explanation in doc/030_preparing_a_new_repo.rst
Copy link

Related: #2134

Copy link

Thanks for suggesting a new feature. However, the necessary setup feels rather convoluted. As files can still be overwritten I don't see a benefit compared to #2398. And a proper solution using Object Locks will also work better with the latter PR. Thus, I'll close this PR, sorry for taking so long to reach a decision.

Copy link

Thanks for the follow-up @MichaelEischer. I haven't followed #2398 closely, but I agree it looks like a more promising direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

3 participants