borg-compression(1)

🌸 Name 🌸

okay so this is borg-compression — part of the borg backup tool manual set, and it's literally just the page where borg spills every single detail about compression. no cap. 💅

---

✨ DESCRIPTION ✨

first of all, bestie, breathe: it is no problem at all to mix different compression methods inside one repository. like, none. because deduplication is done on the source data chunks — not on the compressed data, and not on the encrypted data. so the vibes stay immaculate. 🫶

now the part that lowkey matters: if some specific chunk was once compressed and stored into the repository, then creating another backup that also uses this chunk will not change the stored chunk. so if you use different compression specs for your backups, whichever one stores a chunk first determines its compression. periodt. (peep borg recreate if you wanna know more about that whole situation 👀)

and if you don't specify a compression via --compression — not on the command line, not in the environment, not in the default config file — then the repository's default compression is used, which you can set with borg repo-create --compression. and if there's no repository default at all? it's just lz4. iconic behavior honestly.

🎀 Valid compression specifiers 🎀

here's the whole menu, bestie, pick your fighter:

• none — do not compress. that's it. that's the whole thing. 🙈
• lz4 — use lz4 compression. very high speed, very low compression. this is the built-in default btw. 👑
• zstd[,L] — use zstd ("zstandard") compression, a modern wide-range algorithm. if you don't explicitly give the compression level L (ranging from -128 to 22), it will use level 3. negative levels are zstd's "fast" levels (level -N is what the zstd command line tool calls --fast=N): they give up compression ratio for speed. -1 to -10 is the useful range for general data; going lower only pays off for data with long repeats (disk/VM images, database files), where it stays fast while still finding the big matches. Level 0 selects zstd's default level (3) — for zstd it does not mean "no compression" (use none for that), unlike for zlib below. not me warning you about that one twice. 😭
• zlib[,L] — use zlib ("gz") compression. medium speed, medium compression. if you don't explicitly give the compression level L (ranging from 0 to 9), it will use level 6. giving level 0 (which means "no compression", but still has zlib protocol overhead) is usually pointless — you're better off just using none compression, fr fr.
• lzma[,L] — use lzma ("xz") compression. low speed, high compression. if you don't explicitly give the compression level L (ranging from 0 to 9), it will use level 6. giving levels above 6 is pointless and counterproductive because it does not compress better due to the buffer size used by borg — but it wastes lots of CPU cycles and RAM. so don't. 💀
• auto,C[,L] — use a built-in heuristic to decide per chunk whether to compress or not. the heuristic tries with lz4 whether the data is compressible. for incompressible data, it will not use compression (uses none). for compressible data, it uses the given C[,L] compression — with C[,L] being any valid compression specifier. this can be helpful for media files which often cannot be compressed much more. slay. 🎀
• obfuscate,SPEC,C[,L] — use compressed-size obfuscation to make fingerprinting attacks based on the observable stored chunk size more difficult. noting:
  • you must combine this with encryption, or it won't make any sense. 🚨
  • your repo size will be bigger, of course.
  • a chunk is limited by the constant MAX_DATA_SIZE (cur. ~20MiB).

the SPEC value determines how the size obfuscation works, and it's giving options:

🔥 Relative random reciprocal size variation (multiplicative)

size will increase by a factor, relative to the compressed data size. smaller factors are used often, larger factors rarely.

available factors:

   1:     0.01 ..        100
   2:     0.1  ..      1,000
   3:     1    ..     10,000
   4:    10    ..    100,000
   5:   100    ..  1,000,000
   6: 1,000    .. 10,000,000

example probabilities for SPEC 1:

   90   %  0.01 ..   0.1
    9   %  0.1  ..   1
    0.9 %  1    ..  10
    0.09% 10    .. 100

🎲 Randomly sized padding up to the given size (additive)

   110: 1kiB (2 ^ (SPEC - 100))
   ...
   120: 1MiB
   ...
   123: 8MiB (max.)

🧚 Padmé padding (deterministic)

   250: pads to sums of powers of 2, max 12% overhead

uses the Padmé algorithm to deterministically pad the compressed size to a sum of powers of 2, limiting overhead to 12%. see https://lbarman.ch/blog/padme/ for details. 💜

---

🌈 Examples 🌈

like, just copy these, bestie:

borg create --compression lz4 --repo REPO ARCHIVE data
borg create --compression zstd --repo REPO ARCHIVE data
borg create --compression zstd,10 --repo REPO ARCHIVE data
borg create --compression zlib --repo REPO ARCHIVE data
borg create --compression zlib,1 --repo REPO ARCHIVE data
borg create --compression auto,lzma,6 --repo REPO ARCHIVE data
borg create --compression auto,lzma ...
borg create --compression obfuscate,110,none ...
borg create --compression obfuscate,3,auto,zstd,10 ...
borg create --compression obfuscate,2,zstd,6 ...
borg create --compression obfuscate,250,zstd,3 ...

---

👑 Author 👑

The Borg Collective 🫶✨

---

that's the whole page, bestie!! 💖 this was borg-compression(1) from the borg backup tool, dated 2026-10-07 — go forth and compress responsibly, mwah 🎀🦋🌸