Sauvegarde 3-2-1 : protégez vos données avec Borg ou Restic
Sauvegarde 3-2-1 : protégez vos données avec Borg ou Restic
La sauvegarde 3-2-1 consiste à conserver au moins trois copies des données, sur deux types de supports différents, avec une copie hors site. Borg et Restic permettent d’appliquer cette règle avec chiffrement, déduplication et restauration de fichiers, à condition de séparer réellement les emplacements et de tester les copies créées.
Une copie synchronisée sur un second disque ne suffit pas face à une suppression, un vol, un incendie ou un rançongiciel. Ce tutoriel montre comment concevoir une stratégie de sauvegarde, choisir entre Borg et Restic, créer un dépôt chiffré, automatiser les tâches et vérifier qu’une restauration fonctionne réellement.
En bref
🗂️ La règle 3-2-1 signifie trois copies, sur deux supports distincts, avec une copie hors site. Le fichier original compte comme l’une des trois copies.
🔒 Borg et Restic sont des outils de sauvegarde chiffrée, pas des outils de synchronisation. Leur déduplication réduit le volume stocké lorsque plusieurs versions contiennent les mêmes données.
🧪 La version renforcée 3-2-1-1-0 ajoute une copie immuable ou hors ligne et des restaurations testées sans erreur. Une sauvegarde non restaurée reste une hypothèse.
Qu’est-ce que la règle de sauvegarde 3-2-1 ?
La règle de sauvegarde 3-2-1 est une méthode de résilience qui répartit les risques entre plusieurs copies, plusieurs supports et plusieurs lieux. Elle protège contre la panne d’un disque, mais aussi contre les erreurs humaines, les sinistres locaux et les attaques qui ciblent les fichiers de production.
La méthode a été popularisée au début des années 2000 par le photographe Peter Krogh. Le principe reste simple, mais son application doit tenir compte des menaces actuelles : un rançongiciel qui chiffre le poste de travail peut également atteindre un partage réseau ou un disque de sauvegarde laissé connecté.
- 3 copies : les données de production et au moins deux copies de secours distinctes.
- 2 supports : par exemple un disque local et un stockage distant, ou un NAS et un disque externe.
- 1 copie hors site : une copie stockée dans un autre lieu physique ou chez un prestataire distant.
La règle 3-2-1 réduit le risque de perte ; elle ne dispense ni de sécuriser les accès ni de tester les restaurations.
Trois copies ne veulent pas dire trois dossiers identiques
Trois copies utiles doivent pouvoir survivre à des incidents différents. Un dossier local, son miroir sur le même disque et une archive sur une seconde partition ne forment pas une stratégie robuste : une défaillance matérielle, un chiffrement malveillant ou une erreur de manipulation peuvent toucher les trois emplacements.
Une architecture minimale peut associer les données actives sur l’ordinateur, une sauvegarde locale chiffrée sur disque externe, puis une sauvegarde distante chiffrée vers un serveur ou un stockage objet. La séparation physique et administrative entre les copies compte autant que leur nombre.
Deux supports réduisent les défaillances communes
Deux supports différents limitent l’exposition à une panne commune. Un disque externe USB et un espace de stockage distant n’ont pas les mêmes modes de défaillance, les mêmes contraintes d’accès ni les mêmes risques de sinistre local.
Le cloud peut remplir le rôle de copie hors site, mais il faut vérifier le coût de stockage, le coût éventuel de sortie des données, la localisation, la rétention et les mécanismes d’immutabilité proposés. Une sauvegarde distante chiffrée reste dépendante de la clé qui permet de la déchiffrer.
Borg et Restic : quelles différences pour sauvegarder ses données ?
Borg et Restic sont deux logiciels de sauvegarde en ligne de commande qui créent des instantanés chiffrés et dédupliqués. Borg convient bien aux dépôts accessibles comme un système de fichiers ou via SSH ; Restic propose de nombreux backends et s’intègre facilement à des stockages distants compatibles avec ses connecteurs.
Le bon choix dépend moins des fonctions marketing que de l’emplacement du dépôt, des compétences disponibles et de la procédure de restauration. Une sauvegarde Borg ou Restic doit rester lisible par une personne habilitée, même lors d’un incident où le serveur principal n’est plus disponible.
| Outil | Usage adapté | Atout concret | Point de vigilance |
|---|---|---|---|
| BorgBackup | Serveur Linux, NAS, dépôt local ou SSH | Déduplication efficace et gestion fine des archives | La syntaxe diffère entre les grandes versions de Borg |
| Restic | Postes, serveurs et stockage distant varié | Backends nombreux et commandes homogènes | La configuration du backend distant doit être documentée |
| rsync | Copie de fichiers simple sur un support maîtrisé | Facile à inspecter directement | Ne fournit pas seul un historique chiffré et dédupliqué |
| Syncthing | Synchronisation entre appareils | Réplication rapide de dossiers actifs | Une suppression peut se propager : ce n’est pas une sauvegarde complète |
Quand choisir BorgBackup ?
BorgBackup est pertinent lorsque le dépôt est un disque local, un volume monté ou un serveur SSH contrôlé. Borg stocke des archives successives dans un dépôt chiffré et déduplique les blocs communs entre ces archives, ce qui limite la croissance du stockage dans de nombreux usages.
La documentation officielle de Borg doit être consultée avant le déploiement, car les commandes peuvent varier selon la version installée. Les exemples Borg de ce guide utilisent la syntaxe Borg 1.x ; vérifiez la version avec borg --version avant de les automatiser.
Quand choisir Restic ?
Restic est souvent plus commode lorsqu’une copie de secours doit être envoyée vers un stockage distant compatible avec ses backends, notamment un serveur SFTP, un partage monté ou un stockage objet. Restic chiffre les données côté client avant l’envoi : le prestataire de stockage n’a pas besoin d’accéder aux fichiers en clair.
Restic n’élimine pas la nécessité de protéger le compte distant. Un accès administrateur unique partagé entre la production et le dépôt de sauvegarde peut devenir un point de compromission commun lors d’une attaque.
Comment concevoir une architecture de sauvegarde 3-2-1 ?
Une architecture de sauvegarde 3-2-1 commence par l’inventaire des données et par un objectif de restauration réaliste. Listez les dossiers métier, les bases de données, les configurations, les clés, les médias d’installation et les fichiers nécessaires pour redémarrer les services, pas seulement les documents utilisateurs.
Un disque de sauvegarde local facilite une restauration rapide après une suppression accidentelle ou une panne simple. La copie distante protège davantage contre un sinistre qui affecte le domicile, le bureau ou le local serveur. Une copie hors ligne, déconnectée après exécution, réduit aussi le risque qu’un logiciel malveillant atteigne tous les dépôts accessibles.
Étape 1 : classer les données et fixer une priorité
Créez une liste courte des données à restaurer en premier. Séparez les données irremplaçables, comme les documents administratifs, bases de données, photos, dépôts de code, configurations de services et secrets de récupération, des données téléchargeables ou recréables.
Attribuez à chaque ensemble une fréquence de sauvegarde et un délai de restauration acceptable. Une base de données modifiée chaque heure et un dossier d’archives modifié une fois par mois ne nécessitent pas la même planification.
Étape 2 : choisir les emplacements sans créer un faux hors-site
Un disque externe rangé à côté de l’ordinateur n’est pas une copie hors site. Un NAS situé dans le même bâtiment ne répond pas non plus au risque d’incendie, d’inondation ou de vol du matériel.
- Conservez une copie locale pour restaurer vite les fichiers courants.
- Placez une copie distante dans un lieu distinct ou sur un service de stockage choisi selon ses conditions.
- Déconnectez périodiquement un support réservé à une sauvegarde hors ligne.
- Documentez l’emplacement, le responsable, la clé de chiffrement et la procédure de restauration.
Étape 3 : définir une rétention compréhensible
La rétention détermine combien de versions restent disponibles. Une politique simple peut conserver plusieurs sauvegardes quotidiennes récentes, quelques versions hebdomadaires et des versions mensuelles ; les valeurs exactes dépendent du volume, du budget et du délai de détection d’une erreur.
Une conservation trop courte devient un problème lorsqu’une corruption ou un rançongiciel est détecté plusieurs semaines après l’intrusion. Une conservation très longue peut, elle, augmenter la charge de stockage et compliquer le contrôle des données conservées.
Comment mettre en place une sauvegarde avec Borg ?
Une sauvegarde Borg fiable se construit en quatre temps : créer un dépôt chiffré, effectuer une première archive, appliquer une rétention, puis restaurer un fichier dans un répertoire de test. Le dépôt peut être un disque externe monté ou un emplacement distant accessible en SSH, mais il ne doit pas être le seul support de sauvegarde.
Étape 1 : préparer un dépôt Borg chiffré
Installez BorgBackup depuis le gestionnaire de paquets de votre système ou selon la documentation officielle du projet. Créez ensuite un répertoire de dépôt sur le support de sauvegarde et conservez la phrase secrète dans un gestionnaire de mots de passe ou un coffre de secrets, jamais dans un script partagé.
export BORG_REPO="/media/disque-sauvegarde/borg-repo"
borg init --encryption=repokey-blake2 "$BORG_REPO"La commande initialise un dépôt chiffré avec la syntaxe Borg 1.x. Le chemin /media/disque-sauvegarde/borg-repo est un exemple : adaptez-le au point de montage réel et vérifiez que le disque ciblé est bien celui prévu avant de lancer l’initialisation.
Étape 2 : créer la première archive de fichiers
Choisissez des répertoires précis au lieu de sauvegarder tout le système sans filtre. Excluez les caches, fichiers temporaires et répertoires recréables ; incluez les données utilisateur, les configurations et les exports applicatifs nécessaires à une reprise.
borg create --stats \
::'{hostname}-{now}' \
"$HOME/Documents" \
"$HOME/Photos" \
"$HOME/.config"Le résultat attendu est une nouvelle archive identifiable dans le dépôt. Vérifiez sa présence avec borg list et notez son nom dans votre journal d’exploitation ou dans la documentation de reprise.
Étape 3 : restaurer un fichier dans un dossier de test
Une restauration de test doit utiliser un emplacement vide afin de ne pas écraser des données de production. Consultez d’abord les archives disponibles, puis extrayez uniquement le fichier ou le dossier nécessaire depuis l’archive choisie.
mkdir -p "$HOME/restauration-test"
cd "$HOME/restauration-test"
borg extract ::NOM_DE_L_ARCHIVE chemin/vers/le/fichierContrôlez le contenu restauré, la taille du fichier et l’ouverture par l’application attendue. Une archive présente dans un dépôt ne prouve pas que les données sont exploitables.
Étape 4 : appliquer une rétention avant d’automatiser
Définissez une rétention cohérente avec votre capacité de stockage. L’exemple suivant conserve sept archives quotidiennes, quatre hebdomadaires et six mensuelles ; il est indicatif et doit être ajusté à la fréquence réelle des sauvegardes.
borg prune \
--keep-daily=7 \
--keep-weekly=4 \
--keep-monthly=6Planifiez ensuite la création et le nettoyage avec un minuteur systemd, cron ou l’outil d’ordonnancement de votre système. Le script d’automatisation doit journaliser le code de sortie, vérifier la présence du support et échouer clairement si le dépôt est indisponible.
Comment mettre en place une sauvegarde avec Restic ?
Une sauvegarde Restic suit une logique similaire : initialiser un dépôt, protéger le secret, sauvegarder les dossiers sélectionnés, vérifier les instantanés et tester une restauration. Restic convient particulièrement lorsque le dépôt doit être déplacé vers un emplacement distant sans exposer les fichiers en clair au prestataire.
Étape 1 : définir le dépôt et protéger le mot de passe
Créez un fichier de mot de passe lisible uniquement par le compte qui exécute la sauvegarde. Stockez ce fichier dans un emplacement protégé et sauvegardez son accès dans votre procédure de récupération, car la perte du secret peut rendre le dépôt inutilisable.
export RESTIC_REPOSITORY="/media/disque-sauvegarde/restic-repo"
export RESTIC_PASSWORD_FILE="$HOME/.config/restic/password"
restic initLe résultat attendu est un dépôt Restic initialisé sur le support désigné. Pour un dépôt distant, la variable RESTIC_REPOSITORY doit contenir l’adresse correspondant au backend choisi ; suivez la documentation officielle de Restic pour la syntaxe adaptée à ce backend.
Étape 2 : sauvegarder les dossiers utiles et consulter les instantanés
Lancez une première sauvegarde avec des chemins explicites. Commencez par un périmètre limité afin de mesurer la durée, la taille envoyée et les exclusions nécessaires avant d’étendre la tâche à l’ensemble des données.
restic backup \
"$HOME/Documents" \
"$HOME/Photos" \
"$HOME/.config"
restic snapshotsLa commande restic snapshots affiche les instantanés créés. Vérifiez que la date, le nom de l’hôte et les chemins sauvegardés correspondent bien au poste concerné.
Étape 3 : restaurer un instantané Restic
Restaurez d’abord dans un dossier temporaire. Cette précaution évite de remplacer des fichiers actifs et permet de comparer la copie restaurée avec l’original sans ajouter un nouvel incident à une panne existante.
mkdir -p "$HOME/restauration-restic"
restic restore latest --target "$HOME/restauration-restic"Ouvrez plusieurs fichiers restaurés, pas seulement le premier document affiché. Pour une base de données ou une application métier, la vérification doit inclure une restauration dans un environnement isolé et un contrôle fonctionnel adapté.
Étape 4 : gérer la rétention et lancer un contrôle
Restic peut supprimer les instantanés dépassant la politique retenue puis nettoyer les données inutilisées avec l’option --prune. L’exemple ci-dessous reprend une rétention indicative ; elle n’est pas une durée universelle de protection contre les incidents.
restic forget \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
--prune
restic checkLe contrôle restic check vérifie la cohérence du dépôt, mais il ne remplace pas une restauration de fichiers et de services. Planifiez ces deux opérations séparément : un contrôle technique régulier et une restauration fonctionnelle à intervalle défini.
Comment protéger une sauvegarde contre les rançongiciels ?
La sauvegarde 3-2-1 reste pertinente face aux rançongiciels, mais une copie accessible avec les mêmes identifiants administrateurs que la production peut être chiffrée, supprimée ou rendue inutilisable par un attaquant. La stratégie renforcée 3-2-1-1-0 ajoute une copie hors ligne ou immuable et une vérification des restaurations sans erreur.
Une copie immuable est une copie qui ne peut pas être modifiée ni supprimée avant la fin de sa période de rétention. Un stockage WORM, pour « Write Once Read Many », peut fournir ce mécanisme en ligne ; une sauvegarde hors ligne apporte une séparation supplémentaire lorsqu’elle est réellement déconnectée.
Le support de sauvegarde le plus accessible pendant un incident est souvent aussi le plus exposé à la compromission.
Étape 1 : séparer les accès de production et de sauvegarde
Utilisez un compte dédié à la sauvegarde, avec les droits minimaux nécessaires sur les données et sur le dépôt. Évitez de réutiliser le même compte administrateur, le même mot de passe et le même coffre de secrets pour la production et le stockage de secours.
Activez la double authentification lorsque le service distant le permet et conservez des codes de récupération dans un emplacement sécurisé. Une rotation de mot de passe non documentée peut empêcher une restauration en urgence ; la sécurité ne doit pas supprimer la capacité de reprise.
Étape 2 : prévoir une copie réellement déconnectée ou immuable
Débranchez le disque de sauvegarde hors ligne après son exécution et stockez-le dans un autre lieu si possible. L’ANSSI rappelle, dans ses recommandations publiées en 2023, l’intérêt d’une sauvegarde hors ligne, notamment sur bande, pour réduire l’exposition aux cyberattaques.
Un stockage immuable en ligne peut compléter cette approche, mais sa durée de verrouillage doit être définie selon le contexte de détection des incidents, les obligations de conservation et les contraintes opérationnelles. Une immutabilité mal configurée peut bloquer la suppression légitime ou expirer avant la découverte d’une compromission.
Comment vérifier qu’une sauvegarde est réellement restaurable ?
Une sauvegarde est réellement fiable lorsqu’un fichier, une configuration ou une application peut être restauré dans le délai prévu et utilisé sans erreur. La vérification doit couvrir l’intégrité du dépôt, la disponibilité des clés, la vitesse de transfert, les dépendances applicatives et le comportement des données restaurées.
Étape 1 : contrôler les journaux après chaque exécution
Conservez les sorties des tâches Borg ou Restic et surveillez les codes de retour. Une tâche terminée sans alerte n’est utile que si le bon dépôt, les bons chemins et le bon volume de données ont été traités.
Définissez une alerte en cas d’échec, de durée anormale ou d’absence de sauvegarde récente. L’absence de notification est un risque classique : une tâche peut échouer plusieurs semaines sans qu’aucune restauration ne soit possible au moment critique.
Étape 2 : restaurer régulièrement dans un environnement isolé
Créez un répertoire de test ou une machine isolée, puis restaurez un échantillon représentatif : documents, photos, fichiers de configuration, export de base de données et données applicatives. Vérifiez l’ouverture, les permissions et la cohérence métier des éléments restaurés.
Pour un serveur, mesurez aussi le temps de restauration complet et la bande passante requise. Une copie distante correcte peut devenir trop lente à restaurer si la connexion réseau ou le stockage cible constitue un goulot d’étranglement.
Étape 3 : préparer une restauration totale
Documentez les étapes qui seraient nécessaires après la perte d’un poste ou d’un serveur : réinstallation du système, installation de Borg ou Restic, récupération de la clé, accès au dépôt et ordre de restauration. Conservez cette documentation hors du système sauvegardé.
Une stratégie de sauvegarde utile s’intègre à un plan de continuité et de reprise d’activité. Le plan doit indiquer qui décide, où se trouvent les supports, quelles données sont prioritaires et comment vérifier le retour au fonctionnement normal.
Erreurs fréquentes avec Borg, Restic et la règle 3-2-1
Les incidents de sauvegarde viennent souvent d’une architecture incomplète plutôt que d’un défaut de Borg ou Restic. Les erreurs suivantes sont concrètes et peuvent être contrôlées avant qu’une panne ne les révèle.
- Confondre synchronisation et sauvegarde : un outil de synchronisation peut répliquer une suppression ou un fichier chiffré. Conservez des instantanés versionnés dans un dépôt de sauvegarde.
- Laisser le disque de secours connecté en permanence : un rançongiciel ou une erreur d’administration peut atteindre le volume monté. Déconnectez la copie hors ligne après usage.
- Mettre la phrase secrète dans un script : l’historique du terminal, un dépôt Git ou une sauvegarde de configuration peuvent l’exposer. Utilisez un fichier protégé ou un gestionnaire de secrets.
- Ne sauvegarder que les fichiers utilisateur : sans configurations, exports et médias d’installation, la reconstruction d’un service peut être lente ou impossible.
- Ne jamais restaurer : un dépôt cohérent peut contenir des données incomplètes ou une clé indisponible. Planifiez un test de restauration documenté.
Sources utiles à consulter
La configuration exacte dépend des versions installées, du système d’exploitation et du backend distant. Pour toute décision engageante sur les données professionnelles, un audit adapté par un administrateur système ou un spécialiste de la sécurité reste préférable.
- Documentation officielle BorgBackup : syntaxe des commandes, modèles de chiffrement et compatibilité entre versions.
- Documentation officielle Restic : initialisation des dépôts, backends distants, rétention et contrôles d’intégrité.
- ANSSI : recommandations de cybersécurité et pratiques de sauvegarde hors ligne, notamment face aux rançongiciels.
- Présentation de la règle 3-2-1 : rappel pédagogique des trois copies, deux supports et une copie hors site.
Le verdict pour votre stratégie de sauvegarde
Pour un poste personnel ou un petit serveur, commencez par un dépôt chiffré Borg ou Restic sur disque externe, puis ajoutez une copie distante distincte. Le choix entre Borg et Restic importe moins que la capacité à restaurer rapidement, à protéger les secrets et à maintenir une copie séparée de la production.
Ajoutez une copie hors ligne ou immuable lorsque les données sont sensibles ou que le risque de rançongiciel est significatif. La meilleure stratégie de sauvegarde est celle dont la restauration a été testée, mesurée et documentée avant l’incident.
À retenir
- 🗂️ La règle 3-2-1 impose trois copies sur deux supports, dont une hors site.
- 🔒 Borg et Restic créent des sauvegardes chiffrées avec versions et déduplication.
- ⚠️ Un disque branché en permanence reste exposé aux erreurs et aux rançongiciels.
- 🧪 Une restauration isolée teste les données, les clés et les délais réels.
- 📌 Les accès de sauvegarde doivent être séparés des accès de production.
Questions fréquentes sur la sauvegarde 3-2-1
La règle 3-2-1 protège-t-elle contre les rançongiciels ?
La règle 3-2-1 réduit les conséquences d’un rançongiciel, mais elle ne garantit pas une protection totale. Une copie hors ligne ou immuable, des accès séparés et des restaurations testées renforcent nettement la capacité de reprise.
Borg ou Restic : lequel choisir pour une sauvegarde distante ?
Restic est souvent pratique pour une sauvegarde distante grâce à ses nombreux backends. Borg reste un choix solide pour un disque local, un NAS ou un serveur SSH maîtrisé ; choisissez surtout l’outil dont vous savez restaurer les archives.
Peut-on utiliser un stockage cloud pour la copie hors site ?
Oui, un stockage distant peut servir de copie hors site si les données sont chiffrées avant l’envoi. Vérifiez les coûts de stockage et de restauration, la localisation des données, les conditions de rétention et les protections d’accès proposées.
Que se passe-t-il si la clé de chiffrement est perdue ?
Une clé ou une phrase secrète perdue peut rendre les sauvegardes chiffrées inaccessibles. Conservez les secrets dans un gestionnaire de mots de passe ou un coffre sécurisé, avec une procédure de récupération accessible aux personnes autorisées.
Faut-il laisser le disque de sauvegarde branché ?
Un disque local branché facilite les sauvegardes automatiques, mais augmente son exposition aux erreurs et aux logiciels malveillants. Une copie réservée à la sauvegarde hors ligne doit être déconnectée après l’opération lorsque l’organisation le permet.