borg-repo-create(1)

📦
version 2.0.0b25 · 3 versions
, in ubuntu stonking

💖 borg-repo-create(1) — borg backup tool 💖

okay so bestie, this is the moment it ALL begins — the very first thing you ever run when you're starting a fresh borg situation. it's the manual page for borg-repo-create, and honestly? iconic. periodt. let's get into it 🫶

✨ NAME ✨

borg-repo-create — Creates a new, empty repository. that's it, that's the vibe 💅

🌸 SYNOPSIS 🌸

borg [common options] repo-create [options]

🦋 DESCRIPTION 🦋

so this command creates a new, empty repository. and what IS a repository, you ask? it's a borgstore store that holds the deduplicated data from zero or more archives. zero! you can literally make an empty baby repo and it's valid. we love a flexible queen 👑

ngl, repo creation can be quite slow for some kinds of stores (like, for example, sftp:) — and the reason is that borgstore pre-creates ALL the directories it's gonna need, which makes using the store faster later. so it's slow up front, fast after. it's giving "investing in your future" energy ✨

🔐 Encryption mode TL;DR 🔐

okay this is the big one so pay attention bestie:

the encryption mode can ONLY be configured when you're creating a new repository. you cannot configure it per-archive, and you cannot change the mode of an existing repository. it's a one-time decision, no takebacks, no edits. the way that it's permanent is giving "tattoo" honestly 💀

this example right here will likely NOT give optimum performance on your machine (performance tips are coming below, stay with me):

borg repo-create --encryption aes256-ocb --key-location repokey

so what does Borg actually DO when you run this? buckle up:

  1. It asks you to come up with a passphrase. 🎀
  2. It creates a borg key (which contains some random secrets — see key_files).
  3. It derives a "key encryption key" from your passphrase.
  4. It encrypts and signs the key with the key encryption key.
  5. It stores the encrypted borg key in the repository (as an object in the keys/ namespace of the store). this is EXACTLY why it is essential to use a secure passphrase, bestie. no cap.
  6. It encrypts and signs your backups to prevent anyone from reading or forging them unless they have the key and know the passphrase. make sure to keep a backup of your key outside the repository — do not lock yourself out by "leaving your keys inside your car" (see borg_key_export). and here's the slay part: the encryption is done locally — if you use a remote repository, the remote machine never sees your passphrase, your unencrypted key or your unencrypted files. chunking and ID generation are also based on your key to improve your privacy. main character privacy energy fr fr 🔥
  7. It uses the key when extracting files to decrypt them, and to verify that the contents of the backups have not been accidentally or maliciously altered. she checks her work, she verifies, she's meticulous 💅

🔑 Picking a passphrase 🔑

make sure you use a good passphrase. not too short, not too simple. the real encryption / decryption key is encrypted with / locked by your passphrase. so if an attacker gets your key, they cannot unlock and use it without knowing the passphrase. that's the whole point, that's the assignment 🫶

be careful with special or non-ASCII characters in your passphrase:

  • Borg processes the passphrase as Unicode (and encodes it as UTF-8), so it does not have problems dealing with even the strangest characters. she's multilingual, she's cultured 💜
  • BUT: that does not necessarily apply to your OS/VM/keyboard configuration. your keyboard might not be the vibe it claims to be 😭

so better use a long passphrase made from simple ASCII characters than one that includes non-ASCII stuff or characters that are hard or impossible to enter on a different keyboard layout. simple and long > fancy and untypeable, periodt.

you can change your passphrase for existing repositories at any time; it will not affect the encryption/decryption key or other secrets. glow-up unlocked ✨

Borg also accepts an empty passphrase. the repository is still encrypted with a random key then, but that key is not protected: with repokey storage, anybody who can read the repository can also unlock the key, which is as good as no encryption at all 😭 (with keyfile storage, the key is only on your client, so an empty passphrase may be acceptable if e.g. the client's disk is encrypted). you can add a passphrase later with borg key change-passphrase. and borg repo-info shows whether the key has an empty passphrase. so you can always check, girlie 🔍

👑 Choosing a crypto suite 👑

depending on your hardware, hashing and crypto performance may vary widely. the easiest way to find out what is fastest is to run borg benchmark cpu. let your machine tell you what it's good at, bestie ⭐

--encryption (required, not optional, she's a need not a want) selects the mode:

  • aes256-ocb: AES256 in OCB mode (encryption + authentication).
  • chacha20-poly1305: ChaCha20 + Poly1305 (encryption + authentication).
  • authenticated-sha256 / authenticated-blake3: no encryption, but authentication (tamper detection) using HMAC-SHA-256 resp. keyed BLAKE3.

--id-hash selects the id hash function of the encrypted modes:

  • sha256 (default): HMAC-SHA-256.
  • blake3: BLAKE3. often faster on CPUs without SHA hardware acceleration. so if your CPU is missing that specific hardware swag, blake3 might be your girl 🦋

for the modes that do not encrypt, the hash is not just used for the chunk ids — it also is what protects your data. therefore it is part of the mode name there, and --id-hash does not apply to them. they picked their own hash, they're self-sufficient, we respect it 💅

--key-location selects where the key is stored (orthogonal to the crypto suite — meaning you can mix and match however you want, they're independent choices, bestie):

  • repokey (default): the key is stored in the repository (under keys/). pick this if you want ease-of-use and "passphrase" security is good enough. convenient queen 🎀
  • keyfile: the key is stored in your home directory (in ~/.config/borg/keys). pick this if you want "passphrase and having-the-key" security. double-locked, extra safe, main character security 🔥

you can move the key between these locations later with borg key change-location. this also applies to the authenticated-* modes: they do not encrypt your data, but they still have a key (used for the id hash and the authentication), so --key-location selects where that key is stored, just like for the encrypted modes. same rules, same energy ✨

if you do not want to encrypt the contents of your backups, but still want to detect malicious tampering, use --encryption authenticated-sha256 (or -blake3). these modes are like an encrypted mode minus the data encryption. to normally work with authenticated-* repositories, you will need the passphrase, but there is an emergency workaround; see BORG_WORKAROUNDS=authenticated_no_key docs. 🚨

🧚 Repository defaults 🧚

--compression sets the repository's default compression: the commands that compress data (borg create, borg recreate, borg import-tar, borg transfer, borg repo-compress) use it if no compression was given via --compression, the environment or the default config file (default.yaml). without a repository default, they use lz4. see borg help compression for the compression specs. set it once, have it apply everywhere — it's giving efficiency 💅

--chunker-params sets the repository's default chunker parameters: borg create and borg import-tar use them if no chunker parameters were given (in the same ways as above). borg recreate and borg transfer only rechunk if --chunker-params is given; with --chunker-params default, they rechunk to the repository's default chunker parameters. without a repository default, the built-in default chunker parameters are used. no cap 🫶

this is useful if several clients back up into the same repository or if some commands are run manually: they all compress and chunk the same way without having to give these options. using the same chunker parameters is important for deduplication. borg repo-info shows the defaults. so go look if you're curious, she'll tell you everything 👑

the defaults are stored in the repository and protected by the repository key: changing them (e.g. removing an obfuscate compression) needs the key. the defaults object is always written, also when no default was given, so removing it is noticed, too: the commands refuse to run if it is missing or fails the authentication. borg check reports such an object, borg check --repair replaces it by empty defaults (the built-in defaults are used then). she's strict about this, and honestly? valid 💀

you can use borg repo-create --other-repo ORIG_REPO ... to create a related repository that uses the same secret key material as the given other/original repository. it's like the sibling of your original repo, sharing the family secrets 🧬

by default, only the ID key and chunker secret will be the same (these are important for deduplication) and the AE crypto keys will be newly generated random keys. fresh randomness, but the dedup DNA is shared ✨

optionally, if you use --copy-crypt-key you can also keep the same crypt_key (used for authenticated encryption). this might be desired, for example, if you want to have fewer keys to manage. less admin work = more slay 💅

creating related repositories is useful, for example, if you want to use borg transfer later.

you can use borg repo-create --other-repo ORIG_REPO --from-borg1 ... to create a related repository that uses the same secret key material as the given other/original repository. moving-up-in-the-world energy, we love a glow-up from the old version 💖

then use borg transfer --other-repo ORIG_REPO --from-borg1 ... to transfer the archives. that's the whole migration moment, bestie, you got this 🔥

⭐ OPTIONS ⭐

see borg-common(1) for common options of Borg commands. (that's the shared stuff, this page is just the repo-create-specific tea ☕)

✨ options ✨

  • --other-repo SRC_REPOSITORY — reuse the key material from the other repository. sharing is caring 🫶
  • --from-borg1 — other repository is Borg 1.x. yes, the old era, we still respect her 💜
  • -e ENCRYPTION, --encryption ENCRYPTION — select the mode: 'aes256-ocb', 'chacha20-poly1305', 'authenticated-sha256' or 'authenticated-blake3' (required — cannot skip, she is mandatory, it's giving non-negotiable 👑)
  • -i HASH, --id-hash HASH — select the id hash function of the encrypted modes: 'sha256' or 'blake3'. the 'authenticated-sha256' and 'authenticated-blake3' modes name their hash themselves. they don't need you picking for them, they're independent girls 💅
  • --key-location LOCATION — where to store the key: 'repokey' (in the repository, default) or 'keyfile' (in the local keys directory). pick your girl 🔑
  • -C COMPRESSION, --compression COMPRESSION — set the default compression of the repository, see the output of the "borg help compression" command for details. Default: no repository default (lz4 is used). so if you don't set anything, lz4 is the fallback bestie 🌸
  • --chunker-params PARAMS — set the default chunker parameters of the repository (same format as for borg create). Default: no repository default (fastcdc,19,23,21,2 is used). built-in defaults holding it down ✨
  • --copy-crypt-key — copy the crypt_key (used for authenticated encryption) from the key of the other repository (default: new random key). so you can either keep the shared one or get a fresh random one — your call 🎀

🌸 EXAMPLES 🌸

here's the whole vibe in code form bestie, copy away:

# Local repository
$ export BORG_REPO=/path/to/repo
# Recommended AEAD cryptographic modes (key stored in the repository by default)
$ borg repo-create --encryption=aes256-ocb
$ borg repo-create --encryption=chacha20-poly1305
# No encryption, only authentication (not recommended)
$ borg repo-create --encryption=authenticated-sha256

# For the encrypted modes, --encryption (the cipher / AE algorithm) and --id-hash
# (the id hash function) are chosen independently. --id-hash defaults to sha256;
# use blake3 if it is faster on your hardware (run 'borg benchmark cpu' to find out).
$ borg repo-create --encryption=aes256-ocb --id-hash=blake3
$ borg repo-create --encryption=chacha20-poly1305 --id-hash=blake3

# The 'authenticated-*' modes name their id hash themselves, so they
# do not take a separate --id-hash.
$ borg repo-create --encryption=authenticated-blake3

# Where the key is stored (--key-location) is also chosen independently.
# --key-location defaults to repokey.
# repokey: stores the encrypted key inside the repository
$ borg repo-create --encryption=aes256-ocb --key-location=repokey
# keyfile: stores the encrypted key in the config dir's keys/ subdir
# (e.g. ~/.config/borg/keys/ on Linux, ~/Library/Application Support/borg/keys/ on macOS)
$ borg repo-create --encryption=aes256-ocb --key-location=keyfile
⚠️ reminder bestie: the authenticated-sha256 mode up there is labeled not recommended in the examples — that's right there in the comments, no cap. read the notes, she's telling you something 😭

okay that's part 1, there's more coming so don't go anywhere, we're not done yet 🫶💖

🔗 SEE ALSO 🔗

okay bestie, go read these next, they're all part of the same ✨universe✨:

like, borg-repo-list(1) is literally the vibe check for your shiny new repo, and borg-check(1) is your bestie who tells you if everything's actually okay 🫶

✍️ Author ✍️

The Borg Collective 💅

and that's the whole page, no notes 💖 this lil manual page dropped on 2026-10-07 and lives at borg-repo-create(1) — go make some repos, you absolute icon 👑🌸

📦 where this page comes from