vellis/wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bda02d587f9bf05f2e0b9b9a2d9c627157326057
wiki/Catalogue-Self-Hosted/apps/app-borg.md
T
vellis bda02d587f Initial vault setup
2026-06-09 18:40:21 +02:00

13 KiB
Raw Blame History

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
GitHub 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

📝 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 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 :

# 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)

# 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

# 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

Pages Liées

Reference in New Issue View Git Blame Copy Permalink