BorgBackup — Deduplicating Archiver for Efficient Encrypted Backups

Introduction

Borg (borgbackup) is the backup tool many sysadmins reach for when they need deduplication + encryption + efficiency. Unlike dumb tar+gzip backups, Borg splits files into content-defined chunks, stores each unique chunk once across all backups, encrypts them, and lets you mount any snapshot as a filesystem to browse.

With over 13,000 GitHub stars, Borg is the foundation of several hosted backup services (BorgBase, rsync.net's Borg storage, hetzner storage box). It's battle-tested at scales from laptops to multi-TB production servers.

What Borg Does

Borg splits files into variable-size chunks (content-defined chunking), hashes each chunk, and stores unique chunks in a repository. Metadata (filesystem tree, permissions, timestamps) is stored separately. Subsequent backups only upload new or changed chunks. Encryption (authenticated AES-CTR + HMAC) protects data + metadata; compression (LZ4 / Zstd / LZMA) shrinks it further.

Architecture Overview

Source filesystem
      |
[chunker — content-defined chunking]
   splits into variable-size chunks (~2MB avg)
      |
[dedup]
   SHA256 content hash determines chunk identity
   unique chunks stored once across ALL backups
      |
[compression]
   lz4 / zstd / lzma / none
      |
[encryption]
   AES-256-CTR + HMAC-SHA256 (or Blake2 keyed)
      |
[storage]
   local directory or SSH remote
   append-only mode available for immutability
      |
[archive metadata]
   tree structure, timestamps, permissions
   stored per archive (snapshot)

Self-Hosting & Configuration

# A production-ready wrapper script (or use `borgmatic` YAML config)
#!/bin/bash
set -euo pipefail
export BORG_PASSPHRASE="your-long-random-passphrase"
export BORG_REPO="user@backup-server:/backups/myserver"

borg create \
  --verbose --stats --show-rc --compression zstd,3 \
  --exclude-caches \
  --exclude '*.tmp' --exclude '/var/cache' --exclude '/home/*/.cache' \
  ::'{hostname}-{now}' \
  /home /etc /root /var/lib /var/www

borg prune --verbose --list \
  --prefix '{hostname}-' \
  --keep-daily 14 --keep-weekly 8 --keep-monthly 12

borg compact      # reclaim disk on the repo (Borg 1.2+)

# Restore a whole tree
borg extract ::myserver-2026-04-10 home/alice

# Mount a snapshot to browse it
borg mount ::myserver-2026-04-10 /mnt/snapshot
ls /mnt/snapshot/home/alice
borg umount /mnt/snapshot

# /etc/borgmatic/config.yaml (borgmatic simplifies borg operations)
repositories:
  - path: user@backup-server:/backups/myserver
source_directories:
  - /home
  - /etc
  - /var/lib
exclude_patterns:
  - '*.tmp'
  - '/var/cache'
storage:
  encryption_passcommand: pass borg/passphrase
  compression: zstd,3
retention:
  keep_daily: 14
  keep_weekly: 8
  keep_monthly: 12
consistency:
  checks:
    - name: repository
      frequency: 2 weeks
    - name: archives
      frequency: 1 month

Key Features

• Deduplication — content-defined chunking, chunks stored once across all archives
• Encryption — AES-256 + HMAC, key stored in repo or separately
• Compression — LZ4 (fast), Zstd (balanced), LZMA (small)
• Append-only mode — backup clients can't delete old archives (ransomware resilience)
• Mountable — FUSE-mount any snapshot and browse it
• Prune policy — keep N daily/weekly/monthly/yearly automatically
• SSH transport — backup over SSH to any server running borg
• Scriptable — plain CLI, exit codes, JSON output for tooling

Comparison with Similar Tools

FAQ

Q: Borg vs Restic? A: Both are excellent. Borg is slightly faster and more memory-efficient; Restic has native cloud backends (S3, B2, Azure) without going through SSH/rclone. Pick Borg for Linux servers with dedicated backup hosts; Restic for cloud-target backups.

Q: Is the encryption trustworthy? A: Yes — audited, actively maintained. Use a strong passphrase (high entropy) and store it separately from backups (password manager).

Q: How much bandwidth do incremental backups use? A: Only new/changed chunks. Typical second-and-subsequent backups transfer 0.1%-2% of the source size. First backup is always full.

Q: What about huge files that change in the middle (VM images, databases)? A: Borg handles them well thanks to content-defined chunking — only the changed chunks are uploaded. For live databases, still dump them first (pg_dump, mysqldump) for consistency.

Sources

• GitHub: https://github.com/borgbackup/borg
• Docs: https://borgbackup.readthedocs.io
• License: BSD-3-Clause