Une sauvegarde peut être parfaitement correcte et ne protéger qu’une partie du travail.
Elle répond alors à une première question : qu’avons-nous conservé ?
La question suivante est plus concrète : pouvons-nous reprendre le travail à partir de ce contenu ?
Ces deux questions se ressemblent. Elles ne vérifient pas la même chose.
Une copie ne remet pas un système en marche
Un dépôt de code conserve ce qui a été construit. Un export de données saisit un état de l’activité. Une copie de fichiers protège les documents et les pièces jointes.
Chaque élément compte. Aucun ne suffit à lui seul.
Le code ne contient pas automatiquement les données actuelles. Les données peuvent perdre leurs relations. Les comptes utilisateurs ne recréent pas les rôles et les droits. Les connexions restent inactives tant que personne ne sait qui les détient et comment les autoriser à nouveau.
La sauvegarde peut donc être juste sans que le chemin vers le travail soit encore complet.
Cinq éléments doivent se rejoindre
- Le code et sa configuration de construction. Il faut disposer de la bonne version, de ses dépendances et des indications nécessaires pour la remettre en route.
- Les structures, les identités et les droits. Les schémas, les relations, les rôles et les règles d’accès donnent leur sens aux contenus sauvegardés.
- Les données métier et les fichiers. Les enregistrements, leurs liens, les documents et les pièces jointes doivent retrouver un état utilisable.
- Les connexions et les accès. Les mots de passe et les jetons n’ont pas leur place dans un export ordinaire. Il faut toutefois connaître le propriétaire de chaque connexion et la procédure pour l’autoriser de nouveau en sécurité.
- Une reconstruction vérifiée. La documentation décrit le chemin. Un test accompli montre s’il fonctionne.
C’est leur combinaison qui permet de reprendre l’activité.
La restauration constitue le vrai test
Le premier essai se fait dans un environnement isolé.
On peut alors comparer les volumes, vérifier les relations, retrouver les fichiers, recréer les droits et exécuter les parcours essentiels.
Une restauration réussie chez le fournisseur actuel prouve que le retour fonctionne sur cette plateforme.
Elle ne prouve pas encore que le système peut vivre ailleurs.
Pour établir cette autonomie, il faut aussi effectuer un test dans un environnement neutre. Il ne s’agit pas de mettre en scène une urgence. Il s’agit de savoir si l’entreprise peut choisir son prochain mouvement en connaissance de cause.
Cinq questions simples
- La personne responsable trouve-t-elle le code actuel et les instructions de construction ?
- Peut-on restaurer ensemble les données, leurs relations et leurs fichiers ?
- Les propriétaires des comptes, les rôles et les droits sont-ils documentés ?
- Existe-t-il un inventaire des connexions et un chemin sûr pour les autoriser de nouveau ?
- Quand la dernière restauration a-t-elle été réalisée et qu’a-t-on réellement vérifié ?
Une réponse incomplète reste utile. Elle montre la prochaine pièce à clarifier.
Une sauvegarde montre ce qui a été conservé. Une restauration testée montre si le travail peut reprendre.
Patrick Thole, Disruption Dynamics, Zurich
disruption-dynamics.ch