A command line archiver that stores deduplicated, compressed and encrypted archives in a repository on local disk or on any host reachable by SSH. It replaces a paid endpoint backup agent with an SSH account and a cron job.
Our verdict on BorgBackup#
The live question for anyone choosing Borg today is Borg 2, and the answer as of September 2026 is: not yet. The current stable series is 1.4, at 1.4.5 (19 July 2026). Borg 2.0 is still in beta, with 2.0.0b24 on 2 September 2026, and the project's own release page says it is in testing and should not be used in production. That matters because 2.0 is a hard break: repositories are not compatible, so you do not upgrade a repo, you run borg transfer --other-repo from the old one into a new one, which needs enough free space for a second copy and requires you to be on borg 1.2.6 or later with the manifest and archive TAM upgrade already applied. Start on 1.4 today. Borg's genuine advantage over restic is that it needs nothing on the server except an SSH account and a borg serve binary, and --append-only on that account gives you ransomware resistance without object storage.
Who BorgBackup is for#
Choose it if
- Someone who already has SSH access to a remote box or a friend's NAS and does not want to introduce object storage into the picture.
- Anyone who wants append-only backups enforced server side: a forced
borg serve --append-onlycommand in authorized_keys means a compromised client cannot erase its history. - Linux and BSD server fleets where the tool is in the distro repository and can be patched by the package manager rather than by you.
- Operators who want a single-writer, strongly consistent repository rather than one that has to tolerate an eventually consistent bucket.
Look elsewhere if
- Your only backup destination is S3 or B2. Borg speaks a repository protocol, not object storage, and bolting on rclone or borgbase-style intermediaries adds a moving part restic does not need.
- You need concurrent backups from several machines into one repository. Borg locks a repository exclusively, so clients queue.
- You want a supported arm64 standalone binary: Borg ships x86-64 PyInstaller builds only, and the ARM binaries linked from the docs are built by a third party.
What running it actually looks like#
Install from your distro (Debian, Fedora, Alpine, Arch and others package it) or use the x86-64 PyInstaller binary from the releases page; there is no official arm64 build, so on a Pi or an ARM VPS you use the distro package or pip. Borg must exist on both ends: the client runs borg, the repository host runs borg serve over SSH, and the versions should match closely or you get protocol complaints. borg init --encryption=repokey-blake2 once, then a cron job that runs borg create, borg prune and borg compact in that order. There is no daemon and no port of its own. Upgrades within 1.x are in place and painless; 1.2 to 1.4 needs no migration steps if you were already on 1.2.5 or later. Going to 2.0 is a repository rewrite, not an upgrade.
Resource profile#
- Memory
- 80 MB idle, around 400 MB in ordinary use. No daemon, so this is footprint during a run. The documented formula is chunk_count * 164 + total_file_count * 240 bytes, and the manual's worked example of 1 million files across 1 TB with default buzhash parameters comes to 0.31 GiB.
- CPU and acceleration
- Chunking plus BLAKE2b or HMAC-SHA256 during backup; compression choice dominates, with `zstd,3` cheap and `lzma` slow enough to halve throughput on a Pi-class CPU.
- Storage growth
- Deduplicated across all archives in a repository, so incremental growth is real new data only. A `borg check --verify-data` reads the whole repository, so size drives verification time more than backup time.
- Operational load
- 2 of 5, Light. A cron job and an SSH target, with no service to keep running and no schema to migrate. The recurring attention is `borg prune` plus `borg compact`, breaking stale locks after killed runs, and the cache resync you pay whenever a second machine touches the same repository.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Two things must survive: the repository and the key. In repokey mode the key is inside the repository and the passphrase unlocks it; in keyfile mode the key lives in ~/.config/borg/keys on the client and is not in the repository at all, so losing that laptop loses every archive. Run borg key export --paper and store it away from both. For integrity, borg check validates repository and archive structure, while borg check --verify-data re-reads and re-hashes every chunk and is the only thing that finds bit rot. Repairs with --repair can discard damaged data, so always run without it first. Restores are per-file; borg mount gives you a FUSE view for pulling a handful of files without a full extract.
Derived backup shape
Mixed. Stop the service, copy its data directory, restart. Check upstream docs for a supported export command first.
Traps and surprises#
Borg 2 is still beta after four years
2.0.0b24 shipped 2 September 2026 and the project still labels the series as testing only, for new repositories, not production. Anyone who read a 2023 article expecting 2.0 shortly should plan on 1.4 for the foreseeable future. The migration is borg transfer --other-repo, which rewrites archives into a new repository, so you need free space for both and a maintenance window proportional to your data, not to your changes.
Cache resync when a second machine uses the repo
Borg keeps a chunks index and files cache under ~/.cache/borg keyed to the repository. If you back up the same repository from a different machine, a different user, or after wiping the cache, Borg has to rebuild that index from the repository, which reads a large amount of metadata and can take a very long time on a big repo over a slow link. Give each client its own repository, or accept the resync.
prune frees nothing until compact runs
In Borg 1.2 and later, borg prune only deletes archive references. Disk space comes back when borg compact rewrites segment files. If your cron job runs create and prune but not compact, the repository grows forever and you will diagnose it as a deduplication failure. Add borg compact as the last step, and note it needs write access, so it cannot run against an append-only repository.
prune patterns can delete another host's archives
borg prune applies its retention rules to every archive in the repository unless you scope it. With multiple hosts sharing one repository, running prune without --glob-archives 'thishost-*' (or --prefix on older versions) will happily apply your 7-daily rule across archives that belong to a machine backing up monthly. Always test with borg prune --dry-run --list after any change to the naming scheme.
Exclusive locks and break-lock
A repository takes an exclusive lock, so one writer at a time and a killed process leaves a stale lock behind. The next run fails with a lock error until you run borg break-lock. Do not automate that blindly: if the original process is genuinely still running on another host, breaking the lock lets two writers into the same repository, which is how you get an inconsistent repo that borg check then has to repair.
Specifications#
- Category
- Backup and object storage
- Licence
- BSD-3-Clause (Permissive)
- Written in
- Python / C / Cython
- First release
- 2015
- Maturity
- Mature
- Datastore
- Its own repository format, plus a local chunks index and files cache under ~/.cache/borg
- Default ports
- none
- Ships as
- distro package, standalone binary (x86-64 only), pipx
- arm64 builds
- No
- Identity
- Not applicable. No accounts and no network service of its own. Authentication is the SSH key you use to reach the repository host, plus the repository passphrase.
- Replaces
- CrashPlan, Backblaze Personal Backup, Acronis True Image, Carbonite
- Project site
- www.borgbackup.org
- Source
- github.com/borgbackup/borg
- Documentation
- borgbackup.readthedocs.io/en/stable
Alternatives to BorgBackup#
Everything else in backup and object storage, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Kopia | 2, Light | 200 MB | Apache-2.0 |
| rclone | 2, Light | 40 MB | MIT |
| restic | 2, Light | 100 MB | BSD-2-Clause |
| Duplicati | 3, Moderate | 200 MB | MIT |
| Garage | 3, Moderate | 150 MB | AGPL-3.0-only |
| MinIO | 4, Heavy | 250 MB | AGPL-3.0 (repository archived) |
Where BorgBackup comes up elsewhere#
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.