restic

Description

restic est un programme de sauvegarde open source, écrit en Go, conçu dès l'origine pour être à la fois rapide, sécurisé et efficace. Son auteur, Alexander Neumann, a voulu résoudre les trois défauts majeurs des outils traditionnels (tar, rsync) : pas de chiffrement natif, pas de déduplication, et des restaurations complexes.

Le secret de restic tient à son architecture en content-addressed storage : chaque fichier sauvegardé est découpé en blobs découpés selon un algorithme CDC (Content-Defined Chunking, buzhash par défaut), puis chaque blob est identifié par son hash SHA-256. Deux fichiers identiques, ou deux versions d'un même fichier qui partagent ne serait-ce qu'un seul bloc, ne stockent physiquement qu'une seule copie du blob en question. Le résultat est une déduplication transversale (entre snapshots) extrêmement efficace, particulièrement sur les workloads de photos, bases de données ou arborescences de code source.

Côté sécurité, toutes les données sont chiffrées côté client avec AES-256-CTR (mode ctr) avant d'être envoyées au backend. L'authentification et l'intégrité reposent sur le hash SHA-256 des chunks et une authentification polynomiale (Poly1305-AES) par fichier. Sans le mot de passe du repository (et éventuellement le keyfile ou les key files ajoutés à un repo), les blobs sont mathématiquement irrécupérables. C'est une propriété essentielle : même le fournisseur de stockage (S3, B2, SFTP…) n'a aucun accès au contenu.

restic supporte nativement une quantité impressionnante de backends : local, sftp, s3 (et donc AWS S3, MinIO, Wasabi, Backblaze B2, Scaleway, OVH, etc.), b2 (API native Backblaze B2), azure, gs (Google Cloud Storage), rclone (et donc tout ce que rclone supporte : WebDAV, S3-compatible, Google Drive, OneDrive, etc.), rest (son propre serveur HTTP), et même un mode stdio pour les pipes. Cette polyvalence explique pourquoi il est devenu le backend d'orchestrateurs comme [[app-backrest]], [[app-kopia]] (en mode repo), ou des solutions SaaS comme [[app-borgbase]] (qui héberge des repos restic et Borg clé-en-main).

Comparé à ses principaux rivaux :

• vs [[app-borg|Borg]] : restic est plus simple à mettre en place, plus rapide à froid (pas de cache local obligatoire), son format est simple et ouvert (on peut l'inspecter avec un peu de Python), mais Borg offre historiquement une compression et une vitesse de reconstitution supérieures. Voir [[app-borg]] pour les détails.
• vs [[app-kopia|Kopia]] : Kopia offre une UI desktop et des snapshot policies plus riches nativement, mais restic reste plus minimaliste, plus scriptable, et dispose d'un écosystème d'orchestration plus large.
• vs [[app-duplicati|Duplicati]] : Duplicati propose une UI web prête à l'emploi, mais repose sur des technologies web plus lourdes (.NET / Mono) et souffre d'une base d'utilisateurs vieillissante ; restic est le choix des sysadmins qui aiment la ligne de commande et les formats ouverts.

Public cible : intermédiaire à avancé. Débutants motivés acceptables (un restic init && restic backup /home suffit pour démarrer), mais la pleine puissance (pruning, hooks, forget --keep-*) demande un peu de lecture.

Installation

Option 1 : Docker Compose (orchestrateur générique)

restic n'a pas besoin d'être servi via Docker pour fonctionner — c'est un binaire qu'on invoque dans des cron, des scripts ou des conteneurs one-shot. On le déploie souvent via un conteneur dédié qui exécute les sauvegardes.

# docker-compose.yml
version: '3.8'
services:
  restic:
    image: restic/restic:latest
    container_name: restic-backup
    restart: unless-stopped
    environment:
      - RESTIC_REPOSITORY=s3:s3.eu-west-3.amazonaws.com/mon-bucket-backups
      - AWS_ACCESS_KEY_ID=AKIAxxxxxxxxxxxxxxxx
      - AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      - RESTIC_PASSWORD_FILE=/run/secrets/restic_password
    secrets:
      - restic_password
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /mnt/data:/data:ro
      - restic-cache:/root/.cache/restic
    command: >
      sh -c "restic snapshots && restic check"
    labels:
      - "traefik.enable=false"

  restic-ui:
    # Backrest : interface web pour piloter plusieurs repos restic
    image: garethgeorge/backrest:latest
    container_name: backrest
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - backrest-data:/data
      - /mnt/backups:/mnt/backups
    ports:
      - "9898:9898"
    environment:
      - BACKREST_DATA=/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.backrest.rule=Host(`backrest.example.com`)"
      - "traefik.http.routers.backrest.entrypoints=websecure"
      - "traefik.http.routers.backrest.tls.certresolver=letsencrypt"

secrets:
  restic_password:
    file: ./secrets/restic_password.txt

volumes:
  restic-cache:
  backrest-data:

Option 2 : Binaire natif (recommandé sur l'hôte)

# Linux (méthode officielle)
sudo apt install restic      # Debian/Ubuntu
sudo dnf install restic      # Fedora/RHEL
brew install restic          # macOS

# Vérification de l'installation
restic version

# Exemple d'init d'un repo S3
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:s3.eu-west-3.amazonaws.com/mon-bucket
export RESTIC_PASSWORD='un-très-long-mot-de-passe-généré-avec-passphrase-generator'

restic init

Configuration

1. Choisir et préparer le backend : créer un bucket S3, un bucket B2, ou un répertoire local/SFTP. Récupérer les credentials (clé d'accès + secret) et noter le endpoint et la région. Le compte de stockage utilisé par restic doit avoir un droit de lecture + écriture + list (et DeleteObject pour le prune).
2. Générer un mot de passe de repo fort : pwgen -s 64 1 ou gpg --gen-random --armor 1 32. Sauvegarder ce mot de passe ailleurs (gestionnaire de mots de passe type Bitwarden/Vaultwarden, papier dans un coffre, etc.) — c'est le seul moyen de restaurer.
3. Initialiser le repo : restic -r s3:bucket/chemin init. Vérifier qu'un fichier config est bien créé côté backend.
4. Premier backup test : restic -r s3:bucket/chemin backup /chemin/important. Inspecter la sortie, vérifier qu'aucune erreur n'apparaît, et lister : restic snapshots.
5. Automatiser : ajouter un cron 0 3 * * * restic backup /home /etc /var/lib --tag daily && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune. Le --prune libère réellement l'espace (sans lui, les blobs orphelins restent sur le backend).
6. Tester la restauration : sur une machine vierge ou un dossier temporaire, restic restore latest --target /tmp/restore puis comparer avec un diff. Les backups non testés ne sont pas des backups.

Alternatives

Open Source

• [[app-borg]] — Plus ancien (2010), format fermé, compression lz4/zstd/lzma, plus rapide sur de gros volumes locaux, mais format non interopérable.
• [[app-kopia]] — UI desktop intégrée, snapshot policies déclaratives, support multi-cloud, format propriétaire (mais ouvert en lecture).
• [[app-duplicati]] — UI web clé en main, multi-backend, idéal pour les non-techniciens, mais projet en perte de vitesse.
• [[app-backrest]] — Orchestrateur web moderne au-dessus de restic : si vous aimez restic mais voulez une UI.
• rclone — Pas un backup tool, mais le backend universel ; très complémentaire de restic via rclone:.

Comparaison des outils CLI / orchestrables

Verdict : restic est le couteau suisse des backups modernes. Si vous êtes à l'aise avec la CLI et que vous voulez un format simple, ouvert et bien outillé, c'est le choix par défaut. Pour une UI prête à l'emploi, regardez [[app-kopia]] (desktop) ou [[app-backrest]] (web au-dessus de restic).

Propriétaires (ce que restic remplace)

• BorgBase — SaaS qui héberge des repos restic/Borg. Pas propriétaire du moteur, mais propriétaire de l'infrastructure.
• Arq Backup — Outil macOS/Windows propriétaire, excellent pour les postes单人, mais pas self-hostable.
• Backblaze Personal — Backup cloud infini clé en main, mais chiffré côté serveur (pas E2E).
• Veeam — Standard entreprise pour VM, mais licence hors de prix pour un homelab.
• Acronis True Image — Référence grand public, propriétaire, fermé.

Backends de stockage (côté où on stocke)

Sécurité

• Chiffrement at-rest et in-transit : AES-256-CTR + Poly1305 côté client, TLS pour le transport vers le backend. Le fournisseur de stockage ne voit jamais les données en clair.
• Mot de passe du repository : c'est la clé du royaume. Le sauvegarder dans un gestionnaire de mots de passe (Bitwarden, KeePassXC, Vaultwarden self-hosted) hors-ligne sur au moins deux supports distincts. Un repo dont on a perdu le mot de passe est une poubelle chiffrée.
• Règle 3-2-1 : 3 copies des données, sur 2 supports différents, dont 1 offsite (ex. : home NAS + disque USB local + B2/Wasabi dans le cloud).
• Test de restauration régulier : programmer un job mensuel qui restaure un snapshot au hasard sur un serveur de test et vérifie son intégrité (restic check couvre la cohérence des blobs, mais pas leur lisibilité applicative).
• Air-gapped backup : un disque USB branché une fois par mois pour un backup local, puis débranché. C'est l'ultime défense contre un rançongiciel qui chiffrerait aussi les partages réseau et les credentials S3.
• Rétention vérifiée : restic check lit tous les blobs et vérifie leur intégrité cryptographique. À lancer au moins une fois par mois (c'est lourd en I/O, ne pas le faire pendant la fenêtre de backup).

Ressources

• Site officiel restic.net
• Documentation officielle
• GitHub restic/restic
• Forum communautaire
• Design principles (lecture recommandée)