What compression options does BorgBackup offer?

Updated

BorgBackup offers five compression settings: lz4 for speed, zstd for a balance of speed and size, zlib and lzma for maximum compression, and none to disable compression entirely. You choose one per repository or per archive, so the right pick depends on whether you care more about backup speed, storage space, or CPU load on the machine running the backup.

The available compression options

Borg's own documentation describes the trade-off as a spectrum from fast to maximum squeeze:

Option Emphasis When it tends to fit
lz4 Speed Frequent backups, fast-changing data, low CPU headroom
zstd Balance General-purpose default for most repositories
zlib Compression ratio When space matters more than backup time
lzma Maximum squeeze Archival data, infrequent backups, plenty of CPU time
none No compression Already-compressed data (media, archives, encrypted files)

Borg also lets you tune the level within a compressor (for example, different zstd or zlib levels), so "zstd" is a family of settings rather than a single fixed point.

How compression interacts with deduplication

Compression and deduplication are separate mechanisms that both reduce repository size, and they work on the same content-defined chunks:

  • Borg splits files into content-defined chunks and stores identical chunks only once — across files, machines, and years of history.
  • Compression is then applied to the data that actually gets stored.

Because deduplication already removes repeated chunks, compression mainly shrinks the unique data that remains. The two stack: a nightly full backup costs little more than the changes since yesterday, and those changes are stored compressed.

One practical consequence: if your data is already compressed (photos, video, zip files, most encrypted content), choosing lzma or zlib buys you very little while costing CPU time. In that case lz4, zstd, or none is usually the better trade.

How to choose

Work from the constraint that actually binds you:

  • Backup window too long? Move toward lz4 or a low zstd level.
  • Repository growing too fast? Move toward zstd at a higher level, then zlib, then lzma.
  • CPU is the bottleneck (weak NAS, Raspberry Pi, busy server)? Prefer lz4 or none.
  • Data is already compressed? none avoids wasted CPU for no space gain.
  • Long-term archival, backups run rarely? lzma is reasonable because you pay the CPU cost once per archive.

A common starting point is zstd, then adjust in one direction once you've measured actual backup time and repository size on your own data. Borg's compression setting can be changed later, so you are not locked into an early choice.

What the site confirms

The BorgBackup homepage states the options directly: "Pick your trade-off: lz4 for speed, zstd for balance, zlib and lzma for maximum squeeze — or none at all." It also confirms the surrounding design — content-defined chunking for deduplication, authenticated AES encryption, and mountable archives — and that Borg is BSD-licensed free software installable on Linux, macOS, BSD, and more via distribution packages, single-file binaries, or pip. The site does not publish specific compression ratios or benchmark numbers, so treat any ratio claims as workload-dependent and test on your own data.