Tester une restauration : une tâche au vert n’est pas une preuve

Les tâches de sauvegarde tournent toutes les nuits et sont toutes au vert. Cela prouve que le fichier a été écrit. Cela ne prouve pas qu’il peut être lu, ni que la machine à l’intérieur démarre, et encore moins que le service sur cette machine tourne. L’écart entre les deux apparaît le jour où vous en avez vraiment besoin.

Trois niveaux de test

Premier : est-elle lisible. Une vérification que la sauvegarde est intacte. C’est bon marché, automatisable, et cela attrape au moins la corruption silencieuse. À soi seul, cela ne dit toujours pas « la machine démarre ».

Deuxième : démarre-t-elle. Restaurez la sauvegarde sous une nouvelle identité sur une cible de test, démarrez-la réseau débranché, et regardez l’écran de connexion. La plupart des gens n’atteignent jamais ce niveau, alors qu’il coûte une pause café et que ce qu’il apprend est considérable.

Troisième : fait-elle son travail. L’application démarre-t-elle, les données sont-elles là, la dernière heure manque-t-elle. Sur les machines critiques, c’est la vraie question, car une machine qui démarre mais démarre vide ne sauve personne.

La règle pour tester sans rien casser

Restaurez toujours sous une nouvelle identité, jamais par-dessus la machine en marche. Et faites le test réseau débranché : deux machines portant la même identité et la même adresse se battent sur le même réseau, et le prix n’est pas payé par votre copie de test mais par l’original en service.

Ce que les gens trouvent quand ils testent enfin

Ce que trouvent ceux qui testent pour la première fois se ressemble étonnamment d’une installation à l’autre. La sauvegarde a trois semaines parce que la tâche s’est arrêtée en silence et que personne n’a regardé. La machine démarre mais l’application réclame une clé qui vivait ailleurs. La restauration demande plus de place que la cible n’en a. Rien de tout cela n’est visible pendant la sauvegarde ; tout est visible pendant la restauration.

Surprises au moment de restaurer

Conflit d’identité : ce numéro est déjà utilisé. Nom de stockage : la sauvegarde renvoie à un nom de stockage qui n’existe plus sur cette machine. Nom de pont : la définition réseau dans la sauvegarde désigne un pont que ce serveur n’a pas, donc la machine démarre sans réseau.

Rien de tout cela n’est une panne, ce sont des effets du déplacement. Mais rencontrés pour la première fois le jour d’un vrai sinistre, ils ne se distinguent pas d’une panne.

Fréquence et calendrier

Un test de restauration fait une fois par trimestre vaut plus qu’une politique de sauvegarde impeccable jamais éprouvée. Attachez le test à une date ; les tests remis à « quand j’aurai le temps » n’ont pas lieu. Notez ce que vous avez trouvé, car si le test suivant trouve la même chose, le problème n’est pas la sauvegarde mais le processus.

Le point, c’est la répétition

Le jour d’une vraie perte, vous n’aurez pas le temps d’apprendre tout cela. La seule chose à faire ce jour-là est de refaire un travail déjà fait. Le test est la répétition de ce jour, et c’est exactement ce que vaut une répétition.

Ce que fait Atlas

Atlas montre quelles sauvegardes existent, où elles se trouvent et quand elles ont été prises, si bien que la question « ai-je une sauvegarde et de quand date-t-elle » se répond en regardant plutôt qu’en devinant. C’est la première étape du test ci-dessus : s’assurer qu’il y a quelque chose à tester. La restauration elle-même se fait depuis les écrans du côté Proxmox ; Atlas ne s’interpose pas, il rend visible ce que vous avez en main.