Une sauvegarde n'est pas un fichier : c'est une promesse de retour en arrière. Tant que cette promesse n'a pas été tenue au moins une fois, elle n'a aucune valeur démontrée.
Ce qu'on découvre en testant
Les restaurations qui échouent échouent rarement pour une raison spectaculaire. L'archive est là, mais elle ne contient pas la base. Ou elle la contient, mais sans les fichiers envoyés par les utilisateurs. Ou tout est là, et personne ne connaît le mot de passe du compte qui permet de remonter l'ensemble.
Le point commun : on ne s'en aperçoit qu'au pire moment, quand le site est déjà à l'arrêt et que le temps compte double.
Trois questions à se poser aujourd'hui
Combien de temps faut-il pour revenir en ligne ? Pas en théorie : chronométrez une restauration réelle sur un environnement de test. Le chiffre obtenu est souvent trois à cinq fois supérieur à l'estimation.
Combien de données peut-on se permettre de perdre ? Une sauvegarde quotidienne signifie que vous acceptez de perdre jusqu'à vingt-quatre heures de commandes, d'inscriptions ou de messages. Pour certains métiers c'est indolore, pour d'autres c'est inenvisageable.
Où vivent les copies ? Une sauvegarde stockée sur le même serveur que le site disparaît avec lui. Une sauvegarde chez le même hébergeur disparaît avec l'hébergeur.
La discipline qui change tout
Planifiez une restauration de test à date fixe, comme n'importe quelle autre tâche d'exploitation. Trimestrielle suffit pour la plupart des projets. Notez le temps, notez ce qui a manqué, corrigez. La deuxième fois sera deux fois plus rapide.
C'est peu spectaculaire, et c'est précisément le genre de travail qui distingue un produit qu'on opère d'un site qu'on a livré.