On parle beaucoup de sauvegardes. Tout le monde en fait. Enfin… tout le monde dit qu’il en fait.
Mais la vraie question, celle qui fait mal, c’est plutôt : est ce que tu peux prouver que tu sais restaurer. Et pas « théoriquement ». Pas « ça devrait marcher ». Je parle d’une restauration complète, documentée, reproductible, et qui tient devant un audit ou un incident réel.
Parce qu’au moment où ton serveur ne boote plus, où la base est corrompue, où tu as chiffré ton NAS par erreur (oui, ça arrive), tu n’as plus le luxe d’avoir une stratégie vague. Tu as besoin d’un scénario de restauration qui marche. Et d’une preuve.
Dans cet article, je te montre une approche très concrète, un peu « sysadmin qui a déjà souffert », pour prouver la restauration. Avec des exemples, des métriques, des tests, et surtout une logique qui peut s’appliquer à Linux, aux VM, aux conteneurs, aux bases de données, et même à tes projets perso.
Et si tu aimes ce genre de contenu pratique, tu peux aussi jeter un oeil à Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, j’y publie souvent des checklists, des méthodes, et des retours terrain.
La vérité simple : une sauvegarde n’existe pas tant qu’elle n’est pas restaurée
Une sauvegarde, c’est un fichier. Ou un set d’objets. Ou un snapshot.
Mais « sauvegarde fiable », ça veut dire : capacité à restaurer dans un délai donné, avec un résultat donné, sur une cible donnée, même si la prod est en feu.
Donc la preuve n’est pas « j’ai des archives ». La preuve c’est : j’ai déjà restauré, récemment, et je peux le refaire, et voilà comment.
En gros, pour qu’une sauvegarde soit crédible, il faut pouvoir répondre clairement à ce genre de questions :
- Restaurer quoi, exactement ? OS, données, config, secrets, licences, dépendances, jobs cron, certificats.
- Restaurer où ? même machine, nouvelle machine, autre région, lab, cloud.
- Restaurer en combien de temps ? (RTO)
- Perdre combien de données ? (RPO)
- Valider comment que c’est bon ? (tests, checksums, requêtes, smoke tests)
- Qui sait le faire ? une seule personne ou l’équipe.
- Et si l’outil de backup est indisponible ? et si la clé KMS est perdue ? et si le compte cloud est verrouillé ?
Ça fait beaucoup. Mais on peut rendre ça simple avec une méthode.
Les quatre preuves que je considère comme « solides »
Je te donne une grille simple. Si tu coches ces quatre preuves, tu es déjà au dessus de 90 % des systèmes de sauvegarde « décoratifs ».
1) Preuve d’existence : inventaire, rétention, copies
- Où sont stockées les sauvegardes, précisément.
- Combien de copies, sur quels supports.
- Quelle rétention.
- Quel chiffrement.
- Et surtout : comment on liste et on récupère une sauvegarde donnée sans interface magique.
Exemple de preuve simple : une commande ou un script qui sort la liste des backups avec date, taille, hash.
2) Preuve d’intégrité : hashes, validations, cohérence applicative
L’intégrité ce n’est pas juste « le fichier est là ». C’est :
- checksum (sha256, blake2, etc.)
- test d’archive (tar tzf, zstd test, etc.)
- cohérence base de données (pg_verifybackup, mysqlcheck, restauration à blanc)
- cohérence applicative (un export peut être intègre mais inutilisable)
3) Preuve de restauration : runbook + exécution récente
Un runbook sans exécution récente, c’est un roman.
La preuve : une restauration faite dans un environnement de test, avec des logs, une date, et idéalement un ticket ou un rapport signé.
4) Preuve de fonctionnement : tests post restore
Une restauration « qui finit » n’est pas forcément une restauration « qui marche ».
Il faut des tests post restauration :
- le service démarre
- les endpoints répondent
- la DB contient des données attendues
- les jobs planifiés tournent
- les permissions sont bonnes
- les secrets/certificats sont présents et valides
RTO et RPO : arrête de les inventer, mesure les
On voit souvent des RTO/RPO écrits au hasard dans un doc. « RTO 4h, RPO 15min ». Ok. Prouve.
La seule manière sérieuse : tu chronomètres une restauration complète.
Comment mesurer ton RTO (concrètement)
Tu prends un scénario réaliste :
- VM détruite
- disque OS corrompu
- DB perdue
- ou suppression accidentelle d’un répertoire critique
Et tu mesures :
- temps pour identifier le bon point de restauration
- temps pour récupérer le média (download, mount, decrypt)
- temps de restauration brute (copie, import)
- temps de remise en route (services, réseau, DNS, LB)
- temps de validation (tests)
Le résultat, c’est ton RTO réel. Pas celui que tu souhaites.
Comment mesurer ton RPO (sans se mentir)
Tu regardes la fréquence réelle des points de backup utilisables.
- Si tu fais un backup quotidien à 02:00, ton RPO typique c’est proche de 24h, même si « en moyenne » tu perds moins.
- Si tu fais du PITR PostgreSQL avec WAL shipping toutes les minutes, là oui, tu peux descendre à quelques minutes. Mais seulement si la chaîne WAL est complète et restaurable.
Le RPO se prouve avec une restauration à une heure précise. Pas avec une promesse.
Construire un protocole de test de restauration (simple mais carré)
On va faire ça comme un protocole. Répétable. Pas un truc freestyle.
Étape 1 : choisir les scénarios de panne (les vrais)
Tu n’as pas besoin de 50 scénarios. Prends 5 qui couvrent 80 % des risques :
- suppression accidentelle d’un fichier ou dossier
- corruption de base de données
- VM ou serveur non bootable
- ransomware sur partages
- perte totale d’un site ou d’un compte cloud
Tu peux en ajouter selon ton contexte (Kubernetes etc.), mais déjà ça, c’est solide.
Étape 2 : définir l’environnement de restauration
Le piège classique : restaurer sur la prod. Non.
Tu veux un environnement isolé :
- un VLAN de lab
- un compte cloud « sandbox »
- une VM de test
- ou même une machine locale si c’est un petit projet
L’idée : restaurer sans danger, mais dans des conditions proches.
Étape 3 : écrire un runbook qui tient en 2 pages
Je suis sérieux. Si ton runbook fait 30 pages, personne ne l’utilisera en incident. Il faut :
- prérequis (accès, clés, outils)
- commande ou procédure de restauration
- points de contrôle
- tests post restauration
- « quoi faire si ça rate »
Exemple de structure :
- objectif
- périmètre
- prérequis
- procédure pas à pas
- validation
- rollback ou dépannage
Et tu y mets des commandes réelles, pas « restaurer la base ».
Étape 4 : exécuter et capturer des preuves
Preuves possibles :
- logs de l’outil de backup
- captures console
- exports de commandes (date, hostname, version)
- hash des fichiers restaurés
- résultats de tests applicatifs
Oui, c’est un peu administratif. Mais c’est ça qui te sauve quand quelqu’un demande : « comment tu sais que ça marche ».
Exemples concrets de preuves (Linux, VM, base de données)
Exemple A : restauration de fichiers avec checksums
Tu veux prouver que le fichier restauré est identique à l’original sauvegardé.
- Avant incident, tu calcules un hash et tu le stockes (ou tu le recalcules depuis la sauvegarde).
bash sha256sum /data/clients.csv > clients.csv.sha256
- Après restauration :
bash sha256sum -c clients.csv.sha256
Tu gardes le log. C’est une preuve d’intégrité simple.
Exemple B : restauration PostgreSQL et preuve fonctionnelle
Une vraie preuve ici ce n’est pas « postgres démarre ». C’est :
- la base est cohérente
- les tables existent
- des requêtes métiers passent
Après restauration, tu peux faire :
bash psql -d appdb -c "select count(*) from users;" psql -d appdb -c "select max(created_at) from orders;"
Et tu compares avec un attendu (même approximatif, mais logique).
Si tu fais du PITR, tu notes l’horodatage exact restauré. C’est ça qui prouve ton RPO.
Exemple C : VM complète restaurée, preuve de boot et services
Pour une VM, ta preuve minimale :
- boot ok
- ssh ok
- services critiques ok
Exemple :
bash systemctl is-active nginx systemctl is-active postgresql curl -fsS http://127.0.0.1/health
Et tu journalises.
Le piège des sauvegardes chiffrées : prouver que tu peux déchiffrer
Le chiffrement est indispensable. Mais il introduit un risque énorme : la clé.
Donc la preuve doit inclure :
- où est stockée la clé
- qui y a accès
- comment on la récupère en situation de crise
- test réel de déchiffrement
Si tu utilises age, gpg, KMS, Vault, LUKS, peu importe. Tu dois faire un test « à froid » : machine neuve, tu récupères la clé, tu déchiffres, tu restaures.
Beaucoup de gens découvrent trop tard qu’ils ont chiffré… et perdu l’accès.
Le piège du « backup réussi » : les alertes ne prouvent rien
Un mail « Backup completed successfully » ne prouve pas que :
- l’archive est lisible
- la rétention est correcte
- la restauration est faisable
- les données sont complètes
Donc, ajoute au minimum :
- une vérification d’intégrité automatique (test archive + checksum)
- un test de restauration planifié (mensuel, hebdo selon criticité)
Et surtout : surveille la taille des sauvegardes. Une DB qui passe de 50 Go à 3 Go sans raison, ça sent mauvais. Parfois c’est juste la compression. Parfois c’est un backup vide.
Mettre en place une « restauration de contrôle » automatique (oui, même en petit)
Tu n’es pas obligé d’avoir une usine à gaz. Même un projet perso peut avoir un mini pipeline :
- chaque semaine, prendre la dernière sauvegarde
- restaurer dans un conteneur ou une VM jetable
- lancer des tests simples
- publier un rapport
Tu peux faire ça avec :
- cron + scripts bash
- GitHub Actions (si données accessibles)
- un runner self hosted
- Ansible pour rejouer la procédure proprement
L’idée : industrialiser la preuve.
Checklist « audit ready » : ce que je mettrais dans ton dossier de preuves
Si demain on te demande « prouve que tu peux restaurer », tu veux un dossier avec :
- une page d’architecture des sauvegardes (où, quoi, fréquence, rétention)
- un tableau RTO/RPO mesuré (avec date de test)
- les runbooks de restauration (versionnés)
- les rapports des derniers tests de restauration
- les logs d’intégrité (hash, test archive)
- la procédure d’accès aux clés (avec un plan B)
- la liste des personnes formées + date du dernier exercice
Simple. Pas parfait. Mais solide.
Un mot sur la documentation : elle doit être vivante, sinon elle ment
La doc de restauration doit être mise à jour quand :
- tu changes de version de DB
- tu migres de VM à conteneurs
- tu modifies les chemins de données
- tu changes la stratégie de chiffrement
- tu changes l’outil de backup
Donc oui, c’est du boulot. Mais le jour où ça casse, tu seras content d’avoir une doc qui ne raconte pas une autre époque.
Perso, j’aime bien mettre ces runbooks dans un repo Git privé, avec un dossier /restore-tests/ qui contient les rapports horodatés. Ça se versionne. Et ça prouve l’historique.
Mini plan d’action : si tu veux améliorer ça cette semaine
Tu peux faire ça en 3 sessions, pas besoin d’un trimestre :
- Aujourd’hui : choisis 2 scénarios (suppression fichier + base corrompue), écris un runbook court.
- Cette semaine : restaure dans un lab, mesure le temps, capture les preuves.
- Ensuite : programme un test mensuel automatique, même basique.
Et si tu veux, tu peux aussi t’inspirer d’autres articles orientés productivité et sysadmin sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com). Je publie régulièrement des méthodes « build, scale, sell », mais côté infra, ça reste la même philosophie : ce qui compte c’est ce qui tient en conditions réelles.
Conclusion : prouver la restauration, c’est gagner du temps quand tout va mal
La sauvegarde n’est pas un fichier. C’est une capacité.
Si tu peux montrer : un test récent, un runbook clair, un RTO mesuré, des validations post restore, et des preuves d’intégrité, alors oui, tu as des sauvegardes fiables.
Sinon… tu as surtout de l’espoir compressé en .tar.gz.
Et l’espoir, en incident, ça ne boote pas.
Questions fréquemment posées
Pourquoi est-il crucial de prouver la capacité à restaurer une sauvegarde ?
Parce qu'une sauvegarde n'est pas fiable tant qu'elle n'a pas été restaurée avec succès. En cas d'incident réel, comme un serveur qui ne démarre plus ou une base corrompue, il faut un scénario de restauration complet, documenté et reproductible pour garantir que les données peuvent être récupérées rapidement et efficacement.
Quels éléments doivent être clairement définis pour qu'une sauvegarde soit crédible ?
Il faut savoir quoi restaurer (OS, données, configurations, secrets), où restaurer (même machine, nouvelle machine, cloud), en combien de temps (RTO), combien de données on peut perdre (RPO), comment valider la restauration (tests, checksums), qui sait effectuer la restauration et comment gérer les situations où les outils de backup sont indisponibles.
Quelles sont les quatre preuves essentielles pour garantir la fiabilité d'un système de sauvegarde ?
- Preuve d'existence : inventaire clair des sauvegardes avec rétention et copies. 2) Preuve d'intégrité : validations par checksums et cohérence applicative. 3) Preuve de restauration : runbook documenté avec exécution récente. 4) Preuve de fonctionnement : tests post-restauration confirmant le bon fonctionnement du service.
Comment valider l'intégrité d'une sauvegarde au-delà de sa simple existence ?
En utilisant des checksums comme sha256 ou blake2, en testant l'archive (par exemple avec tar tzf ou zstd test), en vérifiant la cohérence des bases de données via des outils dédiés et en s'assurant que les données exportées sont utilisables dans l'application cible.
Pourquoi un runbook sans exécution récente n'est-il pas suffisant ?
Parce qu'un runbook est un guide théorique. Sans avoir réalisé une restauration récente et documentée avec logs et rapports, on ne peut pas garantir que la procédure fonctionne réellement en situation d'urgence.
Quels tests doivent être effectués après une restauration pour garantir son succès ?
Après restauration, il faut vérifier que le service démarre correctement, que les endpoints répondent aux requêtes, que la base de données contient les données attendues, que les jobs planifiés s'exécutent bien, que les permissions sont correctes et que les secrets ou certificats nécessaires sont présents et valides.
0 Commentaires