How BorgBackup Protects Backup Data with Encryption

Updated

BorgBackup encrypts every chunk it stores using AES with cryptographic authentication, so the repository only ever contains ciphertext. The practical consequence: the machine holding your backups never needs to be trusted, because it cannot read or undetectably alter what it stores. This applies to any repository you create with encryption enabled — local disk, USB drive, or a remote host reached over SSH.

What "authenticated encryption" means here

Borg combines two properties in one step:

  • Encryption (confidentiality): data is unreadable without your key.
  • Authentication (integrity): each chunk carries a cryptographic tag. If a chunk is modified, truncated, or swapped, Borg detects it and refuses to use it.

That second property is what separates Borg from tools that only encrypt. A malicious or compromised backup server sees ciphertext, and if it tries to tamper with it, the tampering surfaces as a verification failure rather than silently corrupting your restore.

Why the backup server doesn't need to be trusted

The page states this directly: "Your backup server never needs to be trusted — it only ever sees ciphertext."

The mechanism behind that claim:

  1. Borg splits your files into content-defined chunks on the client.
  2. Each chunk is encrypted and authenticated before it leaves the client.
  3. The repository (local or remote) stores only those encrypted chunks.

So a remote host running borg serve handles opaque blobs. It can enforce quotas and access rules, but it has no path to your plaintext and no key material.

Encryption works together with deduplication and compression

These three features are not separate modes — they operate in the same pipeline:

Stage What happens Effect
Chunking Files split into content-defined chunks Identical chunks identified
Deduplication Identical chunks stored once across files, machines, and history Space savings
Compression Chunk compressed (lz4, zstd, zlib, lzma, or none) Smaller storage
Encryption Compressed chunk encrypted + authenticated Confidentiality and integrity

A detail worth understanding: deduplication happens on chunk content, so identical data still collapses to a single stored copy even though each copy is encrypted. You get the space savings and the confidentiality at the same time.

What this means for your setup decisions

  • You can use an untrusted remote host. A VPS, a friend's server, or a shared machine is viable because it only stores ciphertext.
  • Losing your key means losing your data. Encryption is only as recoverable as your key management. Store the passphrase or keyfile somewhere separate from the repository.
  • Integrity checking is built in. You can verify a repository and detect tampering or bit rot without decrypting everything by hand.

The one-command starting point

The page frames setup as a single command: point Borg at a repository — local disk, USB drive, or any machine reachable over SSH — and go. No daemons, no agents, no lock-in. Encryption is configured when the repository is initialized, so the protection described above is in place from the first backup onward.

For the exact borg init encryption modes and their trade-offs, the install and documentation pages on borgbackup.org are the authoritative source, since available modes and defaults can change between series.