À une époque où nos vies personnelles comme nos infrastructures professionnelles sont intégralement numérisées, la perte de données peut aller d’un simple désagrément à une véritable catastrophe opérationnelle. Qu’il s’agisse de vingt ans de photos de famille irremplaçables, de documents administratifs critiques ou de la configuration complète d’un serveur de production (Docker, bases PostgreSQL, clés cryptographiques), la question n’est jamais de savoir si un incident matériel ou logique surviendra, mais quand.

Pour éliminer tout point de défaillance unique (Single Point of Failure), l’industrie s’appuie sur un standard universel recommandé par la CISA (Cybersecurity and Infrastructure Security Agency) et l’ANSSI : la règle de sauvegarde 3-2-1, complétée en 2026 par son évolution anti-ransomware 3-2-1-1-0.

1. La Règle d’Or : Qu’est-ce que le « 3-2-1 » ?

Formulée initialement par le photographe américain Peter Krogh puis adoptée par l’ensemble des ingénieurs systèmes [1] [2], la règle 3-2-1 impose de maintenir en permanence :

1. TROIS copies de vos données : votre donnée originale de production (Copie 1) accompagnée d’au moins deux copies indépendantes (Copie 2 et Copie 3). Si une probabilité de panne annuelle d’un support est de 1/100, la probabilité de perdre simultanément trois copies indépendantes chute à 1 / 1 000 000.
2. Sur DEUX supports technologiques différents : ne jamais concentrer toutes les copies sur le même contrôleur matériel. Attention au piège classique : le RAID (RAID 1, RAID 5, RAID 6, SHR) n’est PAS une sauvegarde ! Le RAID protège uniquement la continuité de service contre la casse mécanique d’un disque ; si un rm -rf, une corruption du système de fichiers, une surtension électrique de l’alimentation ou un ransomware frappe le volume RAID, la destruction est répliquée instantanément sur tous les disques du grappe. Associez toujours deux médias distincts (ex: SSD NVMe interne du PC/serveur + NAS sur le réseau ou disque externe USB-C débranché).
3. Dont UNE copie hors site (Off-Site) : c’est votre assurance-vie numérique contre les sinistres physiques affectant le bâtiment entier (incendie, dégât des eaux, cambriolage, foudre).

2. Architecture concrète à la maison et en Homelab : Données « Chaudes » vs « Froides »

Pour protéger efficacement les souvenirs familiaux (photothèque Immich, coffre-fort documentaire, boîtes e-mail) et les configurations serveurs sans exploser sa facture Cloud, il faut segmenter le stockage selon la vitesse de restauration souhaitée (RTO : Recovery Time Objective) :

La stratégie hybride automatisée autour d’un NAS (Synology / QNAP)

Un serveur NAS moderne constitue le pivot idéal de cette topologie [3] :

• Vos postes de travail et votre serveur principal sauvegardent leurs volumes chaque nuit vers le NAS local (via NFSv4, SMB ou rsync/SSH) ;
• Le NAS prend un snapshot local en lecture seule (Btrfs ou ZFS) ;
• Une tâche nocturne chiffre les blocs côté client (AES-256-GCM ou ChaCha20-Poly1305) avant de les pousser vers un bucket Cloud externe. Ainsi, le fournisseur Cloud n’a jamais accès à vos fichiers en clair.

3. Le Cloud n’est pas infaillible : la leçon de l’incendie d’OVHcloud (Strasbourg, 2021)

Le 10 mars 2021, un incendie majeur a détruit le datacenter SBG2 d’OVHcloud à Strasbourg et endommagé SBG1 [4]. Des milliers d’entreprises et de collectivités ont découvert brutalement que leurs serveurs de production et leurs sauvegardes automatisées étaient hébergés dans la même salle ou le même bâtiment :

• « Le Cloud, c’est l’ordinateur de quelqu’un d’autre » : et cet ordinateur physique peut subir un sinistre industriel.
• Responsabilité partagée : l’hébergeur garantit l’infrastructure matérielle, mais l’architecte reste seul responsable de la survie de ses données.
• Règle d’isolation géographique : si votre serveur primaire tourne à Paris (eu-west-3 ou domicile), votre sauvegarde hors site doit résider dans une autre région physique distante d’au moins plusieurs dizaines ou centaines de kilomètres (eu-central-1 Francfort, Amsterdam, ou NAS déporté dans une autre résidence).

4. Automatisation technique : Rclone (crypt) et Restic en ligne de commande

Une sauvegarde qui dépend d’une action humaine manuelle (« penser à brancher le disque dur le dimanche soir ») finit toujours par échouer. En production, nous automatisons le pipeline via restic (pour la déduplication par blocs chiffrés) et rclone (pour la réplication multi-cloud chiffrée).

Exemple 1 : Sauvegarde dédupliquée et chiffrée avec restic + purge de rétention GFS

restic découpe les fichiers en blocs définis par le contenu (Content-Defined Chunking), les compresse, les chiffre avec authentification (AEAD) et n’envoie sur le réseau que les blocs modifiés :

#!/usr/bin/env bash
set -euo pipefail

export RESTIC_REPOSITORY="s3:https://s3.eu-central-003.backblazeb2.com/homelab-vault-321"
export RESTIC_PASSWORD_FILE="/etc/restic/repo.key"
export AWS_ACCESS_KEY_ID="003xxxxxxxx"
export AWS_SECRET_ACCESS_KEY_FILE="/etc/restic/b2_secret.key"

# 1. Sauvegarde incrémentale dédupliquée des volumes critiques
restic backup \
  /srv/docker/domotique \
  /srv/docker/app-core \
  /mnt/nas_backups/postgres_dumps \
  --exclude="*.log" \
  --exclude="node_modules" \
  --tag "nightly-321"

# 2. Politique de rétention Grandfather-Father-Son (7 jours, 4 semaines, 12 mois)
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

# 3. Vérification cryptographique d'un échantillon de 5 % des blocs distants
restic check --read-data-subset=5%

Exemple 2 : Réplication NAS vers Cloud chiffré à la volée avec rclone crypt

(Un script complet prêt à l’emploi est également disponible sur notre dépôt public InfraAtHome/rclone/backup_321_rclone.sh).

# Synchronisation unidirectionnelle vers un remote chiffré "b2-crypt:"
# Les fichiers supprimés ou modifiés sont déplacés dans une archive datée (--backup-dir)
rclone sync /mnt/nas_qnap/famille_vault b2-crypt:actuel \
  --backup-dir "b2-crypt:archives/$(date +%Y-%m-%d_%H-%M)" \
  --transfers 8 \
  --checkers 16 \
  --fast-list \
  --bwlimit "20M" \
  --log-file /var/log/rclone_321.log \
  --log-level INFO

5. MàJ 2026 Du 3-2-1 au standard « 3-2-1-1-0 » (Immuabilité WORM anti-ransomware)

Entre 2020 et 2026, la menace principale a changé de nature : aujourd’hui, les ransomwares modernes (et les attaquants ayant compromis un serveur d’administration) ne se contentent plus de chiffrer le disque de production. Leur première action consiste à scanner le réseau local pour chiffrer les partages NFS/SMB du NAS et à utiliser les clés API AWS/S3 présentes sur le serveur pour purger les buckets de sauvegarde distants.

Pour parer ce scénario, la règle 3-2-1 a évolué vers le standard 3-2-1-1-0 :

• 3 copies des données ;
• 2 supports différents ;
• 1 copie hors site (Off-Site) ;
• + 1 copie IMMUABLE (WORM : Write Once, Read Many) ou Air-Gapped (hors ligne) ;
• + 0 erreur détectée lors des tests automatisés de restauration.

Comment rendre une sauvegarde techniquement indestructible en 2026 ?

1. Architecture Pull (NAS qui tire) plutôt que Push (Serveur qui pousse) : au lieu de donner au serveur de production les droits d’écriture/suppression sur le NAS, c’est un démon isolé sur le serveur de sauvegarde qui vient tirer les données en lecture seule, ou via BorgBackup en mode --append-only (une clé SSH dédiée ne peut qu’ajouter de nouveaux points de restauration et ne peut jamais exécuter borg delete ou borg prune).
2. S3 Object Lock (COMPLIANCE mode) : sur AWS S3, Backblaze B2 ou Scaleway Object Storage, activez le verrouillage d’objet WORM avec une rétention de 30 jours en mode COMPLIANCE. Même si un attaquant dérobe vos clés administrateur root du compte Cloud, il est mathématiquement et contractuellement impossible d’écraser ou de supprimer un bloc sauvegardé avant l’expiration des 30 jours.

Conclusion : Une sauvegarde non testée n’est qu’un espoir

Mettre en place une architecture 3-2-1-1-0 avec un NAS local (Synology / QNAP) et un stockage objet chiffré (Restic / Rclone) coûte aujourd’hui quelques euros par mois et quelques heures de configuration initiale. Mais retenez la loi fondamentale de l’ingénierie SRE : personne n’a besoin d’une sauvegarde ; tout le monde a besoin d’une restauration fonctionnelle. Planifiez un exercice de restauration trimestriel : c’est la seule preuve empirique qui garantit votre sérénité le jour où le matériel ou le datacenter flanchera.

Sources

1. Data Backup Options | CISA (Cybersecurity & Infrastructure Security Agency)
2. The 3-2-1 Backup Strategy | Backblaze Engineering Blog
3. Synology Hyper Backup & Immutable Snapshots | Synology Inc.
4. OVHcloud Strasbourg Data Center Fire Analysis | DataCenter Dynamics

Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome