BO

BorgBackup

Deduplicating archiver with compression and encryption

Backup & Recovery ★ 13.8k stars Medium setup BSD-3-Clause

BorgBackup is a deduplicating backup program with compression and authenticated encryption for efficient, secure archives. It targets technical users backing up to local or remote storage. It is deployed as a binary or package.

BorgBackup setup guides & articles

Hands-on coverage of BorgBackup from the blog.

Key features

  • Deduplication and compression
  • Authenticated encryption
  • Append-only repos for ransomware safety
  • Efficient remote backups over SSH

Pros & cons

Strengths

  • Excellent space efficiency
  • Strong security
  • Battle-tested

Trade-offs

  • Command-line oriented
  • Repo not directly mountable everywhere

BorgBackup replaces

Last reviewed Aug 26, 2026 · 839 words

Lose the repository key and passphrase and every byte of a BorgBackup repository is indistinguishable from noise. That is the whole point of authenticated encryption, and it is also the failure mode I see most often: a disk dies, the repo is safe on a remote host, and the only copy of the key was on the disk that died. Run borg key export /path/to/repo borg-key.txt the day you create a repository, print it, and store the passphrase in a password manager you do not back up with Borg. Everything below is secondary to that.

Three commands cover most of what you will ever do

Initialise once, create nightly, prune and compact weekly:

borg init --encryption=repokey-blake2 ssh://[email protected]:23/./borg/laptop
borg create --stats --compression zstd,3 \
  ssh://[email protected]:23/./borg/laptop::'{hostname}-{now:%Y-%m-%d}' \
  /home /etc --exclude '/home/*/.cache'
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 ssh://.../borg/laptop
borg compact ssh://.../borg/laptop

repokey-blake2 stores the key inside the repository (protected by the passphrase) and uses BLAKE2 for machines without AES hardware acceleration; on a modern x86 box repokey with AES is fine too. borg prune marks archives for deletion; since Borg 1.2 you must run borg compact afterwards or the space is never reclaimed. The 256 MB minimum in the catalogue is realistic for a client backing up a laptop; the chunk index grows with repository size, so a multi-terabyte repo wants more.

Deduplication is why it fits the budget

Borg splits files into variable-size chunks by content, not by position, so a renamed or moved file costs nothing, and a large file that changes at the start does not re-upload its tail. Chunks are compressed (zstd is the sensible default) and encrypted before they leave the machine. The practical effect is that daily snapshots of a home directory for a year usually take a modest multiple of the live size rather than 365 copies. Borg prints the ratio in --stats output; check it once and stop worrying. The BorgBackup vs restic comparison covers where restic's cloud-native storage beats Borg's SSH-only model.

Append-only is the ransomware answer

A client that can delete archives can be made to delete archives. Borg's fix is server-side: restrict the SSH key so the remote can only append. On the storage host, in ~/.ssh/authorized_keys:

command="borg serve --restrict-to-path /srv/borg/laptop --append-only",restrict ssh-ed25519 AAAA... backup@laptop

With that in place, a compromised client can write garbage but cannot remove history. The trade is that prune and compact from that client silently do nothing; run them from a second, trusted key on a schedule, or flip the flag off for a maintenance window. Pair this with the 3-2-1 backup rules and a stolen laptop becomes an inconvenience.

Where to put the repository

Borg speaks two transports: local filesystem and SSH. That rules out S3 and Backblaze B2 directly, and it is the single biggest reason people choose restic instead. What works well: a Hetzner Storage Box (Borg over SSH is supported natively, about 4 euros a month for 1 TB at last check), BorgBase (built around Borg, with a small free tier), a Raspberry Pi at a relative's house running borg serve, or a USB disk for the local copy. Two of those, not one.

Restoring is borg extract for a full archive or borg mount repo::archive /mnt/restore to browse with FUSE and copy back single files. FUSE mounting is the piece the catalogue flags as not available everywhere; on macOS it needs macFUSE, and inside minimal containers it is often absent.

Borgmatic turns it into a cron job you stop thinking about

borgmatic wraps the commands above in one YAML file with retention, checks, hooks for database dumps, and a healthcheck ping:

source_directories:
  - /home
  - /etc
repositories:
  - path: ssh://[email protected]:23/./borg/laptop
    label: hetzner
compression: zstd,3
keep_daily: 7
keep_weekly: 4
keep_monthly: 12
checks:
  - name: repository
    frequency: 2 weeks
healthchecks:
  ping_url: https://hc-ping.com/your-uuid

borgmatic --verbosity 1 from a systemd timer or cron, and the missing-ping alert from Healthchecks tells you when it stops working, which it eventually will. Vorta is the desktop GUI if you want one; Backrest is the equivalent for restic.

What I'd do

Repokey-blake2 repository on a Hetzner Storage Box behind an append-only SSH key, a second repository on a local USB disk, borgmatic on a nightly timer with a Healthchecks ping, borg check every two weeks, and one real restore into a scratch directory each quarter. Exported key on paper. That setup has been running unchanged on my machines for years, and the only maintenance it asks for is reading the release notes before a major version bump.

Compare BorgBackup

23 head-to-head comparisons.

Similar backup & recovery apps