---
title: Borg
created: 2026-06-07
updated: 2026-06-07
type: app
tags: [catalogue, backups, deduplication, encryption, compression, borg, snapshot, incremental, versionning, ssh, sftp, docker, python, bsd]
confidence: high
contested: false
sources: [https://selfh.st/apps/?tag=Backups, https://github.com/borgbackup/borg]
---

# 💾 Borg (BorgBackup)

> **Le doyen des backup tools modernes (2010)**, toujours parmi les plus rapides et les plus efficaces sur de gros volumes. Compression, chiffrement, déduplication bloc — tout est dans un seul binaire et un seul format propriétaire (mais bien documenté).

## 📋 Informations Générales

| Champ | Valeur |
| :--- | :--- |
| **Site web** | [borgbackup.readthedocs.io](https://borgbackup.readthedocs.io) |
| **GitHub** | [borgbackup/borg](https://github.com/borgbackup/borg) |
| **License** | BSD-3-Clause |
| **Langage** | Python + extensions C (borgbackup) |
| **Étoiles GitHub** | 13,4k ⭐ |
| **Dernière MAJ** | 2026-06-05 |
| **Catégorie** | [[cat-backups|Backups]] |

## 📝 Description

**BorgBackup** (souvent appelé simplement « **Borg** ») est un **archiveur dédupliqué avec compression et chiffrement**. Le projet a démarré en **2010** sous le nom d'`attic` avant d'être forké en `borg` en 2015, ce qui en fait le **plus ancien** des outils de backup modernes encore largement utilisés (avec `rsnapshot`, qui est très différent). Sa maturité est un de ses grands atouts : l'API est stable, les cas limites sont connus, et la base installée est énorme.

Le cœur de Borg est un **format de repository propriétaire** (`.borg` segments + manifests), optimisé pour la **déduplication bloc-level** au sein d'un même repo. Les fichiers sont découpés en **chunks de taille variable** (algorithme `buzhash`, par défaut 64 KB moyen), puis **chiffrés en AES-256-OCB** (mode OCB depuis 1.1 ; avant c'était AES-CTR, et avant cela AES-CBC). Borg est **plus rapide que restic** sur de très gros volumes locaux grâce à :
- un **cache local** (`~/.cache/borg`) qui accélère drastiquement les incréments,
- une **segmentation** plus efficace,
- un mode de compression configurable (`lz4` par défaut, `zstd` depuis 1.1.4, `zlib`, `lzma`) qui compresse *avant* chiffrement (donc utile, contrairement à restic qui refuse de compresser pour des raisons de sécurité).

Côté backends, Borg supporte nativement : `local`, `ssh` (un agent Borg tourne sur la machine cible, c'est le mode le plus courant pour les serveurs), `sftp` (plus lent que ssh car pas de protocole binaire dédié), et **tout backend supporté par `rclone`** (S3, B2, GCS, Azure, WebDAV…) via le couple `borg mount` / `rclone` ou via des fuse mount. La grosse limitation historique : **pas de backend S3 natif** (il faut un serveur SSH distant ou rclone), ce qui rend Borg moins naturel que [[app-restic]] pour du pur cloud S3.

Le format **Borg est spécifique** : un repo Borg ne peut être lu **que par Borg**. C'est le compromis classique : on gagne en vitesse et en compression, on perd en interopérabilité. Si un jour le projet s'arrête, vos backups deviennent des blobs opaques (même si leur structure interne est bien documentée et qu'un parseur Python tiers existe). [[app-restic]], [[app-kopia]] et [[app-duplicati]] ont tous fait le choix inverse (format spécifique aussi, mais plus simple ou avec une déduplication transversale multi-snapshot plus efficace).

Comparé à ses principaux rivaux :
- **vs [[app-restic]]** : Borg est plus rapide sur de gros volumes (cache local + compression), plus efficace en espace grâce à la compression, mais son format est plus fermé et il n'a pas de backend S3 natif. Pour du **LAN** ou du **SSH vers un serveur dédié**, Borg gagne. Pour du **cloud S3/B2 direct**, restic gagne.
- **vs [[app-kopia]]** : Kopia est plus moderne (2017), plus multi-cloud nativement, et offre une UI desktop. Borg reste plus rapide et plus éprouvé.
- **vs [[app-borg-ui|Borg UI]] et [[app-backrest]]** : Borg n'a pas d'UI officielle. Il faut soit la ligne de commande, soit une UI tierce.

**Public cible** : **intermédiaire à avancé**. Idéal pour les sysadmins qui ont un serveur de backup dédié (NAS Synology, machine Linux, location OVH) et qui sauvegardent des volumes importants.

## 🚀 Installation

### Option 1 : Docker Compose (UI Borg tierce)

Borg lui-même n'est qu'un **binaire Python+C** qu'on invoque depuis un cron. Pour avoir une UI, on s'appuie sur des frontends comme [[app-borg-ui]] ou Borg Web (un projet plus ancien). Voici un exemple avec [[app-borg-ui]] :

```yaml
# docker-compose.yml
version: '3.8'
services:
  borg-ui:
    image: karanhudia/borg-ui:latest
    container_name: borg-ui
    restart: unless-stopped
    environment:
      - BORG_UI_PORT=8081
      - BORG_UI_HOST=0.0.0.0
      - DOCKER_HOST=unix:///var/run/docker.sock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - borg-ui-data:/app/data
      - /mnt/repos-borg:/repos
      - /mnt/source:/source:ro
      - ~/.ssh/mount:/root/.ssh:ro   # clé SSH pour le repo distant
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.borg-ui.rule=Host(`borg.example.com`)"
      - "traefik.http.routers.borg-ui.entrypoints=websecure"
      - "traefik.http.routers.borg-ui.tls.certresolver=letsencrypt"

volumes:
  borg-ui-data:
```

### Option 2 : Binaire natif (méthode recommandée)

```bash
# Debian / Ubuntu
sudo apt install borgbackup

# Fedora / RHEL
sudo dnf install borgbackup

# macOS
brew install borgbackup

# pip (si on veut une version plus récente)
pip install --user borgbackup

# Vérification
borg --version
```

### Exemple d'init + premier backup

```bash
# Repo local
borg init --encryption=repokey-blake2 /mnt/backup-repo
# Repo SSH distant (le plus courant)
borg init --encryption=repokey-blake2 ssh://user@backup-server//path/to/repo

# Premier backup avec compression zstd
borg create --compression zstd ::archive-{now} /home /etc

# Lister les archives
borg list ssh://user@backup-server//path/to/repo

# Restaurer
borg extract ssh://user@backup-server//path/to/repo::archive-2026-06-07
```

## ⚙️ Configuration Initiale

1. **Choisir le mode de chiffrement** :
   - `repokey-blake2` (défaut recommandé) : clé AES stockée dans le repo, protégée par une passphrase. Le hash utilise BLAKE2b.
   - `repokey` : idem mais avec SHA-256.
   - `keyfile` : la clé AES est exportée dans un fichier **à stocker hors-ligne**.
   - `authenticated` : idem `repokey` mais les chunks sont authentifiés (intégrité garantie).
   - `none` : ⚠️ **pas de chiffrement** — à éviter pour tout ce qui sort de la machine.
2. **Initialiser le repo** : `borg init --encryption=... ssh://...` ou `borg init --encryption=... /chemin/local`.
3. **Premier backup test** : `borg create --stats ::test-{now} /chemin/à/sauvegarder`. Inspecter les stats : la taille **compressée** doit être bien inférieure à la taille source si les données s'y prêtent.
4. **Automatiser** : un script bash appelé par cron qui enchaîne `borg create`, `borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6`, et `borg compact` (pour réorganiser le repo après pruning). Le `borg compact` libère réellement l'espace — sans lui, les segments supprimés restent alloués.
5. **Sauvegarder la clé** : si mode `repokey`, exporter la clé (`borg key export`) et la stocker **séparément** (gestionnaire de mots de passe, papier, etc.). Si mode `keyfile`, copier le fichier `key` sur un support hors-ligne.
6. **Tester la restauration** : sur une machine vierge, `borg extract` une archive, puis vérifier l'intégrité de quelques fichiers. Les backups non testés ne sont **pas** des backups.

## 🔄 Alternatives

### Open Source

- [[app-restic]] — Plus moderne, format plus simple, backend S3 natif, mais pas de compression.
- [[app-kopia]] — UI desktop, multi-cloud natif, mais plus jeune.
- [[app-borg-ui]] — UI web simple pour Borg (le projet qui complète cet écosystème).
- [[app-borg-backup-server]] — Orchestrateur pour gérer plusieurs clients Borg depuis un serveur central.
- **Restic** vs **Borg** : choix cornélien classique — voir le tableau ci-dessous.

### Comparaison Borg vs restic vs Kopia

| Critère | Borg | [[app-restic]] | [[app-kopia]] |
| :--- | :--- | :--- | :--- |
| Année de naissance | 2010 (fork d'attic) | 2014 | 2017 |
| Langage | Python + C | Go (pur) | Go (pur) |
| Compression | ✅ lz4, zstd, lzma, zlib | ❌ (délibéré) | ❌ (délibéré) |
| Déduplication | Bloc-level, par archive + transversale | Bloc-level (CDC), transversale | Bloc-level (CDC), transversale |
| Chiffrement | AES-256-OCB + BLAKE2b | AES-256-CTR + Poly1305 | AES-256-GCM |
| Backend S3 natif | ❌ (via rclone) | ✅ | ✅ |
| Backend SSH | ✅ (le plus rapide) | ✅ (SFTP) | ✅ (SFTP) |
| Cache local | ✅ (très efficace) | ❌ | ❌ |
| UI native | ❌ (tiers : [[app-borg-ui]]) | ❌ (tiers : [[app-backrest]]) | ✅ (desktop) |
| Format de repo | Spécifique, fermé | Spécifique, simple | Spécifique, fermé |
| Licence | BSD-3-Clause | BSD-2-Clause | Apache-2.0 |
| `borg check` / équivalent | ✅ très complet | `restic check` | `kopia repository validate` |

**Verdict** : Borg reste **le roi des performances brutes** sur de gros volumes, surtout si on a un serveur SSH dédié et qu'on veut compresser. Pour un homelab qui veut du cloud-first ([[app-restic]] ou [[app-kopia]]) ou une UI ([app-kopia], [[app-backrest]]), on regarde ailleurs. Pour un backup **local** rapide et efficace, Borg est imbattable.

### Propriétaires (ce que Borg remplace)

- **Veeam Backup & Replication** — Le standard entreprise pour VM, mais hors de prix pour un homelab et pas self-hosted simple.
- **Acronis Backup Advanced** — Référence SMB, fermé, licence annuelle.
- **Druva** — Backup cloud SaaS, fermé.
- **Time Machine** (Apple) — Excellent pour les Macs, mais limité à un seul disque/dossier et non scriptable.
- **Windows Server Backup** — Intégré à Windows Server, mais pas cross-platform et pas de cloud natif.

### Backends de stockage (pour un repo Borg)

| Solution | Type | Coût approx. | Idéal pour |
| :--- | :--- | :--- | :--- |
| **Serveur SSH dédié** (Hetzner, OVH) | Local distant | 4-8 € / To / mois (Hetzner Storage Box) | LAN/serveur de backup |
| **BorgBase** | SaaS spécialisé | 3,5-10 € / To / mois | Borg/restic clé en main |
| **Hetzner Storage Box** | NAS distant | 3,5 € / mois / 1 To | EU, SMB |
| **rsync.net** | Stockage SSH/SFTP | 0,025 $ / Go / mois | Pro, EU |
| **Scaleway Stardust** (B2-like) | S3-compatible | 7,5 € / To | EU, via rclone |
| **Disque USB local** | Air-gapped | 50-100 € one-shot | Rançongiciels |

## 🔐 Sécurité

- **Chiffrement AES-256-OCB + BLAKE2b** : par défaut, le repo est **chiffré avant écriture** sur le backend. Même un administrateur du serveur de backup ne peut pas lire les fichiers. Le mode `repokey-blake2` est le **sweet spot** entre sécurité et commodité (la clé est dans le repo, mais protégée par passphrase).
- **Règle 3-2-1** : Borg ne fait pas la politique — c'est à l'utilisateur de la mettre en place. Un setup classique Borg :
  - Backup **local** sur un disque USB branché au serveur (rotation mensuelle, hors-ligne le reste du temps → air-gap contre les rançongiciels).
  - Backup **distant** sur un serveur SSH (Hetzner, OVH, maison de campagne).
  - Pas de backup cloud direct (Borg n'a pas de backend S3 natif), mais on peut mitiger avec rclone.
- **Clé du repo** : si mode `repokey`, exporter la clé (`borg key export repo /tmp/keyfile`) et la stocker **ailleurs** — papier dans un coffre, KeePassXC, Bitwarden. **Un repo sans clé = poubelle chiffrée**.
- **Test de restauration régulier** : programmer un `borg check --verify-data` mensuel (lit *tous* les chunks, donc lent et I/O-intensif) **et** un test de restauration applicative sur un serveur de test.
- **Air-gapped backup** : un disque USB mensuel sorti du serveur est l'ultime défense contre un rançongiciel qui aurait compromis à la fois le serveur principal et le serveur de backup.

## 📚 Ressources

- [Documentation officielle](https://borgbackup.readthedocs.io/)
- [GitHub borgbackup/borg](https://github.com/borgbackup/borg)
- [FAQ / wiki](https://github.com/borgbackup/borg/wiki)
- [Site de la communauté](https://www.borgbackup.org/)
- [BorgBackup support commercial](https://www.borgbackup.com/)

## Pages Liées

- [[cat-backups]] — Catégorie Backups
- [[strategie-backup-321]] — La règle 3-2-1 expliquée
- [[app-restic]] — Concurrent direct, format ouvert
- [[app-kopia]] — Concurrent moderne, UI desktop
- [[app-borg-ui]] — UI web pour Borg
- [[app-backrest]] — UI web pour restic
- [[app-portainer]] — Visualiser les conteneurs
- [[app-traefik]] — Reverse-proxy HTTPS
- [[securisation-home-lab]] — Bonnes pratiques de sécurité
- [[glossaire-homelab]] — Définitions