borgbackup/docs/usage/transfer.rst

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

107 lines
4.4 KiB
ReStructuredText
Raw Normal View History

2022-06-23 19:19:19 -04:00
.. include:: transfer.rst.inc
Examples
~~~~~~~~
To keep the following examples short and readable, we export the repository
locations and passphrases first:
::
export BORG_REPO=ssh://borg2@borgbackup/./tests/b20
export BORG_PASSPHRASE='your-borg2-repo-passphrase'
export BORG_OTHER_REPO=ssh://borg2@borgbackup/./tests/b1x
export BORG_OTHER_PASSPHRASE='your-borg1-repo-passphrase'
::
2026-05-15 13:10:17 -04:00
# Borg 1.x repository -> Borg 2.0 repository (hmac-sha256 -> hmac-sha256, keeping the same chunk ID algorithm)
2026-05-15 13:10:17 -04:00
# 0. Have Borg 2.0 installed on the client AND server; have a Borg 1.x repository copy for testing.
# 1. Create a new "related" repository:
# Here, the existing Borg 1.x repository used repokey (and AES-CTR mode),
# thus we use aes256-ocb for the new Borg 2.0 repository.
# Staying with the same chunk ID algorithm (hmac-sha256) and with the same
# key material (via BORG_OTHER_REPO) will make deduplication work
# between old archives (copied with borg transfer) and future ones.
# The AEAD cipher does not matter (everything must be re-encrypted and
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
# re-authenticated anyway); you could also choose chacha20-poly1305.
$ borg repo-create -e aes256-ocb
# 2. Check what and how much it would transfer:
$ borg transfer --from-borg1 --dry-run
# 3. Transfer (copy) archives from the old repository into the new repository (takes time and space!):
$ borg transfer --from-borg1
# 4. Check whether we have everything (same as step 2):
$ borg transfer --from-borg1 --dry-run
::
2026-05-15 13:10:17 -04:00
# Borg 1.x repository -> Borg 2.0 repository (blake2 -> blake3, changing the chunk ID algorithm)
2026-05-15 13:10:17 -04:00
# 0. Have Borg 2.0 installed on the client AND server; have a Borg 1.x repository copy for testing.
# 1. Create a new "related" repository:
# Here, the existing Borg 1.x repository used repokey-blake2 (and AES-CTR mode),
# thus we use aes256-ocb with --id-hash blake3 for the new Borg 2.0 repository.
# We need to change from blake2 to blake3, because blake2 is not supported
# for borg2 repos (blake3 is much faster). Because we change how chunk IDs are
# computed, we need to re-chunk everything while doing the transfer.
# The chunker parameters you provide here should be the same as you will
# use for all future Borg 2.0 archives.
# The AEAD cipher does not matter (everything must be re-encrypted and
# re-authenticated anyway); you could also choose -e chacha20-poly1305 -i blake3.
$ borg repo-create -e aes256-ocb -i blake3
$ export CHUNKER_PARAMS="buzhash64,19,23,21,4095"
# 2. Check what and how much it would transfer:
$ borg transfer --from-borg1 --chunker-params=$CHUNKER_PARAMS --dry-run
# 3. Transfer (copy) archives from the old repository into the new repository (takes time and space!):
$ borg transfer --from-borg1 --chunker-params=$CHUNKER_PARAMS
# 4. Check whether we have everything (same as step 2):
$ borg transfer --from-borg1 --chunker-params=$CHUNKER_PARAMS --dry-run
2022-07-04 18:38:37 -04:00
2026-05-15 13:10:17 -04:00
Keyfile considerations when upgrading from Borg 1.x
++++++++++++++++++++++++++++++++++++++++++++++++++++
2026-05-15 13:10:17 -04:00
If you are using a ``keyfile`` encryption mode (not ``repokey``), Borg 2
may not automatically find your Borg 1.x key file, because the default
key file directory has changed on some platforms due to the switch to
the `platformdirs <https://pypi.org/project/platformdirs/>`_ library.
2026-05-15 13:10:17 -04:00
On **Linux**, there is typically no change -- both Borg 1.x and Borg 2
use ``~/.config/borg/keys/``.
2026-05-15 13:10:17 -04:00
On **macOS**, Borg 1.x stored key files in ``~/.config/borg/keys/``,
but Borg 2 defaults to ``~/Library/Application Support/borg/keys/``.
2026-05-15 13:10:17 -04:00
On **Windows**, Borg 1.x used XDG-style paths (e.g. ``~/.config/borg/keys/``),
while Borg 2 defaults to ``C:\Users\<user>\AppData\Roaming\borg\keys\``.
2026-05-15 13:10:17 -04:00
If Borg 2 cannot find your key file, you have several options:
1. **Copy the key file** from the old location to the new one.
2. **Set BORG_KEYS_DIR** to point to the old key file directory::
export BORG_KEYS_DIR=~/.config/borg/keys
3. **Set BORG_KEY_FILE** to point directly to the specific key file::
export BORG_KEY_FILE=~/.config/borg/keys/your_key_file
2026-05-15 13:10:17 -04:00
4. **Set BORG_BASE_DIR** to force Borg 2 to use the same base directory
as Borg 1.x::
export BORG_BASE_DIR=$HOME
2026-05-15 13:10:17 -04:00
This makes Borg 2 use ``$HOME/.config/borg``, ``$HOME/.cache/borg``,
etc., matching Borg 1.x behavior on all platforms.
See :ref:`env_vars` for more details on directory environment variables.