borgbackup/docs/usage/key.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

76 lines
2.3 KiB
ReStructuredText
Raw Normal View History

.. include:: key_change-location.rst.inc
2017-06-06 18:06:36 -04:00
.. _borg-change-passphrase:
.. include:: key_change-passphrase.rst.inc
Examples
~~~~~~~~
::
# Create a key file protected repository
key: unify keyfile/repokey classes, locate key independent of type byte (#9743) Borg used to read the manifest's key-type byte and then look for the key in exactly one place (keyfile or repokey) depending on the key class that byte selected. As a result every crypto suite was duplicated into a keyfile class and a repokey class that differed only in TYPE, NAME, ARG_NAME and STORAGE. Now key *location* is independent of the type byte: detection tries keyfiles first and repokeys afterwards until a passphrase unlocks a key. The type byte still selects the crypto suite (id hash, MAC, cipher) to instantiate. Where a key is stored (keyfile vs repokey) is therefore a per-key property (self.storage), not a separate class, so a repository may even hold a mix of keyfile- and repo-stored borg keys. With storage decoupled from class identity, the keyfile/repokey class pairs collapse into one class per crypto suite: - modern AEAD: AESOCBKey, CHPOKey, Blake3AESOCBKey, Blake3CHPOKey - legacy borg 1.x (read-only): AESCTRKey, Blake2AESCTRKey There is now exactly one type byte per modern crypto suite (the old separate repokey type bytes 0x11/0x21/0x31/0x41 were removed; borg2 is beta and only needs to read repos it created). identify_key() matches on TYPES_ACCEPTABLE. CLI: --encryption selects only the crypto suite (aes-ocb, chacha20-poly1305, blake3-aes-ocb, blake3-chacha20-poly1305, authenticated*, none); the storage location is chosen with the new --key-location=repokey|keyfile (default repokey). The old combined modes (repokey-aes-ocb etc.) were removed. borg key import also gained --key-location. borg key change-location no longer swaps key classes or rewrites the manifest; it just re-saves the unlocked key at the new location. Keyfile removal (key remove, change-location) now overwrites the keyfile with random data via secure_erase() before unlinking, consistent with save(). borg 1.x legacy read compatibility is preserved (the legacy class merge is a behavior-preserving rename; the legacy type bytes incl. PASSPHRASE stay in TYPES_ACCEPTABLE). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-12 17:07:57 -04:00
$ borg repo-create --encryption=aes-ocb --key-location=keyfile -v
2017-06-06 18:06:36 -04:00
Initializing repository at "/path/to/repo"
Enter new passphrase:
Enter same passphrase again:
Remember your passphrase. Your data will be inaccessible without it.
Key in "/root/.config/borg/keys/mnt_backup" created.
Keep this key safe. Your data will be inaccessible without it.
Synchronizing chunks cache...
Archives: 0, w/ cached Idx: 0, w/ outdated Idx: 0, w/o cached Idx: 0.
Done.
# Change key file passphrase
2022-06-23 19:19:19 -04:00
$ borg key change-passphrase -v
2017-06-06 18:06:36 -04:00
Enter passphrase for key /root/.config/borg/keys/mnt_backup:
Enter new passphrase:
Enter same passphrase again:
Remember your passphrase. Your data will be inaccessible without it.
Key updated
.. note::
The key file paths shown above are the defaults for Linux (``~/.config/borg/keys/``).
On macOS, key files are stored in ``~/Library/Application Support/borg/keys/``.
On Windows, they are stored in ``C:\Users\<user>\AppData\Roaming\borg\keys\``.
See :ref:`env_vars` for details.
::
# Import a previously-exported key into the specified
# key file (creating or overwriting the output key)
# (keyfile repositories only)
2022-06-23 19:19:19 -04:00
$ BORG_KEY_FILE=/path/to/output-key borg key import /path/to/exported
2017-06-06 18:06:36 -04:00
Fully automated using environment variables:
::
key: unify keyfile/repokey classes, locate key independent of type byte (#9743) Borg used to read the manifest's key-type byte and then look for the key in exactly one place (keyfile or repokey) depending on the key class that byte selected. As a result every crypto suite was duplicated into a keyfile class and a repokey class that differed only in TYPE, NAME, ARG_NAME and STORAGE. Now key *location* is independent of the type byte: detection tries keyfiles first and repokeys afterwards until a passphrase unlocks a key. The type byte still selects the crypto suite (id hash, MAC, cipher) to instantiate. Where a key is stored (keyfile vs repokey) is therefore a per-key property (self.storage), not a separate class, so a repository may even hold a mix of keyfile- and repo-stored borg keys. With storage decoupled from class identity, the keyfile/repokey class pairs collapse into one class per crypto suite: - modern AEAD: AESOCBKey, CHPOKey, Blake3AESOCBKey, Blake3CHPOKey - legacy borg 1.x (read-only): AESCTRKey, Blake2AESCTRKey There is now exactly one type byte per modern crypto suite (the old separate repokey type bytes 0x11/0x21/0x31/0x41 were removed; borg2 is beta and only needs to read repos it created). identify_key() matches on TYPES_ACCEPTABLE. CLI: --encryption selects only the crypto suite (aes-ocb, chacha20-poly1305, blake3-aes-ocb, blake3-chacha20-poly1305, authenticated*, none); the storage location is chosen with the new --key-location=repokey|keyfile (default repokey). The old combined modes (repokey-aes-ocb etc.) were removed. borg key import also gained --key-location. borg key change-location no longer swaps key classes or rewrites the manifest; it just re-saves the unlocked key at the new location. Keyfile removal (key remove, change-location) now overwrites the keyfile with random data via secure_erase() before unlinking, consistent with save(). borg 1.x legacy read compatibility is preserved (the legacy class merge is a behavior-preserving rename; the legacy type bytes incl. PASSPHRASE stay in TYPES_ACCEPTABLE). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-12 17:07:57 -04:00
$ BORG_NEW_PASSPHRASE=old borg repo-create --encryption=aes-ocb
2017-06-06 18:06:36 -04:00
# now "old" is the current passphrase.
2022-06-23 19:19:19 -04:00
$ BORG_PASSPHRASE=old BORG_NEW_PASSPHRASE=new borg key change-passphrase
2017-06-06 18:06:36 -04:00
# now "new" is the current passphrase.
.. include:: key_export.rst.inc
2024-07-19 13:44:38 -04:00
Examples
~~~~~~~~
::
borg key export > encrypted-key-backup
borg key export --paper > encrypted-key-backup.txt
borg key export --qr-html > encrypted-key-backup.html
# Or pass the output file as an argument instead of redirecting stdout:
borg key export encrypted-key-backup
borg key export --paper encrypted-key-backup.txt
borg key export --qr-html encrypted-key-backup.html
.. include:: key_import.rst.inc
.. include:: key_add.rst.inc
.. include:: key_list.rst.inc
.. include:: key_remove.rst.inc