13 KiB
title: restic created: 2026-06-07 updated: 2026-06-07 type: app tags: [catalogue, backups, deduplication, encryption, cloud, s3, b2, sftp, s3, restic, snapshot, incremental, versionning, cli, docker, go] confidence: high contested: false sources: [https://selfh.st/apps/?tag=Backups, https://github.com/restic/restic]
💾 restic
Le standard de facto des backups chiffrés et dédupliqués en ligne de commande : rapide, sécurisé, multi-backend, et son format de repo ouvert a inspiré toute une génération d'outils.
📋 Informations Générales
| Champ | Valeur |
|---|---|
| Site web | restic.net |
| GitHub | restic/restic |
| License | BSD-2-Clause |
| Langage | Go |
| Étoiles GitHub | 33,9k ⭐ |
| Dernière MAJ | 2026-06-05 |
| Catégorie | [[cat-backups |
📝 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 : 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 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 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 Initiale
- 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
DeleteObjectpour leprune). - Générer un mot de passe de repo fort :
pwgen -s 64 1ougpg --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. - Initialiser le repo :
restic -r s3:bucket/chemin init. Vérifier qu'un fichierconfigest bien créé côté backend. - 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. - 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--prunelibère réellement l'espace (sans lui, les blobs orphelins restent sur le backend). - Tester la restauration : sur une machine vierge ou un dossier temporaire,
restic restore latest --target /tmp/restorepuis 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
| Critère | restic | app-borg | app-kopia | app-duplicati |
|---|---|---|---|---|
| Langage | Go | Python (C ext.) | Go | C# / Mono |
| Déduplication | Bloc (CDC) | Bloc (fixed + variable) | Bloc (CDC) | Bloc |
| Chiffrement | AES-256-CTR + Poly1305 | AES-256-OCB | AES-256-GCM | AES-256 |
| Compression | Non (délibéré) | lz4 / zstd / lzma | Non (délibéré) | zstd |
| UI native | Non (CLI pur) | Non (BorgWeb / app-borg-ui) | UI desktop | UI web |
| Backends | 12+ natifs | local, ssh, sftp, rclone | local, S3, B2, GCS, Azure, SFTP | 20+ (S3, B2, GCS, SSH, WebDAV…) |
| Format du repo | Ouvert, simple | Borg (spécifique) | Kopia (propriétaire) | Duplicati (propriétaire) |
| Licence | BSD-2-Clause | BSD-3-Clause | Apache-2.0 | LGPL-2.1 |
| Pruning intégré | forget --prune |
prune |
policy |
Intégré UI |
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)
| Service | Coût (~$ / To / mois) | Hot tier | Egress | Idéal pour |
|---|---|---|---|---|
| Backblaze B2 | 6 $ | Oui | 10 $ / To | Homelab, petits volumes |
| Wasabi | 7 $ (pas d'egress) | Oui | 0 $ | Backups volumineux, lectures fréquentes |
| AWS S3 Standard | 23 $ | Oui | 90 $ / To | Pro, intégration AWS |
| AWS S3 Glacier IR | 3,9 $ | Oui (latence ms) | 10 $ / To | Archives consultées rarement |
| AWS S3 Glacier Deep Archive | 0,99 $ | Non (12h) | 0,10 $ / To | Cold storage long terme |
| Scaleway Object Storage | 7,5 $ | Oui | 0,01 € / Go | EU, souverain |
| OVH Object Storage | 7,2 € | Oui | trafic sortant facturé | EU |
| MinIO (self-hosted) | Coût serveur | Oui | 0 $ | 100% on-prem |
🔐 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 checkcouvre 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 checklit 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)
Pages Liées
- cat-backups — Catégorie Backups
- strategie-backup-321 — La règle 3-2-1 expliquée
- app-borg — Concurrent historique, format fermé
- app-kopia — Concurrent avec UI desktop
- app-duplicati — Concurrent avec UI web
- app-backrest — UI web moderne au-dessus de restic
- app-borg-ui — UI web pour Borg
- app-portainer — Pour visualiser les conteneurs qui tournent
- app-traefik — Reverse-proxy pour exposer l'UI Backrest
- securisation-home-lab — Bonnes pratiques de sécurité
- glossaire-homelab — Définitions (CAS, S3, B2, etc.)