Une sauvegarde jamais restaurée est une hypothèse
Une tâche de sauvegarde peut échouer pendant des mois sans que personne ne le voie. Le seul moyen de savoir, c'est de restaurer pour de vrai.
Le piège de la sauvegarde qui « tourne »
Une tâche de sauvegarde peut planter chaque nuit pendant des mois — permission changée, disque de destination plein, identifiants expirés — sans que personne ne le remarque, parce que rien ne surveille son résultat. Le job apparaît « exécuté » dans le journal, un fichier est bien créé quelque part, et tout semble normal jusqu'au jour où l'on en a réellement besoin.
La seule preuve qui compte : restaurer ces données ailleurs et vérifier qu'un site fonctionne dessus. Une archive qui existe n'est pas une garantie ; une restauration qui a marché, si.
Le protocole en 6 points
Chaque test suit la même séquence, dans le même ordre. C'est ce qui le rend reproductible d'une fois sur l'autre, et comparable dans le temps.
Restaurer sur un environnement isolé
Jamais sur la production. Une machine ou un conteneur dédié, déconnecté du site en ligne. Restaurer « pour voir » sur la prod a déjà écrasé des données vivantes.
Vérifier l'intégrité
Comparer le volume restauré au volume attendu, et contrôler les sommes de contrôle quand l'outil les fournit. Un écart de taille inexpliqué est un signal, pas un détail.
Comparer les inventaires
Compter les fichiers, les lignes des tables principales, les boîtes mail. Une restauration qui ramène 90 % des données est un échec, pas un succès partiel.
Démarrer l'application
Le test décisif. Lancer le site sur les données restaurées et parcourir les parcours critiques : page d'accueil, connexion, commande, formulaire. Des fichiers restaurés ne prouvent rien.
Chronométrer
Noter le temps écoulé entre le début de la restauration et le moment où l'application répond. Ce chiffre est votre RTO réel. Il est presque toujours plus élevé que prévu.
Documenter
Écrire la procédure suivie, les écarts constatés, la durée. Un test non documenté oblige à tout redécouvrir au prochain incident, sous pression.
RPO et RTO : les deux chiffres qu'un test révèle
Deux objectifs se décident avant l'incident, pas pendant — et un test chronométré est le seul moyen de savoir si le RTO théorique correspond au RTO réel.
Recovery Point Objective
Combien de données puis-je perdre ?
Exprimé en temps. Des sauvegardes quotidiennes donnent un RPO de 24 heures : au pire, une journée de saisie à refaire. C'est le RPO qui fixe la fréquence des sauvegardes.
Recovery Time Objective
En combien de temps dois-je être reparti ?
Le délai acceptable entre l'incident et le retour au service. C'est le RTO qui dicte la méthode de restauration et le budget d'infrastructure — et seul un test chronométré révèle le vrai.
Ce qu'on vérifie chez un client
Sept questions, posées dans cet ordre, lors de l'audit de l'existant qui ouvre toute mise en place de sauvegarde. La plupart des clients découvrent la réponse à au moins une d'entre elles.
- ? Les tâches de sauvegarde se sont-elles exécutées sans erreur ces 30 derniers jours ?
- ? Quelqu'un reçoit-il une alerte quand une sauvegarde échoue, et cette alerte est-elle lue ?
- ? La dernière restauration de contrôle date de quand, et sur quel périmètre ?
- ? Les boîtes mail sont-elles dans le périmètre, ou seulement les fichiers et la base ?
- ? Une copie est-elle hors site et hors d'atteinte d'un ransomware sur la machine source ?
- ? La procédure de restauration est-elle écrite quelque part qu'un tiers pourrait suivre ?
- ? Sauriez-vous dire, chiffre en main, combien de temps prend une restauration complète ?
Questions fréquentes
À quelle fréquence tester une restauration ? +
Le rythme dépend de l'enjeu, mais deux règles valent partout. D'abord, tout test vaut mieux qu'aucun : une restauration de contrôle par trimestre suffit à détecter les pannes silencieuses sur un site vitrine. Ensuite, un test est obligatoire après tout changement d'infrastructure — migration, changement d'hébergeur, mise à jour majeure, modification du script de sauvegarde. C'est précisément à ces moments que les sauvegardes cassent sans prévenir.
Que vérifie-t-on exactement lors d'un test ? +
Quatre choses, dans cet ordre. Que les données restaurées sont intègres, en comparant les volumes et en contrôlant les sommes de contrôle quand l'outil les fournit. Que l'application démarre réellement sur les données restaurées — un dossier de fichiers restauré n'est pas un site qui fonctionne. Que rien ne manque : les fichiers récents, la base, la configuration, les mails. Et combien de temps l'opération a pris, parce que ce chiffre est votre RTO réel, pas celui que vous espériez.
Quelle différence entre RPO et RTO ? +
Le RPO est la quantité de données que vous acceptez de perdre, exprimée en temps : avec des sauvegardes quotidiennes, votre RPO est de 24 heures, donc au pire vous perdez une journée de saisie. Le RTO est le délai pour être de nouveau opérationnel après l'incident. Les deux se décident avant, pas pendant : le RPO détermine la fréquence des sauvegardes, le RTO détermine la méthode de restauration et le budget d'infrastructure.
Faire tester vos restaurations
On audite l'existant, on met en place ce qui manque et on réalise une restauration réelle, chronométrée et documentée.