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

Clarification of keyfile backup #6207

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

rolandu
Copy link

@rolandu rolandu commented Jan 30, 2022

Proposed clarification in response to my confusion in #6204.

Proposed clarification in response to my confusion in borgbackup#6204.
Comment on lines +519 to +520
If you use keyfile encryption, you MUST make sure to have an independent backup of these keyfiles, otherwise you cannot access your backups anymore if you lose
them. If you use repokey encryption it is also highly recommended that you backup the keyfiles in case the originals (stored within the repository) get damaged. The best way to create a backup is using the ``borg key export`` command.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this: can't we just simply say that you must have a backup of the keys in any case and use borg key export for this?

In the end, it doesn't really matter where they are stored and how you lose them, but that for both options, it is possible to lose them.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, something like "backup the key in case you need it" is probably the shortest version for the end user.

My confusion really came from the fact that this said disaster recovery without a backup of the keyfile was impossible but I did remember doing just that last year (which was possible because I had repokey and not keyfile enc).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or: By all means, backup the key! And keep the backup and your passphrase at a safe place.

@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented Feb 13, 2022

Hmm, I just noticed we should document that elsewhere: In the borg key export docs.

Currently, we have 2 places talking about key backup:

  • faq (== this PR)
  • quickstart (the warning section below "repository encryption")

I think both places should only have one sentence about that where they link to borg key export docs.
Like "You must make a backup of your borg key, see --->borg key export how to do that.".

And everything else should get refactored and deduplicated into the borg key export docs.

borg repokey keys are stored inside the repository. You MUST make sure to have an
independent backup of these keyfiles, otherwise you cannot access your backups anymore if you lose
them. You also MUST keep these files secret; everyone who gains access to your repository and has
All your borg keyfile keys are stored in this directory. Please note that borg repokey keys are stored inside the repository.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"keyfile keys" sound somewhat weird, I'd say they are just "keyfiles".

Also, the first part of this basically just reformarts into a single awfully long line. The file already has some variation in line lengths, but that should not be worsened.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, agreed, it sounds a bit strange, but the types of borg keys we have are "keyfile" and "repokey".

so while it may sound a bit strange, it hopefully makes 100% clear what is meant.

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

Successfully merging this pull request may close these issues.

None yet

3 participants