Sans test, une sauvegarde reste une hypothèse
Les voyants verts dans la console de sauvegarde ne disent qu’une chose. La tâche s’est exécutée et s’est terminée sans erreur. Ils ne montrent pas si cette sauvegarde permet de rétablir un service opérationnel, auquel une personne peut se connecter et sur lequel elle peut travailler.
Entre les deux, l’écart est considérable et se révèle toujours au pire moment. Le jour de la panne, lorsque les utilisateurs attendent le retour du système et que les clients appellent. Une sauvegarde qui n’a jamais été restaurée ne constitue pas une protection. Elle reste une hypothèse.
La raison de cet écart est banale. Le logiciel de sauvegarde rend compte de son propre travail, c’est-à-dire qu’il indique s’il a pu lire les données et les enregistrer dans une copie. Il ne vérifie pas si celle-ci contient tout ce qui est nécessaire pour remettre le service en place à partir de zéro, car il ne peut pas le savoir. Seule la personne qui exploite ce service le sait, et seulement après avoir réellement tenté de le restaurer.
Cela se retrouve même dans les règles de référence du secteur. La règle classique 3-2-1 prévoit trois copies des données sur deux types de supports, dont une conservée hors site. Sa version plus récente, 3-2-1-1-0, ajoute une copie isolée du réseau et zéro erreur. Ce zéro désigne des sauvegardes vérifiées par des tests de restauration réguliers. Le test n’est pas un complément à la sauvegarde. Il en fait partie.
Restaurer un fichier ou un service complet
Ce sont deux opérations totalement différentes, que l’on désigne pourtant très souvent par le même terme.
La restauration d’un fichier prouve que le support fonctionne, que le catalogue des sauvegardes est cohérent et que les données peuvent être récupérées. Elle prend quelques minutes et une seule personne suffit. Un test utile, mais très limité.
La restauration d’un service prouve tout autre chose, car elle vérifie l’ensemble de la chaîne. Elle couvre la machine, le système d’exploitation, la configuration, la base de données, les comptes et les droits, la licence, l’adressage, le certificat ainsi que les liens avec les autres systèmes. Elle prend plusieurs heures et mobilise plusieurs personnes. Seul ce test répond à la question que la direction pose réellement. L’entreprise pourra-t-elle reprendre son activité ?
La plupart des entreprises qui affirment avoir testé leurs sauvegardes ont testé des fichiers.
Comment se déroule un test de restauration
Un test de restauration est un exercice planifié dont le périmètre est défini. Il ne s’agit pas de tout remettre en service en une seule fois. Il comporte quatre éléments, dont aucun ne peut être omis.
Ce que nous restaurons. Nous choisissons ce dont l’absence paralyse l’entreprise en premier. Il s’agit généralement d’un système avec sa base de données, de la messagerie ou d’un serveur de fichiers, et non de toute la salle des serveurs.
Où nous restaurons. Dans un environnement isolé, c’est-à-dire un réseau distinct sans route vers la production. Ce n’est pas une formalité. Un serveur restauré ne sait pas qu’il s’agit d’une copie. Si nous le laissons faire, il commencera à recevoir les e-mails, à écrire dans la base de données, à se répliquer et à envoyer des données vers l’extérieur.
Comment nous mesurons le temps et qui valide le résultat. Le temps est compté depuis la décision de restaurer jusqu’au moment où une personne travaille réellement dans le système, et non depuis le lancement de la tâche jusqu’à la fin de la copie des données. L’exhaustivité est validée par la personne qui utilise ce système chaque jour, et non par l’administrateur. La comptable ouvre un document d’une date précise. Le commercial recherche son propre devis. Un administrateur verra que le service fonctionne, mais pas qu’il manque les données des deux derniers jours.
Ce que le premier test révèle le plus souvent
Le premier test se déroule rarement sans difficulté. C’est précisément ce qui fait toute sa valeur. Les problèmes suivants reviennent régulièrement :
- le service démarre, mais attend un contrôleur de domaine, un serveur de licences ou un autre système que personne n’a inscrit sur la liste des éléments à restaurer,
- le mot de passe d’un compte de service a été défini une seule fois, lors du déploiement, par une personne qui ne travaille plus dans l’entreprise, de sorte que la sauvegarde existe mais pas le mot de passe,
- la sauvegarde de la base de données ne contient aucun journal de transactions, de sorte que la base repart dans l’état de la dernière sauvegarde complète et non dans celui qui précédait la panne,
- la sauvegarde de la machine n’inclut pas la configuration réseau, si bien que la machine fonctionne mais n’a ni adressage, ni VLAN, ni règles de pare-feu, ni service publié, et que personne ne peut y accéder,
- personne ne connaît l’ordre dans lequel les services doivent démarrer, de sorte qu’ils se bloquent mutuellement,
- un certificat a expiré ou une licence est liée à l’ancien matériel, de sorte que le service démarre et refuse aussitôt de fonctionner.
Aucun de ces problèmes n’apparaît dans la console de sauvegarde. Ils se manifestent tous dès la première heure du test.
Les enseignements du premier test valent davantage que son résultat, car chacun de ces problèmes peut être corrigé à l’avance. Un système manquant est ajouté au périmètre des sauvegardes. Les mots de passe des comptes de service sont transférés dans le gestionnaire de mots de passe de l’entreprise. La sauvegarde des journaux de transactions est simplement activée. Il suffit de consigner une fois par écrit l’adressage, les règles et l’ordre de démarrage. Une correction avant la panne coûte quelques heures de travail. La même correction pendant la panne coûte une journée de travail à toute l’entreprise.
Un test trop lent est aussi un échec
Il arrive qu’un test réussisse tout en étant un échec. Les données sont complètes et le service fonctionne, mais la restauration a pris plusieurs fois plus de temps que ne l’avait prévu quiconque dans l’entreprise.
La durée fait donc partie du résultat du test, au même titre que l’exhaustivité des données. Elle doit être mesurée avant la panne et non pendant. Une fois la durée réelle connue, il existe trois possibilités : modifier le mode de stockage des sauvegardes, préparer une procédure de restauration plus courte pour les systèmes les plus importants, ou accepter ce délai en connaissance de cause et en informer les personnes dans l’entreprise. Chacune de ces possibilités vaut mieux que de découvrir la réalité un vendredi soir.
La mesure du temps détermine aussi l’ordre. Puisque tout ne redémarre pas en même temps, quelqu’un doit décider de ce qui repart en premier. C’est une décision métier, pas une décision technique, et mieux vaut la prendre au calme.
Ce délai mesuré doit aussi être connu par une personne extérieure au service informatique. La personne responsable de l’entreprise ne perçoit pas de la même façon une phrase indiquant qu’une restauration prend une demi-journée et un graphique dans la console de sauvegarde. Elle seule peut dire si une demi-journée est acceptable ou s’il faut payer pour réduire ce délai.
À quelle fréquence effectuer les tests
Un test ponctuel rassure pour une journée. L’environnement évolue, et un résultat de l’an dernier décrit l’an dernier.
Un rythme raisonnable fonctionne à deux vitesses. Le petit test, qui consiste à restaurer un fichier ou une seule machine, est effectué souvent et prend peu de temps. Le test complet, qui consiste à restaurer l’ensemble d’un service avec validation par un utilisateur, est effectué moins souvent, mais à une date planifiée et avec une préparation en amont.
Quel que soit le rythme, certains événements imposent de refaire le test :
- l’ajout d’un nouveau système ou d’une nouvelle machine dans l’environnement,
- un changement de version du système d’exploitation, de la base de données ou du logiciel de sauvegarde,
- un changement de l’emplacement de stockage des sauvegardes ou de leur durée de conservation,
- une modification de l’adressage, du pare-feu ou du mode de publication d’un service,
- un changement concernant les personnes ayant accès à la console de sauvegarde.
La règle est simple. Si quelque chose a changé qui pourrait influer sur la restauration, c’est que quelque chose a changé qui invalide le test précédent.
Que consigner dans le compte rendu
Un test non documenté n’est qu’une anecdote. Le compte rendu n’a pas besoin d’être long, mais il doit toujours suivre la même trame afin de pouvoir comparer deux tests réalisés à un an d’intervalle.
Il doit contenir les éléments suivants :
- la date du test et les personnes qui y ont participé,
- ce qui a été restauré, la sauvegarde utilisée et la date de cette sauvegarde,
- la destination de la restauration, c’est-à-dire une description de l’environnement isolé,
- l’heure de début, l’heure de fin et la durée mesurée jusqu’au moment où le système était utilisable,
- qui a confirmé que les données étaient complètes et en quoi a consisté cette confirmation,
- ce qui n’a pas fonctionné, les mesures prises et les modifications apportées à la configuration,
- la date et le périmètre du prochain test.
Ce document se révèle utile dans trois situations : lors d’un audit, lors d’un échange avec un assureur et lors d’un changement de prestataire informatique, quand quelqu’un demande la date de la dernière restauration réussie.
C’est toutefois lors du deuxième et du troisième test que le compte rendu prend toute sa valeur. Il permet alors de voir si le temps de restauration augmente avec le volume de données, si les observations formulées lors du test précédent ont été prises en compte et si le périmètre du test couvre aussi les systèmes ajoutés au cours de l’année. Un compte rendu consigne un événement. Trois comptes rendus montrent déjà la direction prise par l’entreprise.
Une question qui mérite d’être posée
Si vous voulez savoir ce qu’il en est réellement de vos sauvegardes, il suffit de poser une question à la personne ou à l’entreprise qui s’en charge. Quand avons-nous restauré pour la dernière fois des données à partir d’une sauvegarde et qu’avons-nous restauré exactement ?
Dire que les sauvegardes sont effectuées chaque jour et qu’aucune erreur n’est signalée ne répond pas à cette question. La réponse doit indiquer une date, le périmètre et le nom de la personne qui a confirmé que les données étaient complètes. Si personne ne peut vous fournir ces éléments, cela ne signifie pas encore que les sauvegardes sont défectueuses. Cela signifie seulement que personne ne le sait.
Nous réalisons des tests de restauration chez nos clients, car sans eux, la gestion des sauvegardes reste une simple promesse. Si vous souhaitez vérifier vos sauvegardes et ne savez pas par où commencer, appelez-nous au +48 662 036 615 ou écrivez-nous à [email protected].