# BorgBackup 2.0 beta: deduplicating backups with authenticated encryption

> BorgBackup splits files into content-defined chunks, stores only chunks it has never seen, and encrypts the result client-side. The master branch is the unstable 2.0 beta, and the README tells you not to use it for production backups.

**borgbackup/borg** — Deduplicating archiver with compression and authenticated encryption.

- Repository: https://github.com/borgbackup/borg
- Website: https://www.borgbackup.org/
- Stars: 13,792 · Forks: 874
- Language: Python
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/borgbackup-borg

## What BorgBackup solves, and who ends up using it

The problem is repeated full backups. If you copy a 200 GB virtual disk image every night and 1 GB of it changed, you spend 200 GB of transfer and storage per night unless something looks inside the file. BorgBackup looks inside. It splits each file into variable-length chunks and adds only chunks whose id_hash value it has not seen before, where the id_hash is a cryptographically strong hash or MAC such as (hmac-)sha256 or (keyed) blake3. The README states that deduplication considers all chunks in the same repository, regardless of which machine, which backup, or which single file they came from. That is the design decision that matters: the unit of reuse is the chunk, not the file.

The consequence is that renaming or moving a directory does not break deduplication, and neither does a timestamp change. A large file that changes slightly costs only the new chunks. Data that shifts position inside a file is still found. This is why BorgBackup shows up in VM image and raw disk backup setups, where naive tools are unusable.

The audience is system administrators, which is the intended audience listed in the project metadata. In practice that means people comfortable with a command line, with SSH keys, and with the idea that a backup repository is a directory tree they must not touch by hand. If you want a graphical wizard, this is not the tool. If you want a nightly job that writes a few hundred megabytes instead of a few hundred gigabytes, it is.

## How deduplication, chunking and encryption actually fit together

A Borg repository is not a mirror of your filesystem. Files are read, cut into chunks by a chunker, hashed, and the chunk is written only if that hash is new. The supported chunkers are fastcdc (the default), buzhash64, the older buzhash from borg 1.x, fixed blocksize, and three keyed AES-based chunkers: toeplitz-aes, rabin-aes and goldilocks-aes. That last group exists for a specific reason stated in the README: keyed chunkers make chunk-boundary fingerprinting attacks much harder. An attacker who can watch repository growth can otherwise infer something about content from where chunk boundaries fall. If your repository lives on a host you do not fully control, the keyed chunkers are the ones worth reading up on.

On top of that sits compression and encryption. Compression options are lz4, zstd, zlib and lzma, spanning fast-and-weak to slow-and-strong. Encryption is client-side, 256-bit authenticated, using AES-OCB or chacha20-poly1305. If confidentiality is not required, authenticated-sha256 and authenticated-blake3 modes authenticate without encrypting, which the README presents as the option for people who only need integrity. There is also an obfuscation feature that actively obscures file and chunk sizes, which is a second layer against the same class of inference attack that the keyed chunkers address.

The performance-critical parts (chunking, compression, encryption) are implemented in C/Cython with SIMD paths (NEON, AVX2, AVX-512) and the scan kernel is picked per platform. Local caching and quick detection of unmodified files are listed as speed features. Those are claims from the README; treat the numbers as something you measure on your own data, because chunk sizes and compression ratios dominate everything here. A repository full of already-compressed media will deduplicate and compress poorly no matter which options you pick, and no amount of SIMD work changes that.

## Installing BorgBackup and running a first backup

The README points to the installation manual at borgbackup.readthedocs.io and to docs/installation.rst in a downloaded tree. It also states that single-file binaries are offered for Linux (x86_64, arm64), macOS (arm64, x86_64), FreeBSD (x86_64) and Windows (x86_64, MSYS2/MINGW borg.exe, experimental), and that these require installing nothing. NetBSD, OpenBSD, illumos/Solaris, Cygwin and WSL are supported through a package or from source rather than a binary. The project metadata requires Python 3.11 or newer for source installs, and lists borghash, borgstore, msgpack, packaging and platformdirs as dependencies.

The README's own example sets a repository path in the environment so you do not repeat it on every command:

```bash
export BORG_REPO=/path/to/repo
```

Creating the repository is where you choose encryption. The README example uses AES-OCB with the key stored in the repository:

```bash
borg repo-create --encryption=aes256-ocb --key-location=repokey
```

Then a first archive. Note the argument order: archive name first, then the path to back up.

```bash
borg create docs ~/Documents
```

Run the same command again with verbose statistics and you should see the deduplication in the numbers. The README's sample output for a second run of the same tree reports 24 files, 29.73 MB original size, and 520 B deduplicated size. That 520 B is the point of the tool: almost nothing was written because almost every chunk already existed. If your second run reports a deduplicated size close to the original size, something is defeating chunking, and the usual suspects are a container format that rewrites its headers on every save or a compression step applied before Borg sees the file.

## The beta warning is not boilerplate

The README for this branch opens by stating that it is the README for unstable Borg2 / master, that the code is in beta testing, that major or breaking changes can land between beta releases, and that there is no beta-to-next-beta upgrade code, so you will have to delete and re-create repositories. It then says, in capitals, not to use Borg2 for production backups, and asks testers to set it up additionally to their production backups.

That is an unusually blunt warning and it should be read literally. The practical failure mode is not corruption. It is that you build a repository, run it for three months, upgrade to the next beta, and discover the repository cannot be opened by the new code and there is no migration path. Your only recovery is the production backup you kept alongside it. The release cadence visible in the repository (2.0.0b22 in July, 2.0.0b23 in August, 2.0.0b24 in September) means that situation can arrive roughly monthly.

A second limitation is platform support. Windows support is described as experimental, and Cygwin and WSL likewise. OpenBSD is listed with no xattrs or ACLs support, and NetBSD and illumos/Solaris with xattrs but no ACLs. If your backup must preserve extended attributes or access control lists on those systems, the metadata will not survive, and that is a property of the platform support, not a bug you can configure away.

## Where BorgBackup fits against restic and plain rsync

The closest comparison in this space is restic, another deduplicating backup tool with client-side encryption and a single binary. The difference in approach shows up in the chunking. BorgBackup exposes the chunker as a choice, including keyed AES-based chunkers designed to resist boundary fingerprinting, and it exposes compression as a choice across four algorithms. The README frames deduplication as repository-wide across machines and archives, which is the property that makes a shared repository between several hosts worthwhile. If you have already chosen restic, the honest reason to look at BorgBackup is that keyed chunker plus the obfuscation feature, not the deduplication itself, which both tools perform.

Against rsync, the difference is more basic. rsync synchronizes a directory tree to another directory tree, and the destination holds the files. BorgBackup stores chunks in a repository and produces named archives you can mount as a user-space file system for browsing and restoring through a normal file manager. That archive model is what lets you keep last week's version of a file after it was overwritten. rsync alone does not give you that unless you build a snapshot scheme around it.

Against a plain tar pipeline, the difference is that BorgBackup decrypts and rehydrates on restore without you writing the reassembly logic, and the repository is append-oriented rather than a single stream you must keep whole. A truncated tar file is often a total loss; a repository with a damaged archive is not necessarily the same situation, though the README does not document a repair procedure in the text available here.

## Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-21, so the code is being worked on. That tells you about activity, not about stability, and the beta warning above is the stability answer.

For a 1.x deployment, the maintenance cost is the usual one for a backup system: you must periodically verify that archives are readable, and you must keep the repository from being modified by anything except Borg. For a 2.0 beta deployment, add the cost of recreating the repository at beta boundaries. If your data set is large, that cost is not small, because re-creating the repository means re-uploading everything the first time, and if your target is object storage or a remote host over a slow link, that first upload is the expensive part.

On licensing, the README states the project is licensed under the BSD 3-clause license and points to the LICENSE file, and the project metadata declares BSD-3-Clause with LICENSE and AUTHORS as the license files. The repository metadata supplied for this page reports the license as NOASSERTION, which is what GitHub shows when it cannot match the files to a known license identifier; the two are not in conflict, but if your organization requires a machine-readable licence field, check LICENSE in the tree rather than trusting the metadata badge. This is not legal advice; a permissive licence still leaves you responsible for export, encryption and data-protection rules that apply to your backups.

## Remote targets and what they change

BorgBackup can store data on a remote host over several protocols: rest:// (REST over stdio over SSH) and http(s):// (REST over TCP), sftp://, s3:// and b2://, and rclone: for the long tail of providers rclone supports. The README notes that significant performance gains can be achieved with the REST protocols by running a remote agent, which requires borg to be installed on the repository server. That is a real deployment decision: a repository server with Borg installed is faster but is now a machine you must patch and manage, while sftp:// against a plain SSH account is simpler but pushes more work through the client.

The s3:// and b2:// targets are object storage, and object storage does not behave like a filesystem. If you are considering those, the thing to verify first is not speed but whether the repository operations Borg needs map cleanly onto the object store's consistency model. The README lists the protocols; it does not document the operational caveats of each one, so plan a restore test against the real target before you trust it.

One more constraint worth naming: the README describes the single-file binaries as requiring no installation, but the REST remote-agent path requires borg on the server. Those two statements pull in opposite directions when you are choosing between a self-contained client and a faster remote setup, and the decision is really about how many machines you are willing to keep updated.

## Conclusion

Adopt Borg 2.0 beta only as an additional test repository next to backups you already trust, and only if you can tolerate deleting and recreating that repository at every beta release, because the README states there is no beta-to-next-beta upgrade code. Stay on the stable 1.x line if you need an upgrade path you can plan around, or if your target is one of the platforms the README lists as experimental. Before you commit disk space, verify three things yourself: that your chosen chunker and encryption mode are accepted by borg repo-create, that your remote protocol (rest, sftp, s3, b2 or rclone) works from the machine that will run the job, and that a restore from a freshly created repository returns files you can open.

## FAQ

### Is BorgBackup free?

Yes. The README states the project is free and open source software licensed under the BSD 3-clause license, and points to the LICENSE file for the complete license text. The project also accepts donations, which are optional.

### How does BorgBackup work?

Each file is split into variable-length chunks, and a chunk is added to the repository only if its id_hash value has not been seen before, where the id_hash is a strong hash or MAC such as (hmac-)sha256 or (keyed) blake3. Deduplication considers all chunks in the same repository, so it works across machines, archives and files. Compression and client-side authenticated encryption are applied on top.

### Does BorgBackup encryption work?

The README states that all data can be protected client-side with 256-bit authenticated encryption using AES-OCB or chacha20-poly1305, which covers confidentiality, integrity and authenticity. If confidentiality is not needed, authenticated-sha256 and authenticated-blake3 modes authenticate without encrypting.

## Sources

- [borgbackup/borg on GitHub](https://github.com/borgbackup/borg)
- [Issues](https://github.com/borgbackup/borg/issues)
- [Project website](https://www.borgbackup.org/)
- [README](https://github.com/borgbackup/borg/blob/master/README.md)
- [Releases](https://github.com/borgbackup/borg/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/borgbackup-borg