borg-create(1)

💖 NAME 💖

Hiii bestie 🌸 say hi to borg-create(1) — part of the borg backup tool, and her entire personality is: creating a new archive ✨. That's the job. That's the whole job. She eats every time. 👑

🎀 SYNOPSIS 🎀

borg [common options] create [options] NAME [PATH...]

🦋 DESCRIPTION 🦋

okay so here's the tea 🫖 — this command creates a backup archive containing all the files it finds while recursively traversing every path you handed it. And the way paths get added to the archive is literally just... however you gave them. Which means if you want relative paths in there, you gotta run the command from the correct directory. No cap, that part's on you. 💅

Now, the slashdot hack in paths (aka recursion roots) — it gets triggered by using /./:

/this/gets/stripped/./this/gets/archived

means process that fs object, but strip the prefix on the left side of ./ from the archived items — so in this case this/gets/archived is what ends up being the path in the archived item. slay ✨

If a recursion root (a path you gave on the command line, or one that lives in a patterns file) is a symlink, borg follows it and archives what it points to — using the path you gave. Like, if current is a symlink pointing to the directory 20260801-2345, then:

borg create ARCHIVE current

archives current as a directory (with the metadata of 20260801-2345) and recurses into it, archiving the contained fs objects as current/.... And because the archived paths don't change when the symlink target changes, the files cache keeps working for backups like this. iconic behavior honestly 🧚

⚠️ but heads up bestie — the symlink itself is then not in the archive (and neither is its target path 😭), so restoring will create a real directory (or file) where the symlink used to be. If you want the symlink archived as a symlink, do not give it as a recursion root — let borg find it while recursing (symlinks found that way are never followed, fr fr). And a recursion root that's a symlink with a non-existing target? Skipped, with a warning. 💀

If you give both a symlink and its target as recursion roots, borg archives the fs objects only once, under the path given first — same energy as any other root you gave twice. 💜

When you specify - as a path, borg reads data from standard input and creates a file named stdin in the created archive from that data. In some cases it's more appropriate to use --content-from-command instead — peep the section Reading backup data from stdin below for the details. 🍓

The archive will consume almost no disk space for files or parts of files that have already been stored in other archives. Deduplication queen 👑

The --tag option can add a tag to your new archive. Want multiple tags? Give it multiple times, like --tag foo --tag bar. easy. 💅

Your archive name does not need to be unique — you can and absolutely should use the same name for a whole series of archives. The unique archive identifier is its ID (hash), and you can abbreviate that ID as long as it stays unique. 🔥

In the archive name, you may use these placeholders: {now}, {utcnow}, {fqdn}, {hostname}, {user}, and some others. cute, right? ✨

Backup speed goes up because borg doesn't reprocess files that are already part of existing archives and weren't modified. How does she know? By comparing multiple file metadata values against previous values kept in the files cache. 🧠

The files cache is kept locally, one per archive series. If it's missing (fresh machine, or you yeeted the local cache), borg rebuilds it by reading the archive that this one continues from in the repository. Which archive is that? The newest one having the same archive attributes as given by --group-by — by default, the same series name and the same host. Matching on the series name alone would be wrong in a repository shared by multiple machines or users, because they might use the same series name for their own unrelated data — borg would then rebuild the files cache from a foreign archive, where almost nothing matches, and read and chunk everything all over again. embarrassing for everyone 💀

Give --group-by name if the same series is intentionally written by different hosts and they see the same files. Or add user if one host backs up the same series as different users. But beware of grouping by an attribute that isn't stable over time: if, say, the hostname changes for every backup run (looking at you, containers 👀), borg will never find an archive to rebuild the files cache from. tragic.

This comparison can operate in different modes, as given by --files-cache:

• ctime,size,inode — default on POSIX systems 🌸
• mtime,size,inode — default on Windows 🪟
• ctime,size — ignore the inode number
• mtime,size — ignore the inode number
• rechunk,ctime — all files are considered modified - rechunk, cache ctime
• rechunk,mtime — all files are considered modified - rechunk, cache mtime
• disabled — disable the files cache, all files considered modified - rechunk

🔍 inode number: better safety, but often unstable on network filesystems

Normally, detecting file modifications takes inode information into consideration to improve the reliability of file change detection. But that's problematic for files on sshfs and similar network file systems that don't provide stable inode numbers — those files will always be considered modified 😭. You can use modes without inode in that case to improve performance, but reliability of change detection might be reduced. pick your battles, bestie.

⏰ ctime vs. mtime: safety vs. speed

• ctime is a rather safe way to detect changes to a file (metadata and contents), because it cannot be set from userspace. But a metadata-only change will already update the ctime, so you might get some unnecessary chunking/hashing even without content changes. Also, some filesystems don't support ctime (change time) at all. E.g. doing a chown or chmod on a file will change its ctime.
• mtime usually works and only updates if file contents were actually changed. But mtime can be arbitrarily set from userspace — e.g., setting mtime back to the same value it had before a content change happened. That can be done maliciously or with good intentions, but either way, mtime-based cache modes can be problematic. 😬

On Windows, ctime is the file creation time, not the "metadata change time" it is on POSIX systems. So a ctime-based mode wouldn't notice content changes of a file that keeps its size and inode number — which is exactly why borg defaults to mtime,size,inode there. And if a ctime-based mode is given explicitly on Windows, borg warns and uses the corresponding mtime-based mode instead: ctime,size,inode -> mtime,size,inode, ctime,size -> mtime,size, rechunk,ctime -> rechunk,mtime. noted. 📝

The --files-changed option controls how Borg detects if a file has changed during backup:

• ctime (default on POSIX): Use ctime to detect changes. This is the safest option. Not supported on Windows (ctime is file creation time there).
• mtime (default on Windows): Use mtime to detect changes.
• disabled: Disable the "file has changed while we backed it up" detection completely. This is not recommended unless you know what you're doing, as it could lead to inconsistent backups if files change during the backup process. 🚨

The mount points of filesystems or filesystem snapshots should be the same for every creation of a new archive, so everything stays fast. Why? Because the file cache used to figure out changed files quickly uses absolute filenames. If that's not possible, think about creating a bind mount to a stable location. 🫶

The --progress option shows (from left to right) Original and (uncompressed) deduplicated size (O and U respectively), then the Number of files (N) processed so far, followed by the currently processed path. so aesthetic, so useful. ✨

Sizes of GB and above are shown with enough decimal places that even MB-sized progress stays visible. On a terminal, this needs a width of at least 110 columns — on narrower terminals, the compact format is used so the path stays readable. If the output doesn't go to a terminal (like into a logfile), the precise format is always used. 💅

When using --stats, you'll get some statistics about how much data was added — the deduplicated size there is the most interesting one, because that's how much your repository will grow. And --json outputs the same statistics as JSON. 🔥

When --stats is used together with --dry-run, only the number of files and the original size are reported. They're computed from file system metadata, without reading the file contents, so a dry run stays fast. And since data isn't actually read, chunked, and deduplicated during a dry run, the deduplicated size is unknown. The sizes of data read from standard input, from a command's output, or from special files (--read-special) are also unknown in a dry run and counted as zero. 🤷♀️

The --stats output also reports the store statistics (lines prefixed with Store), taken from the storage layer after this run. These cover the backend and the local store cache: call counts and timings per operation, the load/store data volumes and throughput, and cache hits/misses. Store backend load volume and Store backend store volume are the bytes actually read from and sent to the backend; a load counts only what missed the cache, and a store counts chunk data together with Borg's own index and metadata writes. The values are approximate because of write buffering and caching. And on a repeated backup, a near-zero store volume means almost no new data had to be written — because those chunks already exist in the repository (deduplication, she's that girl 💅).

The Added, Modified and Unchanged file counters come from that files-cache comparison described above: Unchanged files matched the cached metadata and were not read again (their existing chunks are reused); Added and Modified files did not match and were read and chunked (new chunks are stored, already-known chunks are deduplicated). The comparison uses the files cache, keyed by the file's absolute path. 🧚

For more help on include/exclude patterns, see the borg_patterns command output.

For more help on placeholders, see the borg_placeholders command output.

---

✨ OPTIONS ✨

Heads up bestie: the shared/common options that basically every borg command has? Those live in borg-common(1). Go peep that for the group-chat-wide stuff 💅

---

🫶 arguments

• NAME — this is the name you're giving your archive, okay? Pick it, love it, name it like a pet 🐾
• PATH — the paths you actually wanna archive

🎀 options

• -n, --dry-run — do the whole thing in your head only, no actual backup archive gets created. rehearsal mode, no cap 🙈
• -s, --stats — prints out statistics for the archive you just made 📊
• --list — spits out a verbose list of every single item (files, dirs, everything) ✨
• --filter STATUSCHARS — only shows you the items whose status characters match what you asked for (the description section spills the tea on this)
• --json — output your stats as JSON. lowkey implies --stats, so you get both 💖
• --stdin-name NAME — use NAME inside the archive for whatever came in on stdin (default: 'stdin')
• --stdin-user USER — set user to USER in the archive for the stdin data (default: it does NOT store user/uid, just so you know)
• --stdin-group GROUP — set group to GROUP in the archive for the stdin data (default: it does NOT store group/gid)
• --stdin-mode M — set the mode to M in the archive for the stdin data (default: 0660)
• --content-from-command — treat PATH as a command and store its stdout. also go read the section called 'Reading backup data from stdin' below 👀
• --paths-from-stdin — read a DELIM-separated list of paths to back up straight from stdin. all the control is external here: it backs up exactly the files you hand it — no more, no less, fr fr
• --paths-from-command — treat PATH as a command and treat its output as if it were --paths-from-stdin
• --paths-from-shell-command — treat PATH as a shell command and treat its output as if it were --paths-from-stdin
• --paths-delimiter DELIM — sets the path delimiter for --paths-from-stdin, --paths-from-command and --paths-from-shell-command (default: \n)

---

🌸 Include/Exclude options 🌸

• -e PATTERN, --exclude PATTERN — exclude any paths that match PATTERN
• --exclude-from EXCLUDEFILE — read your exclude patterns out of EXCLUDEFILE, one per line 📝
• --pattern PATTERN — include/exclude paths that match PATTERN (you decide which way it goes)
• --patterns-from PATTERNFILE — read your include/exclude patterns from PATTERNFILE, one per line
• --exclude-caches — nope out of directories that contain a CACHEDIR.TAG file (https://www.bford.info/cachedir/spec.html)
• --exclude-if-present NAME — exclude directories that are "tagged" by containing a filesystem object with the given NAME
• --keep-exclude-tags — if you specified tag objects with --exclude-if-present, this keeps those tag objects themselves in the backup archive instead of omitting them 🏷️
• --exclude-dataless — excludes files flagged DATALESS (on macOS these are placeholder files whose content isn't materialized locally, e.g. cloud storage files you haven't downloaded yet ☁️)

---

🦋 Filesystem options 🦋

• -x, --one-file-system — stay within the same file system and don't store mount points belonging to other file systems. but heads up — this might behave differently than you expect, peep the description below 👇
• --numeric-ids — only stores the numeric user and group identifiers, no names
• --atime — yes, do store atime into the archive
• --noctime — do not store ctime into the archive
• --nobirthtime — do not store birthtime (that's the creation date, bestie) into the archive
• --noflags — do not read and store flags (like NODUMP, IMMUTABLE) into the archive
• --noacls — do not read and store ACLs into the archive
• --noxattrs — do not read and store xattrs into the archive
• --sparse — detects sparse holes in the input and seeks over them instead of reading them all. efficient queen behavior ✨
• --digests ALGOS — compute these hash digests over the full content of each file and store them into the archive items. it's a comma-separated list of hash algorithm names, e.g. "blake3", or "none". default: none
• --files-cache MODE — operate the files cache in MODE. default: ctime,size,inode (on Windows: mtime,size,inode, because ctime is the file creation time over there)
• --group-by KEYS — a comma-separated list of archive attributes that identify which archives this archive belongs to; the newest one of them is the archive the files cache gets rebuilt from, if the local files cache is missing. valid keys are: name, host, user; default is: name,host
• --files-changed MODE — specify how to detect if a file has changed during backup (ctime, mtime, disabled). default: ctime (on Windows: mtime, because ctime is the file creation time over there)
• --read-special — opens and reads block and char device files, plus FIFOs, as if they were regular files. also follows symlinks that point to these kinds of files 👀
• --read-special-timeout SECONDS — when reading from FIFOs or character devices (see --read-special): skip the file with an error if no data shows up for more than SECONDS (this includes waiting for a FIFO's writer to connect). give 0 to wait forever. default: 1800 seconds ⏳
• --map MAPFILE — hand over a map file describing the content ranges of the (single) input file, so borg doesn't need to read all of it. see the Input maps section below 🗺️
• --reuse-from ARCHIVE — reuse the chunks of this reference archive for the input map's same ranges (this one requires --map). see the Input maps section below
• --reuse-path PATH — the archive-internal path of the reference item in the --reuse-from archive (only needed if that archive contains more than one file item)

---

👑 Archive options 👑

• --comment COMMENT — add a comment text to the archive 💬
• --timestamp TIMESTAMP — manually specify the archive creation date/time (yyyy-mm-ddThh:mm:ss[(+|-)HH:MM] format, where (+|-)HH:MM is the UTC offset, default: local time zone). alternatively, just give a reference file/directory 📅
• --chunker-params PARAMS — specify the chunker parameters (ALGO, CHUNK_MIN_EXP, CHUNK_MAX_EXP, HASH_MASK_BITS, NC_LEVEL). default: the repository default (see borg repo-create), else fastcdc,19,23,21,2
• -C COMPRESSION, --compression COMPRESSION — select the compression algorithm, see the output of the borg help compression command for all the deets. Default: the repository default (see borg repo-create), else lz4
• --tag TAG — add a tag to the archive (you can pass this one multiple times, stack 'em up 🏷️🏷️)

---

🌈 EXAMPLES 🌈

Note: 📌 Archive series and performance: In Borg 2, archives that share the same NAME form an "archive series". The files cache is maintained per series. For the best performance on repeated backups, reuse the same NAME every single time you run borg create for the same dataset (e.g. always use my-documents). Frequently changing the NAME (for example by embedding date/time like my-documents-2025-11-10) prevents cache reuse and forces Borg to re-scan and re-chunk files, which can make incremental backups vastly slower. Only vary the NAME if you intentionally want to start a new series. If you absolutely must vary the archive name but still want cache reuse across names, see the advanced knobs described in upgradenotes2 (BORG_FILES_CACHE_SUFFIX and BORG_FILES_CACHE_TTL), but the recommended approach is to keep a stable NAME per series. 💖

# Backup ~/Documents into an archive named "my-documents"
$ borg create my-documents ~/Documents

# same, but list all files as we process them
$ borg create --list my-documents ~/Documents

# Backup /mnt/disk/docs, but strip path prefix using the slashdot hack
$ borg create --repo /path/to/repo docs /mnt/disk/./docs

# Backup ~/Documents and ~/src but exclude pyc files
$ borg create my-files                \
    ~/Documents                       \
    ~/src                             \
    --exclude '*.pyc'

# Backup home directories excluding image thumbnails (i.e. only
# /home/<one directory>/.thumbnails is excluded, not /home/*/*/.thumbnails etc.)
$ borg create my-files /home --exclude 'sh:home/*/.thumbnails'

# Back up the root filesystem into an archive named "root-archive"
# Use zlib compression (good, but slow) — default is LZ4 (fast, low compression ratio)
$ borg create -C zlib,6 --one-file-system root-archive /

# Backup into an archive name like FQDN-root
$ borg create '{fqdn}-root' /

# Back up a remote host locally ("pull" style) using SSHFS
$ mkdir sshfs-mount
$ sshfs root@example.com:/ sshfs-mount
$ cd sshfs-mount
$ borg create example.com-root .
$ cd ..
$ fusermount -u sshfs-mount

# Make a big effort in fine-grained deduplication (big chunk management
# overhead, needs a lot of RAM and disk space; see the formula in the internals docs):
$ borg create --chunker-params fastcdc,10,23,16,2 small /smallstuff

# Backup a raw device (must not be active/in use/mounted at that time)
$ borg create --read-special --chunker-params fixed,4194304 my-sdx /dev/sdX

# Backup a sparse disk image (must not be active/in use/mounted at that time)
$ borg create --sparse --chunker-params fixed,4194304 my-disk my-disk.raw

# No compression (none)
$ borg create --compression none arch ~

# Super fast, low compression (lz4, default)
$ borg create arch ~

# Less fast, higher compression (zlib, N = 0..9)
$ borg create --compression zlib,N arch ~

# Even slower, even higher compression (lzma, N = 0..9)
$ borg create --compression lzma,N arch ~

# Only compress compressible data with lzma,N (N = 0..9)
$ borg create --compression auto,lzma,N arch ~

# Use the short hostname and username as the archive name
$ borg create '{hostname}-{user}' ~

# Back up relative paths by moving into the correct directory first
$ cd /home/user/Documents
# The root directory of the archive will be "projectA"
$ borg create 'daily-projectA' projectA

# Use external command to determine files to archive
# Use --paths-from-stdin with find to back up only files less than 1 MB in size
$ find ~ -size -1000k | borg create --paths-from-stdin small-files-only
# Use --paths-from-command with find to back up files from only a given user
$ borg create --paths-from-command joes-files -- find /srv/samba/shared -user joe
# Use --paths-from-shell-command with find to back up a few files from only a given user -
# BE VERY CAREFUL AND ONLY USE TRUSTED INPUT FOR THE SHELL COMMAND!
$ borg create --paths-from-shell-command some-of-joes-files -- "find /srv/samba/shared -user joe | head"
# Use --paths-from-stdin with --paths-delimiter (for example, for filenames with newlines in them)
$ find ~ -size -1000k -print0 | borg create \
    --paths-from-stdin \
    --paths-delimiter "\0" \
    smallfiles-handle-newline

⚠️ bestie, real talk on that --paths-from-shell-command one: BE VERY CAREFUL AND ONLY USE TRUSTED INPUT FOR THE SHELL COMMAND! that's not me being dramatic, that's the man page, she said it 💀

👑 NOTES 👑

Okay bestie, listen up, this is where it gets real. 🫶

The --exclude patterns are not like tar. Not even a little. In tar, --exclude .bundler/gems will exclude foo/.bundler/gems. In borg it will not — you need to use --exclude '*/.bundler/gems' to get that same effect. It's giving "close enough" but it is not close enough. 💅

---

On top of using --exclude patterns, you can also use --exclude-if-present to name a filesystem object (like a file or folder name) which, when it's sitting inside another folder, will stop the containing folder from being backed up. By default, the containing folder and everything in it gets omitted from the backup. But! If you want to only include the objects named by --exclude-if-present in your backup, and not include any other contents of the containing folder, you can turn that on with the --keep-exclude-tags option. ✨

The -x or --one-file-system option excludes directories that are mountpoints (and everything in them, obviously, they're gone). It detects mountpoints by comparing the device number from the output of stat() of the directory and its parent directory. Specifically, it excludes directories for which stat() reports a device number different from the device number of their parent. And in general: be aware that there are directories with a device number different from their parent that the kernel does not consider a mountpoint, and also the other way around. 🙈 Linux examples for this are bind mounts (possibly same device number, but always a mountpoint) and ALL subvolumes of a btrfs (different device number from parent but not necessarily a mountpoint). macOS examples are the apfs mounts of a typical macOS installation. So, when you're using --one-file-system, you should double-check that the backup works as intended. Fr fr, please check. 😭

🏷️ Item flags 🏷️

--list outputs a list of all files, directories and other file system items it considered (no matter whether they had content changes or not). For each item, it prefixes a single-letter flag that indicates type and/or status of the item. Cute little letters, so much info. 🌸

If you're only interested in a subset of that output, you can give e.g. --filter=AME and it will only show regular files with A, M or E status (see below). Slay.

An uppercase character represents the status of a regular file relative to the "files" cache (not relative to the repo — this is an issue if the files cache is not used). Metadata is stored in any case, and for 'A' and 'M' also new data chunks are stored. For 'U' all data chunks refer to already existing chunks. 👑

• 'A' = regular file, added (see also a_status_oddity in the FAQ)
• 'M' = regular file, modified
• 'U' = regular file, unchanged
• 'C' = regular file, it changed while we backed it up
• 'E' = regular file, an error happened while accessing/reading this file

A lowercase character means a file type other than a regular file — borg usually just stores their metadata:

• 'd' = directory
• 'b' = block device
• 'c' = char device
• 'h' = regular file, hard link (to already seen inodes)
• 's' = symlink
• 'f' = fifo

Other flags used include:

• '+' = included, item would be backed up (if not in dry-run mode)
• '-' = excluded, item would not be / was not backed up
• 'i' = backup data was read from standard input (stdin)
• 'x' = skipped due to --exclude-dataless (file is flagged DATALESS)
• '?' = missing status code (if you see this, please file a bug report!)

😭 Errors and (incomplete) archives 😭

If an error happens during archive creation (e.g. some file could not be read due to a permission error or some other OS error), borg will log a warning or an error (depending on the type of issue) and continue with the next item. It's a "we move" situation, but like, log it. 🫶

At the end of the backup, if there were any such issues, borg will exit with a non-zero exit code (usually 1 for warnings).

The archive is still saved even if warnings or errors occurred, but it will only contain the data borg was able to read successfully. So it's not broken, it's just... incomplete. Not the vibe we want.

You should always check the backup logs and the exit code of the borg command. Every single time. No cap. 👀

📥 Reading backup data from stdin 📥

There are two methods to read from stdin. Either specify - as path and pipe directly to borg:

backup-vm --id myvm --stdout | borg create --repo REPO ARCHIVE -

Or use --content-from-command to have Borg manage the execution of the command and piping. If you do so, the first PATH argument is interpreted as command to execute and any further arguments are treated as arguments to the command:

borg create --content-from-command --repo REPO ARCHIVE -- backup-vm --id myvm --stdout

-- is used to ensure --id and --stdout are not considered arguments to borg but rather backup-vm. It's the little bodyguard between them. 🎀

The difference between the two approaches is that piping to borg creates an archive even if the command piping to borg exits with a failure. In this case, one can end up with truncated output being backed up. Using --content-from-command, in contrast, borg is guaranteed to fail without creating an archive should the command fail. The command is considered failed when it returned a non-zero exit code. That's the iconic behavior honestly. 💅

Reading from stdin yields just a stream of data without file metadata associated with it, and the files cache is not needed at all. So it is safe to disable it via --files-cache disabled and speed up backup creation a bit. Free performance, we love to see it. 🔥

By default, the content read from stdin is stored in a file called 'stdin'. Use --stdin-name to change the name. Rename it to something cute, you've earned it. 🦋

🗺️ Input maps 🗺️

Usually, borg reads the complete input to determine its contents. If you already know the contents of parts of the input from an external source of truth, you can give that information via --map MAPFILE and borg will not read the known parts. The primary use case is backing up snapshots of large block devices (e.g. LVM thin volumes), where the storage layer knows which ranges are in use. Main character move: skip the reading you already know about. ⭐

The map file must describe the whole input: one range per line, in the form START LENGTH STATE (byte values, decimal or 0x-prefixed hexadecimal). The ranges must be sorted, non-overlapping and contiguous, starting at offset 0 and covering the exact input size. # starts a comment, empty lines are ignored. STATE is one of:

• data: the range's contents are read and backed up.
• zero: the range is known to read as all-zero bytes. borg stores a hole (all-zero range) of that size without reading the range.
• same: the range is known to be identical to the same range of the input backed up in the --reuse-from REFARCHIVE reference archive (usually: the previous backup of an earlier snapshot of the same device). borg reuses the reference archive's chunks for such ranges without reading them. This state requires --reuse-from.

The map is trusted: if it is wrong (e.g. a range marked zero actually contains data, or a range marked same actually changed), the archive will not match the input and borg cannot detect that. Independently verify the source producing the maps, and consider doing a periodic full read backup (without --map). This is the part where you really double-check your sources, bestie. 💀

For LVM thin volume snapshots, maps can be generated from thin_dump / thin_delta XML with the scripts/lvm-thin-map.py converter from the borg sources; its docstring shows the complete workflow.

--map requires giving exactly one input path, which must be a regular file or (with --read-special) a block device.

The reference archive must contain exactly one file item; if it contains more, select the reference item with --reuse-path PATH (its archive-internal path). Reference chunks that only partially overlap same ranges are re-read from the input, so any chunker gives correct results — but a fixed block size chunker (e.g. --chunker-params fixed,4194304, same parameters as used for the reference archive) avoids re-reading at the edges of changed ranges and gives stable chunk boundaries across backups. Stable boundaries? Obsessed. 🧚

🌈 Feeding all file paths from externally 🌈

Usually, you give a starting path (recursion root) to borg and then borg automatically recurses, finds and backs up all fs objects contained in there (optionally considering include/exclude rules). Borg just handles it, main character energy, we love her. 👑

If you need more control and you want to give every single fs object path to borg (maybe implementing your own recursion or your own rules), you can use --paths-from-stdin, --paths-from-command or --paths-from-shell-command (with the latter two, borg will fail to create an archive should the command fail). You do the finding, borg does the storing. Dream team. 🫶

Borg supports paths with the slashdot hack to strip path prefixes here also. So, be careful not to unintentionally trigger that. 🙈

Symlinks given this way are never followed (unlike recursion roots are), they are archived as symlinks. Noted. Periodt. 💖

---

👀 SEE ALSO 👀

borg-common(1), borg-delete(1), borg-prune(1), borg-check(1), borg-patterns(1), borg-placeholders(1), borg-compression(1), borg-repo-create(1)

✍️ Author ✍️

The Borg Collective — yes the whole collective, they're all in the group chat. 🫶

---

And that's the whole page, bestie!! This was borg-create(1), dated 2026-10-07 (source: borg) — go make an archive, you absolute icon. 💖✨🎀