Tous les systèmes de sauvegarde qui ont un jour lâché un client annonçaient un succès quotidien jusqu'au jour où l'on en a eu besoin. Le rapport dit que le fichier a été écrit. Il ne dit pas qu'il est lisible, qu'il contient ce que vous croyez, ni que le restaurer donne un site qui fonctionne.
Testez la restauration, pas la sauvegarde
- Prenez l'archive la plus récente — Pas une que vous auriez faite exprès. Il s'agit de tester le processus qui tourne sans surveillance.
- Restaurez-la ailleurs — Un sous-domaine, un second VPS, un conteneur local. Jamais par-dessus le site en production.
- Ouvrez le site restauré — Connectez-vous. Chargez une page qui lit la base de données. Vérifiez qu'un fichier récemment envoyé est bien là.
- Notez la date du contenu le plus récent — C'est votre véritable point de reprise, et il est souvent plus ancien que ne le laisse croire le calendrier de sauvegarde.
Ce qu'une restauration révèle d'ordinaire
- La base de données est là, mais pas les fichiers envoyés — la sauvegarde couvrait l'une et pas les autres.
- Elle se restaure mais ne démarre pas — un fichier de configuration avec les chemins ou les identifiants de l'ancien serveur.
- L'archive est tronquée — le disque s'est rempli pendant la sauvegarde et personne n'a vérifié le code de sortie.
- Elle est chiffrée et personne n'a la clé — la clé se trouvait sur le serveur qui est mort.
Une sauvegarde sur le même disque que le site n'est pas une sauvegarde. Elle protège d'une erreur, pas du disque, du serveur ni du compte. Au moins une copie vit ailleurs.
À quelle fréquence
La vraie question n'est pas la fréquence des sauvegardes mais la quantité de travail que vous acceptez de refaire. Quotidien signifie jusqu'à une journée de commandes perdue. Si c'est inacceptable, le quotidien est le mauvais rythme, quel que soit le coût de l'autre.
Inscrivez un test de restauration au calendrier, chaque trimestre. C'est le seul test qui prouve quelque chose, et le seul que personne ne fait.
