Sauvegardes 3-2-1 avec Restic

Une sauvegarde ne vaut que par la restauration qu’elle permet. Ce cours s’adresse aux administrateurs, techniciens et dirigeants de PME qui veulent passer d’une copie « au cas où » à une véritable stratégie de sauvegarde, capable de résister à une panne matérielle, à une erreur de manipulation ou à un rançongiciel. Il présente la règle 3-2-1, les notions de RPO et de RTO, puis la mise en œuvre concrète avec restic, un outil libre de sauvegarde chiffrée et dédupliquée. Les commandes présentées correspondent à restic 0.19.1 (publiée le 5 juillet 2026) sur Ubuntu Server 24.04 LTS ; elles fonctionnent de la même façon sur Debian, Windows et macOS, aux chemins près.

À retenir dès maintenant : une sauvegarde qui n’a jamais été restaurée n’est qu’une hypothèse. Ce cours insiste donc, à chaque étape, sur la façon de vérifier que la sauvegarde fonctionne réellement.

1. Pourquoi sauvegarder : menaces et objectifs

Les données d’une PME disparaissent rarement de façon spectaculaire. Le plus souvent, c’est un disque qui lâche, un fichier écrasé par erreur, une synchronisation qui propage une suppression, un poste volé ou un serveur chiffré par un rançongiciel. Dans ce dernier cas, les attaquants cherchent systématiquement à détruire les sauvegardes accessibles depuis le réseau avant de déclencher le chiffrement : une sauvegarde joignable avec les mêmes identifiants que la production a de fortes chances de disparaître avec elle.

Avant de choisir un outil, il faut fixer deux objectifs mesurables avec la direction :

• RPO (Recovery Point Objective) : la perte de données maximale acceptable, exprimée en durée. Un RPO de 24 heures signifie qu’on accepte de perdre une journée de travail ; il impose au moins une sauvegarde par jour.
• RTO (Recovery Time Objective) : la durée maximale d’interruption acceptable avant le retour du service. Un RTO de 4 heures impose que la restauration complète (matériel, système, données) tienne dans ce délai, ce qui se vérifie uniquement par un exercice.

Ces deux valeurs varient selon les données : la comptabilité, la messagerie et les plans d’un bureau d’études n’ont pas la même criticité que les archives d’un ancien projet. Le premier travail consiste donc à dresser l’inventaire des données, de leur emplacement et de leur propriétaire métier.

La sauvegarde a aussi une dimension réglementaire. Le RGPD impose de garantir la disponibilité et la résilience des traitements de données personnelles et de pouvoir les rétablir « dans des délais appropriés » en cas d’incident (article 32) ; les entités concernées par la directive NIS 2 doivent intégrer la gestion des sauvegardes à leur continuité d’activité. À l’inverse, conserver indéfiniment des données personnelles dans des sauvegardes contrevient au principe de limitation de la durée de conservation : la politique de rétention doit être définie, documentée et appliquée.

2. La règle 3-2-1 et ses variantes

La règle 3-2-1 résume en trois chiffres une stratégie robuste :

• 3 copies des données : l’original de production et deux sauvegardes ;
• 2 supports différents : par exemple un serveur de sauvegarde sur disques et un disque externe, ou un NAS et un stockage objet, afin qu’un même défaut ne touche pas toutes les copies ;
• 1 copie hors site : dans un autre bâtiment ou chez un hébergeur, pour survivre à un incendie, un dégât des eaux ou un vol.

Face aux rançongiciels, la règle s’est enrichie en 3-2-1-1-0 : une copie supplémentaire hors ligne ou immuable (disque déconnecté, bande, dépôt en ajout seul), et zéro erreur lors des vérifications de restauration. Le guide de l’ANSSI « Sauvegarde des systèmes d’information – Les fondamentaux » (ANSSI-BP-100, 2023) recommande lui aussi trois copies sur deux types de supports dont une hors ligne, ainsi que des tests de restauration réguliers et documentés.

Schéma type pour une PME : le serveur de fichiers (copie 1) est sauvegardé chaque nuit vers un serveur de sauvegarde situé dans une autre salle (copie 2), dont le contenu est recopié chaque semaine vers un disque externe rangé hors des locaux ou vers un stockage distant (copie 3). Une flèche à sens unique part de la production vers les sauvegardes : la production n’a pas le droit d’effacer ce qu’elle a déposé.

3. Types de sauvegarde : ce qu’il faut savoir

Les outils classiques distinguent trois modes :

• Complète : toutes les données sont copiées à chaque fois. Simple à restaurer, coûteuse en temps et en espace.
• Incrémentale : seules les modifications depuis la dernière sauvegarde sont copiées. Rapide, mais la restauration nécessite de rejouer la chaîne complète.
• Différentielle : les modifications depuis la dernière complète sont copiées. Compromis entre les deux.

On distingue également la sauvegarde par image, qui copie un disque entier bloc par bloc et permet de redémarrer une machine telle quelle (c’est le domaine d’outils comme Clonezilla), de la sauvegarde par fichiers, plus souple pour restaurer un document isolé. Les deux sont complémentaires : l’image accélère la reconstruction d’un système, la sauvegarde de fichiers protège les données qui changent tous les jours.

Piège fréquent : une synchronisation (OneDrive, rsync miroir, réplication RAID) n’est pas une sauvegarde. Elle recopie fidèlement les suppressions et les fichiers chiffrés par un rançongiciel. Une sauvegarde conserve un historique de versions que la production ne peut pas modifier.

Restic dépasse cette classification : chaque sauvegarde produit un instantané (snapshot) qui se restaure comme une sauvegarde complète, alors que seules les données nouvelles sont réellement transférées et stockées, comme dans une incrémentale « perpétuelle ».

4. Restic : principes et architecture

Restic est un programme unique, écrit en Go, distribué sous licence BSD 2-Clause. Il n’a pas besoin d’agent ni de serveur dédié : il lit les fichiers à sauvegarder et écrit dans un dépôt (repository), qui peut être un dossier local, un serveur SFTP, un serveur REST ou un stockage objet compatible S3.

Le dépôt est organisé en quelques répertoires :

• config : fichier chiffré contenant la version du dépôt, son identifiant et le polynôme de découpage ;
• keys : les fichiers de clés, chacun protégé par un mot de passe ;
• data : les fichiers « pack » qui regroupent les blocs de données chiffrés ;
• index : la table qui indique dans quel pack se trouve chaque bloc ;
• snapshots : un fichier par instantané (date, hôte, chemins, étiquettes, arbre racine) ;
• locks : les verrous qui évitent que deux opérations incompatibles s’exécutent en même temps.

La déduplication repose sur un découpage dépendant du contenu (Content Defined Chunking) à l’aide d’empreintes de Rabin. Les fichiers de moins de 512 Kio sont stockés d’un seul bloc ; les autres sont découpés en blocs de 512 Kio à 8 Mio, d’environ 1 Mio en moyenne. Chaque bloc est identifié par son empreinte SHA-256 : un bloc déjà présent dans le dépôt n’est jamais envoyé une deuxième fois, même s’il provient d’un autre fichier, d’un autre dossier ou d’une autre machine sauvegardée dans le même dépôt. Comme les frontières des blocs dépendent du contenu et non de leur position, insérer quelques octets au début d’un gros fichier ne modifie que les blocs voisins.

La compression est disponible depuis le format de dépôt version 2 (version par défaut depuis restic 0.14). Les blocs sont compressés avec zstd. L’option --compression accepte notamment auto (par défaut, très rapide), max et off ; restic 0.19 a ajouté les niveaux fastest et better.

Pour aller plus loin dans la comparaison des outils de cette famille, Kopia repose sur les mêmes principes (instantanés, déduplication, chiffrement côté client) avec une interface graphique ; restic se distingue par sa simplicité et sa stabilité en ligne de commande, très adaptées à l’automatisation sur serveur.

5. Chiffrement et gestion des clés

Toutes les données écrites dans le dépôt sont chiffrées avant de quitter la machine : AES-256 en mode compteur, authentifié par Poly1305-AES. Le stockage de destination (hébergeur, NAS, prestataire) ne voit que des fichiers opaques. Le mot de passe saisi n’est pas la clé de chiffrement : il passe par la fonction de dérivation scrypt pour déchiffrer un fichier de clé, qui contient la clé maîtresse du dépôt. Cette architecture permet d’avoir plusieurs mots de passe pour un même dépôt et d’en changer sans rechiffrer les données.

restic -r /srv/restic-repo key list
restic -r /srv/restic-repo key add
restic -r /srv/restic-repo key remove <ID>

Bonne pratique : la perte du mot de passe rend le dépôt définitivement illisible, sans aucune procédure de récupération. Conservez-le dans un gestionnaire de mots de passe d’entreprise et dans une enveloppe scellée hors site, et créez une seconde clé pour un administrateur suppléant. Ne stockez jamais le mot de passe sur le même support que le dépôt.

Pour l’automatisation, restic lit le mot de passe dans un fichier (--password-file ou la variable RESTIC_PASSWORD_FILE) ou le demande à un programme (RESTIC_PASSWORD_COMMAND), par exemple un coffre-fort de secrets. L’emplacement du dépôt peut être fourni par RESTIC_REPOSITORY. Le fichier de mot de passe doit être lisible par root uniquement (chmod 600).

6. Les destinations de stockage (backends)

Restic sépare la logique de sauvegarde du stockage. Les principaux backends :

• Local : /srv/restic-repo ou un disque externe monté. Idéal pour la copie hors ligne que l’on débranche ensuite.
• SFTP : sftp:utilisateur@hote:/srv/restic-repo. Il suffit d’un serveur SSH ; l’authentification doit se faire par clé, sans saisie interactive.
• REST server : rest:https://hote:8000/. Le serveur rest-server du projet restic est léger et propose un mode ajout seul (--append-only) : les clients peuvent créer de nouvelles sauvegardes mais pas supprimer ni modifier les anciennes.
• S3 et compatibles : s3:https://serveur/bucket, avec les variables AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY. Couplé au verrouillage d’objets (Object Lock) proposé par certains fournisseurs, il permet une copie immuable hors site.
• D’autres backends existent (Azure Blob, Google Cloud Storage, Backblaze B2, Swift) ainsi que rclone, qui ouvre l’accès à des dizaines de services.

Le choix dépend du rôle de la copie dans la stratégie 3-2-1 : un serveur interne en SFTP ou REST pour les restaurations rapides, un stockage objet ou un disque externe pour la copie hors site et hors ligne.

7. Sauvegarder : les options essentielles

Une fois le dépôt initialisé avec restic init, la commande backup crée un instantané :

restic -r /srv/restic-repo init
restic -r /srv/restic-repo backup /etc /srv/data --tag quotidien
restic -r /srv/restic-repo snapshots

Les options à connaître :

• --exclude, --iexclude (insensible à la casse) et --exclude-file pour écarter caches, fichiers temporaires et dossiers volumineux sans valeur ;
• --exclude-caches pour ignorer les dossiers marqués par un fichier CACHEDIR.TAG, et --exclude-if-present pour ignorer les dossiers contenant un fichier témoin ;
• --one-file-system pour ne pas traverser les points de montage (utile pour sauvegarder /) ;
• --tag pour étiqueter les instantanés (quotidien, avant-mise-à-jour, base-de-donnees…) ;
• --dry-run -vv pour afficher ce qui serait sauvegardé sans rien écrire ;
• --skip-if-unchanged pour ne pas créer d’instantané si rien n’a changé.

Depuis restic 0.19, les exclusions ne s’appliquent plus aux chemins passés explicitement en argument, mais toujours à leur contenu. Les bases de données ne doivent pas être sauvegardées en copiant leurs fichiers pendant qu’elles tournent : on sauvegarde un export cohérent. L’option --stdin-from-command exécute la commande d’export et enregistre directement sa sortie, en annulant la sauvegarde si la commande échoue :

restic -r /srv/restic-repo backup --stdin-filename all-databases.sql \
  --stdin-from-command -- mariadb-dump --all-databases --single-transaction

Les codes de retour permettent la supervision : 0 succès, 1 échec sans instantané, 3 instantané créé mais certains fichiers illisibles, 10 dépôt inexistant, 11 verrouillage impossible, 12 mot de passe incorrect. Un script de sauvegarde doit traiter tout code différent de 0 comme une alerte.

8. Restaurer : la seule opération qui compte

Restic offre plusieurs façons de récupérer des données selon le besoin :

• restic restore latest --target /tmp/restore restaure le dernier instantané dans un dossier ; --include et --exclude filtrent les fichiers, et la syntaxe instantane:/chemin permet de restaurer un sous-dossier à la racine de la cible ;
• restic ls et restic find retrouvent un fichier et l’instantané qui le contient ;
• restic dump envoie un fichier sur la sortie standard, ou un dossier sous forme d’archive tar ou zip ;
• restic diff compare deux instantanés, utile pour repérer quand un fichier a été modifié ou chiffré ;
• restic mount (Linux, macOS, FreeBSD, avec FUSE) présente tous les instantanés comme une arborescence parcourable en lecture seule.

Par défaut, restore écrase les fichiers existants dans la cible (--overwrite always) ; les valeurs if-changed, if-newer et never modifient ce comportement. L’option --delete supprime de la cible les fichiers absents de l’instantané : elle est puissante et doit toujours être précédée d’un essai avec --dry-run -vv.

Bonne pratique : restaurez toujours dans un dossier de travail ou sur une machine de test, jamais directement sur la production, sauf procédure validée. Chronométrez chaque restauration complète : c’est votre RTO réel.

9. Rétention, nettoyage et vérification

La politique de rétention décide combien d’instantanés conserver. Restic la réalise en deux temps : forget supprime les références aux instantanés qui ne sont plus couverts par la politique, puis prune libère l’espace des données qui ne sont plus utilisées par aucun instantané. L’option --prune enchaîne les deux.

restic -r /srv/restic-repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run
restic -r /srv/restic-repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Les règles se combinent par un « OU » : un instantané est conservé dès qu’il satisfait au moins une option --keep-*. Les instantanés sont regroupés par hôte et par chemins avant application de la politique (--group-by host,paths par défaut). L’exemple ci-dessus garde une sauvegarde par jour sur une semaine, une par semaine sur un mois et une par mois sur un an. Pendant un prune, le dépôt est verrouillé et les sauvegardes ne peuvent pas aboutir : planifiez-le en dehors des fenêtres de sauvegarde.

La commande check contrôle la cohérence du dépôt (structure, index, présence des blocs). Avec --read-data, elle relit et vérifie toutes les données, ce qui détecte la corruption silencieuse du support mais peut être long et coûteux sur un stockage facturé au téléchargement. L’option --read-data-subset (par exemple 1/5, 10% ou 10G) répartit cette relecture sur plusieurs passages.

10. Automatisation, supervision et résistance aux rançongiciels

Une sauvegarde manuelle finit toujours par être oubliée. Sous Linux, un service systemd déclenché par un timer est la solution la plus propre : journalisation dans journald, rattrapage des exécutions manquées avec Persistent=true, et possibilité de limiter les privilèges. Le service lit ses variables (RESTIC_REPOSITORY, RESTIC_PASSWORD_FILE) dans un fichier d’environnement protégé. Sous Windows, le Planificateur de tâches remplit le même rôle ; restic s’installe avec winget install --exact --id restic.restic --scope Machine ou scoop install restic.

Pour ne pas exécuter restic en root, la documentation propose d’accorder uniquement la capacité CAP_DAC_READ_SEARCH (lecture de tous les fichiers), par exemple dans l’unité systemd :

[Service]
DynamicUser=yes
AmbientCapabilities=CAP_DAC_READ_SEARCH
CapabilityBoundingSet=CAP_DAC_READ_SEARCH

La supervision doit vérifier trois choses : que le service s’est terminé avec le code 0, que le dernier instantané a moins de 24 heures (restic snapshots --json facilite ce contrôle), et que les vérifications check périodiques ne signalent aucune erreur.

Contre un rançongiciel, le principe est simple : la machine sauvegardée ne doit pas pouvoir détruire ses propres sauvegardes. Trois mécanismes complémentaires :

• un dépôt rest-server en mode --append-only, où le client ne peut qu’ajouter ; la rétention est alors appliquée par l’administrateur directement sur le serveur de sauvegarde, avec --keep-within pour ne pas être piégé par de faux instantanés récents ;
• une copie hors ligne sur un disque débranché après usage, alimentée par restic copy ;
• un stockage objet avec verrouillage d’objets pour une copie immuable hors site.

Le serveur de sauvegarde lui-même doit être isolé : zone réseau dédiée, comptes d’administration distincts, pas d’appartenance au domaine Active Directory de production, conformément aux recommandations de l’ANSSI.

11. Construire une stratégie 3-2-1 avec restic dans une PME

Voici une architecture de référence, reproduite dans les travaux pratiques :

1. Copie 1 – production : le serveur de fichiers et sa base de données.
2. Copie 2 – serveur de sauvegarde interne : sauvegarde quotidienne à 1 h du matin vers un rest-server en ajout seul (ou un dépôt SFTP dédié), dans une autre salle ou un autre bâtiment. Rétention 7 jours, 4 semaines, 12 mois, appliquée côté serveur.
3. Copie 3 – hors site et hors ligne : chaque semaine, restic copy vers un disque externe qui tourne entre deux disques, l’un toujours hors des locaux ; ou vers un stockage objet avec verrouillage d’objets.
4. Vérification : check hebdomadaire, check --read-data-subset mensuel, et un exercice de restauration complète au moins une fois par trimestre, consigné dans un registre (date, durée, données restaurées, anomalies).

Avant de mettre cette architecture en production, vérifiez les points suivants :

• l’inventaire des données à protéger est validé, avec un RPO et un RTO pour chaque catégorie ;
• les mots de passe des dépôts sont stockés hors du système sauvegardé et au moins deux personnes savent les retrouver ;
• aucun compte de la production ne peut supprimer les sauvegardes (ajout seul, copie hors ligne ou stockage immuable) ;
• les échecs de sauvegarde déclenchent une alerte lue par quelqu’un, y compris pendant les congés ;
• l’espace disponible sur chaque destination est surveillé et la croissance du dépôt est suivie avec restic stats ;
• les exports de bases de données, de messagerie et d’applications métier sont inclus, et pas seulement les partages de fichiers ;
• la dernière restauration complète réussie date de moins de trois mois.

Pour que restic copy conserve la déduplication entre deux dépôts, le dépôt de destination doit être créé avec les mêmes paramètres de découpage : restic init --from-repo <source> --copy-chunker-params.

Documentez la procédure de restauration sur papier et hors du système d’information : en cas d’attaque, l’intranet et le gestionnaire de documentation peuvent être indisponibles. Indiquez où se trouvent les mots de passe des dépôts, qui peut les utiliser, et dans quel ordre restaurer les services.

12. Synthèse

La règle 3-2-1 n’est pas une contrainte technique mais une assurance : trois copies, deux supports, une copie hors site, complétées par une copie hors ligne ou immuable et des restaurations testées. Restic apporte les briques nécessaires pour l’appliquer à moindre coût : chiffrement côté client, déduplication, multiples destinations, rétention fine, vérification d’intégrité et automatisation simple. Les huit travaux pratiques qui suivent construisent cette stratégie pas à pas dans un laboratoire de deux machines virtuelles : installation, premières sauvegardes, restaurations, dépôt distant, rétention, automatisation, protection contre la suppression, puis copie hors ligne et exercice de reprise complet.

Pour aller plus loin sur le blog : Restic : des sauvegardes chiffrées, dédupliquées et vérifiables · Kopia : sauvegardes chiffrées, dédupliquées et immuables · UrBackup : une solution de sauvegarde libre, simple et complète