Le test de restauration : le seul jour où vous savez que la sauvegarde existe

L’article qui accompagne celui-ci pose la règle des trois copies, dit ce que les installations oublient de sauvegarder, et consacre une section à l’affirmation qui compte le plus : la restauration est la seule preuve. Puis il passe à autre chose, parce qu’il a onze autres sujets.

Cette page est cette section exécutée. Un test de restauration est une opération datée, avec une personne responsable, une machine de destination, un chronomètre et un procès-verbal d’une page.

La distinction à tenir dès maintenant : une sauvegarde qui tourne et une sauvegarde qui restaure sont deux affirmations différentes, et la première est vérifiée tous les jours par un voyant vert pendant que la seconde n’est vérifiée par personne.

Nous ne donnons dans cet article aucune durée de référence, et la raison est dite dans la section qui la concerne : le seul chiffre utile est celui que votre propre test produira, et le citer d’avance donnerait une raison de ne pas le mesurer.

Le test doit être conduit par quelqu’un qui n’a pas configuré la sauvegarde, et c’est la règle la plus souvent négligée parce qu’elle est la moins commode.

La raison n’est pas la défiance. Celui qui a monté le système connaît les chemins, les mots de passe et les contournements ; il restaure donc en s’appuyant sur des choses qui n’existent que dans sa tête, et le test réussit pour une raison qui ne sera pas disponible le jour de la panne.

Le jour de la panne, la personne devant l’écran est souvent quelqu’un d’autre — un collègue, un prestataire différent, vous. Le test doit ressembler à ce jour-là.

La forme pratique est simple : celui qui a installé reste joignable mais ne touche pas le clavier, et chaque fois qu’on doit l’appeler, on le note. Le nombre d’appels est un résultat du test au même titre que la durée.

Dans une très petite structure où une seule personne sait tout faire, la règle devient : cette personne écrit la procédure avant, et quelqu’un d’autre l’exécute en la suivant. Si elle ne suffit pas, c’est la procédure qui est le livrable manquant.

La liste se prépare avant le test, et l’ordre est celui dans lequel l’entreprise redémarre plutôt que celui dans lequel les machines sont rangées.

Commencez par ce qui bloque tout le reste : l’annuaire ou le contrôleur qui distribue les comptes, puis le serveur de fichiers ou la base qui porte l’activité, puis les postes. Restaurer un poste avant l’annuaire produit une machine que personne ne peut ouvrir.

Descendez ensuite d’un cran vers ce qui ne vit pas sur les serveurs : la messagerie, les documents de la comptabilité, les fichiers stockés sur le poste de la personne qui les tient. L’article compagnon consacre une section entière à ce que les installations oublient ; le test est l’endroit où cet oubli devient visible.

N’oubliez pas les éléments qui ne sont pas des données : la configuration du pare-feu, celle du commutateur, les licences, la liste des accès. Une entreprise dont les données reviennent parfaitement et dont personne ne sait reconfigurer le réseau n’a pas redémarré.

Enfin, décidez à l’avance jusqu’où va le test. Un test qui prétend tout restaurer prend deux jours et n’est jamais refait ; un test qui restaure la chaîne critique prend une demi-journée et a lieu deux fois par an.

Quatre constats reviennent, et les connaître d’avance évite de croire à un incident isolé.

Le premier est un volume plus grand que prévu. La sauvegarde couvre bien ce qu’on lui a désigné, et l’entreprise a créé depuis un partage, un dossier ou une application dont personne n’a pensé à l’ajouter.

Le deuxième est une durée deux à trois fois supérieure à ce que l’équipe annonçait. Ce n’est pas une négligence : l’estimation portait sur la copie des données, et le total inclut la recherche, la configuration, les vérifications et les hésitations.

Le troisième est une dépendance manquante, presque toujours une des trois de la section précédente. Le quatrième est plus embarrassant et tout aussi banal : une machine dont on découvre qu’elle n’était pas sauvegardée du tout, généralement parce qu’elle a été ajoutée après l’installation.

Aucun de ces quatre constats n’est un échec du test. Ce sont ses résultats, et un test qui n’en produit aucun a probablement été conduit par la personne qui avait tout configuré.

Ce que nous faisons est délimité. Nous préparons la liste et l’ordre de restauration, nous fournissons la machine de destination, nous tenons le chronomètre, nous rédigeons le procès-verbal d’une page, et nous revenons six mois plus tard vérifier que les décisions ont été appliquées.

Nous refusons de conduire seuls le test sur une infrastructure que nous avons nous-mêmes installée. C’est le conflit décrit à la section trois : nous connaissons les chemins et les mots de passe, donc nous réussirions un test que la panne réelle ferait échouer. Quelqu’un de chez vous tient le clavier, ou nous demandons un second prestataire.

Nous refusons aussi de signer un compte rendu portant la mention « restauration réussie » sans durée mesurée à côté. Sans le chiffre, la phrase est une impression, et elle sert précisément à ne pas regarder le seul résultat qui engage quelque chose.

Et il y a une chose à faire cette semaine sans nous, qui décide de la suite : demandez à la personne qui gère vos sauvegardes de restaurer un document précis dans l’état où il était il y a six semaines, sans préparation, et notez combien de temps cela prend. Si la réponse est « je vais voir », vous avez déjà appris ce que cet article avait à vous apprendre.