Niveau 🟡 intermédiaire
Durée estimée : 20 min · Prérequis : RAID n'est pas une sauvegarde
Un document vraiment important, on n'en garde jamais une seule copie dans un seul tiroir. On en
fait une copie qu'on range ailleurs, et une autre encore, dans un lieu complètement différent —
au cas où le tiroir, la pièce, ou même la maison entière serait perdue. La règle 3-2-1
formalise exactement ce réflexe de prudence, appliqué aux données numériques.
La règle 3-2-1, un standard largement reconnu en sauvegarde de données :
Cette règle répond directement aux limites du RAID identifiées page précédente : en variant à la
fois le support et le lieu, elle protège contre l'erreur humaine (la copie hors site n'est pas
touchée par une suppression locale), le ransomware (si la sauvegarde n'est pas accessible en
écriture permanente depuis la machine infectée), et le sinistre physique (la copie hors site
survit à la destruction du lieu principal).
Trois outils courants, avec des approches différentes :
| Outil | Approche | Points forts |
|---|---|---|
| rsync | Synchronisation de fichiers, incrémentale par défaut (ne transfère que ce qui a changé) | Simple, universel, disponible partout — mais pas d'historique de versions par défaut |
| Restic | Sauvegarde avec déduplication et chiffrement intégrés, versionnée (garde plusieurs instantanés dans le temps) | Chiffrement natif, compatible avec de nombreux supports (local, cloud), restauration granulaire |
| Borg (BorgBackup) | Approche similaire à Restic — déduplication, chiffrement, versionnée | Très efficace en espace disque grâce à une déduplication poussée, écosystème mature |
Restic et Borg apportent tous les deux une notion essentielle que rsync seul n'a pas nativement
: le versionnement — pouvoir restaurer l'état des données non pas seulement « la dernière
copie », mais un instantané précis à une date donnée. Utile face à un ransomware ou une
corruption découverte après plusieurs jours : sans versionnement, une synchronisation simple
aurait déjà propagé la corruption dans l'unique copie de sauvegarde.
Automatiser et vérifier, deux réflexes indispensables au-delà du simple choix d'un outil :
cron, ou une unité systemd de type🧪 Honnêtement, sur notre exemple : cette page décrit la méthode à suivre — elle n'est
pas encore appliquée sur le serveur de ce wiki à ce jour (voir la page suivante,
Notre état réel, qui l'assume explicitement comme un manque). Rien ici
n'est présenté comme testé sur cette installation ; c'est un cours général sur la bonne
pratique à suivre, pas un compte-rendu d'une mise en œuvre déjà faite.
Trois copies (l'original compris), sur au moins deux supports différents, dont une hors site —
la règle se lit directement dans ce schéma minimal.
# Exemple d'usage de rsync -- synchronisation incrémentale vers un
# disque externe monté localement
rsync -avz --delete /srv/docker/ /mnt/disque-externe/backup-docker/
# Exemple d'usage de Restic -- initialise un dépôt de sauvegarde chiffré
restic init --repo /mnt/disque-externe/restic-repo
# Puis, à chaque sauvegarde :
restic --repo /mnt/disque-externe/restic-repo backup /srv/docker/
# Restauration -- l'étape à ne jamais négliger de tester
restic --repo /mnt/disque-externe/restic-repo restore latest --target /tmp/restauration-test
--delete sur rsync synchronise aussi les suppressions — à utiliser avec prudence, en gardant
en tête la limite vue page précédente (une suppression accidentelle se propagerait aussi ici,
sans le versionnement qu'apporte Restic).
Le seul test qui compte réellement : restaurer une sauvegarde dans un dossier temporaire et
vérifier que les fichiers obtenus sont identiques aux originaux. Une sauvegarde qui n'a jamais
été restaurée avec succès ne doit jamais être considérée comme fiable.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Sauvegarde sur un disque externe jamais débranché de la machine | Le disque reste vulnérable aux mêmes risques que l'original (vol, incendie, ransomware qui écrit sur tout support monté) | Respecter le volet « hors site » de la règle 3-2-1, pas seulement « support différent » |
| Sauvegarde jamais testée en restauration | Confiance non vérifiée dans le processus | Planifier un test de restauration régulier, pas seulement la sauvegarde elle-même |
| Sauvegarde manuelle, oubliée après quelques semaines | Dépendance à la mémoire humaine | Automatiser via une tâche planifiée (cron, timer systemd) plutôt que de compter sur un rappel manuel |
3 copies des données, sur 2 supports différents, dont 1 copie conservée hors site.
Le versionnement : la possibilité de restaurer un instantané précis dans le temps, plutôt que
seulement le dernier état synchronisé — utile si une corruption n'est découverte que plusieurs
jours après s'être produite.
Parce que rien ne garantit qu'elle fonctionne réellement tant qu'elle n'a pas été restaurée avec
succès au moins une fois — une sauvegarde non testée n'est qu'une hypothèse.
Conçois, sur le papier, un schéma de sauvegarde 3-2-1 pour un homelab personnel : quel serait
l'original, quelles seraient les deux copies (support et lieu), et quel outil (rsync, Restic ou
Borg) choisirais-tu pour chacune, avec une justification courte.
règle 3-2-1 ·
versionnement ·
déduplication ·
hors site
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.