BorgBackup

Deduplicating encrypted backups

Backup & Recovery BSD-3-Clause Advanced ★ 13,796 stars

What is BorgBackup?

Borg creates encrypted, deduplicated archives locally or over SSH. Because it splits files into content-defined chunks, a daily backup of a large dataset transfers only what actually changed, and each archive is a full browsable snapshot.

Best for

Efficient incremental backups to a repository you control

Why choose BorgBackup

Borg is the mature, battle-tested option for encrypted deduplicated backups, and its chunking algorithm is why. Files are split into content-defined chunks, so inserting a byte at the start of a large file does not invalidate everything after it — only the chunk boundaries that actually changed get retransmitted. The practical effect is that a daily backup of a large dataset transfers far less than the tools that compare whole files. Each archive behaves like a full snapshot that you can browse and restore from selectively, and repository access over SSH makes an offsite copy straightforward without exposing anything to the internet. It has been trusted for long enough that its failure modes are documented rather than discovered.

Replaces

  • Backblaze
  • Carbonite
  • Acronis

Key features

  • Content-defined chunking with global deduplication
  • Authenticated encryption and compression
  • Mount any archive as a filesystem for browsing
  • Prune policies to keep daily, weekly and monthly snapshots

What to watch out for

The repository password is the entire security model — lose it and every archive is unrecoverable, because there is no key escrow by any design. Borg requires its own binary on both ends for remote repositories, which occasionally lags behind a distribution's package version and causes compatibility complaints. Running out of space mid-write can leave a repository needing a repair operation that requires a key or a passphrase, and compaction after pruning is a genuinely time-consuming step. Concurrent access from multiple clients needs locking to be respected, and the append-only mode that protects against a compromised client also prevents pruning from that client. Its compression and chunking behaviour benefit from tuning that most users never do.

How to deploy

  • Install on client and repository host
  • Initialise the repo with a passphrase
  • Script create + prune via cron

Getting started

Initialise the repository and immediately put the passphrase somewhere durable that is not the machine being backed up. Set up the SSH remote for an offsite copy early, because retrofitting an offsite location after months of local-only backups means starting the remote from scratch. Build a prune schedule that includes compaction as a separate step and give it enough time to finish. Enable repository verification on a periodic schedule and confirm it reports no errors. Restore a single file and compare its checksum, rather than assuming a successful backup implies a restorable one. Keep the Borg versions on both ends reasonably aligned before you rely on it.

Typical setup

A repository on a directly attached disk with a second repository over SSH to a remote machine, and the passphrase stored in a password manager with an offline copy. A daily backup runs with an accompanying prune and compact job given enough time to finish. Repository verification runs on a schedule and is checked rather than merely scheduled. Both ends run reasonably matched Borg versions. At least one file restore has been checksummed against the original, and the configuration for the job lives in version control alongside the rest of the server setup.

Who should look elsewhere

Do not choose Borg if you want to back up directly to cloud object storage, because it expects a filesystem or an SSH target and reaching S3 requires a gateway rather than a configuration option. Avoid it if nobody will hold the passphrase securely, since losing it is unrecoverable. And if your data is small enough that full copies are cheap, the deduplication machinery is complexity you will never benefit from.

Project health

  • GitHub stars: 13,796
  • Last code push: 2026-09-29
  • Open issues: 214
  • Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.

More in Backup & Recovery