Sauvegarde, restauration et immuabilité
Concevoir une stratégie de sauvegarde 3-2-1 testée, incluant l'immuabilité contre les rançongiciels.
À retenir
- La règle 3-2-1 (étendue en 3-2-1-1-0) reste la base d'une stratégie de sauvegarde robuste.
- Une sauvegarde non testée en restauration n'offre aucune garantie réelle.
- L'immuabilité (WORM/Object Lock) protège les sauvegardes contre les rançongiciels ciblant les comptes administrateurs.
- RPO et RTO doivent être définis avec les métiers, puis validés par des tests grandeur réelle.
La règle 3-2-1, toujours d'actualité
La règle de sauvegarde 3-2-1 reste la base de toute stratégie de continuité d'activité : 3 copies des données, sur 2 supports différents, dont 1 copie hors site (ou hors ligne). Face à la menace des rançongiciels, une variante étendue 3-2-1-1-0 ajoute une copie immuable (air-gapped ou en mode WORM) et zéro erreur constatée lors des tests de restauration.
| Élément | Signification | Exemple concret |
|---|---|---|
| 3 copies | Original + 2 sauvegardes | Production + backup local + backup distant |
| 2 supports | Deux technologies différentes | Disque + bande, ou disque + stockage objet |
| 1 copie hors site | Résilience géographique | Réplication vers un site distant ou un cloud |
| 1 copie immuable | Résistance aux rançongiciels | Object Lock S3, bande hors ligne |
| 0 erreur | Tests de restauration réguliers validés | Restauration trimestrielle documentée |
Point clé
une sauvegarde qui n'a jamais été restaurée en test n'est pas une sauvegarde fiable, c'est une hypothèse. La restauration doit être testée avec la même rigueur que la sauvegarde elle-même.
Sauvegarde complète, incrémentale, différentielle
- Complète : copie intégrale des données, la plus simple à restaurer mais la plus longue et volumineuse à réaliser.
- Incrémentale : ne copie que ce qui a changé depuis la dernière sauvegarde (complète ou incrémentale) ; rapide à réaliser, mais restauration plus complexe (chaîne de dépendances).
- Différentielle : copie tout ce qui a changé depuis la dernière sauvegarde complète ; compromis entre vitesse de sauvegarde et simplicité de restauration.
Attention
une chaîne d'incrémentales trop longue sans sauvegarde complète récente augmente le risque : la corruption d'un seul maillon de la chaîne peut rendre inutilisables toutes les sauvegardes incrémentales suivantes.
L'immuabilité contre les rançongiciels
Les attaques par rançongiciel ciblent désormais explicitement les systèmes de sauvegarde avant de chiffrer la production, pour empêcher toute restauration. L'immuabilité (WORM — Write Once Read Many) empêche la modification ou la suppression d'une sauvegarde pendant une durée définie, même par un compte administrateur compromis.
# Exemple : verrouillage d'objet immuable en mode conformité (S3 Object Lock)
aws s3api put-object-lock-configuration --bucket mon-bucket-backups --object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 30 } }
}'
En mode « COMPLIANCE », même le compte root du fournisseur ne peut pas supprimer l'objet avant l'expiration de la période de rétention, ce qui constitue une protection réelle contre un compte compromis.
RPO et RTO : les deux métriques qui pilotent la stratégie
- RPO (Recovery Point Objective) : quantité de données qu'on accepte de perdre, exprimée en temps (ex. 15 minutes, 24 heures).
- RTO (Recovery Time Objective) : délai maximal acceptable pour restaurer le service après un incident.
Ces deux valeurs, définies avec les métiers et non par la seule équipe technique, déterminent la fréquence des sauvegardes et l'architecture de restauration (snapshot, réplication continue, restauration à froid).
Sur le terrain
lors d'un exercice de reprise après incident chez un client bancaire, l'équipe a découvert que la restauration complète prenait 18 heures alors que le RTO contractuel était de 4 heures — un écart révélé uniquement par un test grandeur réelle, jamais par la documentation théorique du plan de reprise.
Astuce
documentez et chronométrez chaque test de restauration comme un runbook opérationnel ; en cas d'incident réel à 3h du matin, c'est ce document — pas la mémoire de l'équipe — qui doit guider la reprise.