Learn Borg Backup - History, Background & Why You Need It
Before writing your first command, you need to know where Borg comes from (a fork of Attic in 2010), its design philosophy focused on deduplicating backups, the stable Borg 1.4.x release status and Borg 2.0 still in beta, and the real reasons why dedup- and encryption-based backups matter for servers and everyday workloads.
#Introduction
In episode 0 you set up your environment: borg 1.4.5 is installed and the repository is ready to use. Before writing your first borg create, it is worth understanding where Borg comes from, why it was designed this way, and what real problem it solves. Knowing the background makes you wiser in choosing tools and less easily tempted by irrelevant features.
#History & Philosophy
#A Fork of Attic
Borg started as Attic, a Python backup project created by Jonas Borgström. In 2010, a group of maintainers took the Attic codebase and developed it independently — BorgBackup was born. Borg's core philosophy from the very beginning: deduplicating backup — only the data that actually changed is stored, even though the resulting snapshot appears complete.
Its official tagline is concise and has served as the design compass ever since: "Deduplicated, encrypted, authenticated and compressed backups."
#Release Status: 1.4.x Stable, 2.0 Still Beta
Understanding the Borg version map is important so you do not pick the wrong one in production:
- Borg 1.4.x (stable throughout 2025-2026): the production-ready branch. Borg 1.4.5, released 1 July 2026, is a security release — we dissect its CVEs in episode 15.
- Borg 2.0: still beta (2.0.0b10). The repository format is being overhauled completely. It is interesting to explore, but do not use it in production — we compare the two in episode 17.
Warning
Never manage important data with a beta release. Repos created by Borg 2.0 cannot be read by Borg 1.x and vice versa. For production, use Borg 1.4.5.
#Why Borg
#Deduplication via Content-Defined Chunking
Borg splits files into chunks of variable size determined by the content of the file, not its position. Because chunk boundaries are content-based, a small shift at the start of a file does not trigger changes across the entire file. As a result, daily backups that only change a small portion of data take up very little space. The analogy: adding one line to a 1 GB log file will not re-store the whole 1 GB — only that new line is stored.
#Compression
After dedup, Borg compresses the chunks with zstd, lz4, or zlib (episode 6). Text, log, and config data usually shrinks dramatically, reducing storage space and bandwidth for remote repos.
#Authenticated Encryption
Borg does not just encrypt data — it also ensures data cannot be altered undetected (authenticated encryption). This protects backup integrity, and in episode 13 we add an append-only layer as a defense against ransomware.
#Archive Mount (FUSE)
Borg archives can be mounted as a regular directory with borg mount. No full restore is needed just to look at or grab a single file — we practice this in episode 5.
#Efficient for Daily Backups
The combination of dedup + compression + encryption makes Borg ideal for daily schedules: the time and space required are proportional to the amount of change, not the size of the dataset.
#The Reality: Why We Need Proper Backups
- Ransomware targets data, not just hardware. Backups that are not append-only can be encrypted or deleted too.
- Human error —
rm -rfin the wrong directory — is the most common cause of data loss in the field. - Hardware dies without warning. The annual failure rate (AFR) of a single disk is small, but at the scale of hundreds of disks it is almost guaranteed to happen.
- A backup without a tested restore is not a backup. We will repeat this principle in almost every episode.
The rule of thumb you must remember: 3-2-1 — three copies of your data, on two different media, with one of them off-site.
Note
A good backup is not just "copying files". A good backup offers three properties at once: space efficiency (dedup), security (authenticated encryption), and verifiability (check + test restore). Borg is designed for all three.
#Closing
- Borg was born in 2010 as a fork of Attic, focused on deduplicating backups.
- Its philosophy: Deduplicated, encrypted, authenticated and compressed backups.
- Borg 1.4.5 is stable for production; Borg 2.0 (2.0.0b10) is still beta — avoid it in production.
- Dedup chunking makes daily backups space- and time-efficient.
- Authenticated encryption, FUSE mount, and efficiency are the main reasons to choose Borg.
In episode 2 we get to the technical core: core concepts & key architecture — the difference between a repository and an archive, how content-defined chunking works, the role of the key, and the Borg subcommand map. This is the foundation that makes every later episode feel light.