Cette publication est une réponse écrite suite à une discussion qu’on a eu durant une présentation chez Rencontres Linux au Québec une communauté de Linuxiens et autres fervent des logiciels libres dont je suis d’ailleurs un collaborateur bénévole. Le présentateur a mentionné qu’il était important d’avoir un « plan de relance », et ces mots ont fait resurgir une expérience de travail passé dans une PME. J’avais fait (en solo) un plan de relance après-sinistre (en anglais: « disaster recovery ») testé mensuellement avec une documentation améliorée à chaque test. Au final, j’avais une solution pare-balles et bien rôdé. Je résume donc ici mon expérience et ma tactique utilisé, ici axée PME.

On entend souvent la phrase: « pas de problème, on a des backups ».

C’est rassurant… jusqu’au jour où il faut vraiment s’en servir.

Un backup, tant qu’il n’a pas été restauré, c’est un peu comme un extincteur encore dans sa boîte: probablement utile, mais on ne le sait pas vraiment. Est-ce que le fichier est bon? Est-ce qu’on sait où il est? Est-ce qu’on a le mot de passe? Est-ce qu’on sait quoi restaurer en premier? Est-ce que quelqu’un peut le faire sous pression, un mardi matin, pendant que tout le monde attend que les systèmes reviennent?

C’est là que l’exercice de recouvrement devient important.

Je ne parle pas ici d’un plan théorique de 80 pages avec des termes corporatifs compliqués. Je parle d’un test très concret: prendre une machine à part, faire semblant que le serveur principal est mort, puis essayer de remonter les services importants avec ce qu’on a sous la main.

Le scénario que j’aime tester

Dans ma tête, le bon test ressemble à ceci:

On a eu un feu/inondation/météorite dans les bureaux: les serveurs sont physiquement endommagés. On doit restaurer l’infrastructure sur du nouvel équipement. Et Internet n’est pas disponible, les câbles de communications sortants ont été détruits également.

C’est volontairement pessimiste. Pas parce que je crois que tout va briser en même temps, mais parce qu’un bon plan devrait fonctionner dans le pire des scénarios.

Le pire moment pour découvrir qu’il manque un ISO, un mot de passe ou une étape dans la procédure, c’est pendant un vrai incident.

Le kit de recouvrement

La première chose que je préparerais, c’est un kit physique. Rien de magique: une boîte, une pochette, un tiroir identifié, peu importe. L’important, c’est que la personne responsable sache où il est et qu’il soit utilisable sans chasse au trésor.

Une ou deux clés USB

Je mettrais au minimum une clé USB, idéalement deux, avec tout ce qui est nécessaire pour repartir la base.

Par exemple:

  • l’ISO de Proxmox VE, si c’est l’hyperviseur utilisé;
  • l’ISO de Proxmox Backup Server, si ça fait partie de l’environnement;
  • les outils de restauration Veeam, si les backups sont faits avec Veeam;
  • des outils de transfert comme WinSCP ou FileZilla;
  • des outils réseau de base;
  • une copie PDF de la procédure de restauration;
  • les pilotes ou firmwares nécessaires, s’il y a du matériel capricieux.
  • une copie des mots de passe nécessaire pour compléter toute la chaîne d’opération, sous forme de fichier ouvrable par example avec le logiciel Keepass

Deux clés USB, c’est peut-être redondant, mais une clé USB qui ne boot pas, ça arrive. Et quand ça arrive pendant un incident, ça fait perdre du temps pour une raison franchement plate.

Un disque avec un backup récent

Ensuite, il faut un disque externe avec une copie récente des backups.

Ça peut être:

  • des backups natifs de Proxmox;
  • des backups Veeam;
  • des exports de configuration;
  • des dumps de bases de données;
  • des copies de dossiers importants.

Idéalement, ce disque fait partie d’une rotation hors site. La règle classique est le 3-2-1: trois copies, deux types de médias, une copie à l’extérieur.

Même si on a aussi du backup dans le cloud, je n’aimerais pas que ce soit le seul plan. Dans un vrai mauvais scénario, Internet peut être lent, non disponible, ou bloqué derrière un accès qu’on ne retrouve plus.

Un guide papier

Oui, papier.

Ça sonne vieux jeu, mais c’est justement le but. Si le poste de travail habituel n’est pas disponible, si le réseau est à terre, si le PDF n’ouvre pas ou si tout le monde est déjà occupé à éteindre des feux, le papier reste lisible.

Le guide n’a pas besoin d’être beau. Il doit être clair.

Je voudrais y retrouver:

  • la liste des serveurs ou machines virtuelles importantes;
  • l’ordre dans lequel les restaurer;
  • les adresses IP importantes;
  • les VLAN, bridges ou informations réseau nécessaires;
  • l’endroit où sont les backups;
  • les grandes étapes pour réinstaller l’hyperviseur;
  • les commandes importantes;
  • une checklist pour confirmer que les services fonctionnent.

Le point important: le guide doit être écrit pour quelqu’un de stressé. Une phrase qui semble claire aujourd’hui peut devenir beaucoup moins claire quand la production est arrêtée.

Les mots de passe: attention au faux sentiment de sécurité

Je ne mettrais pas les mots de passe en clair dans le guide papier. Par contre, le guide doit expliquer comment les retrouver. Une solution “portable” à ce problème serait d’utiliser le logiciel Keepass et une base de donnée Keepass “locale” qui fait parti du kit de restauration. Également, il serait sage d’inclure le fichier d’installation du logiciel Keepass.

Le vrai test: restaurer ailleurs qu’en production

Le coeur de l’exercice, ce n’est pas de dire « oui oui, les backups roulent ». C’est de restaurer pour vrai.

Je prendrais une machine à part, hors réseau de production, et je suivrais le guide papier comme si je ne connaissais rien par coeur.

Les règles du jeu:

  1. utiliser le kit physique;
  2. suivre la documentation, pas sa mémoire;
  3. éviter de chercher sur Internet, sauf si c’est vraiment nécessaire;
  4. noter chaque endroit où le guide n’est pas clair;
  5. corriger le guide après le test;
  6. mesurer le temps que ça prend;
  7. vérifier que les services restaurés fonctionnent réellement.

Ce dernier point est important. Une machine virtuelle qui démarre, ce n’est pas automatiquement un service restauré.

Exemple simple avec Proxmox

Prenons un exemple avec Proxmox VE, parce que c’est un scénario assez courant en homelab ou en petite infrastructure.

1. Installer Proxmox sur une machine de test

On démarre sur la clé USB, on installe Proxmox, on configure l’adresse IP de gestion, puis on valide qu’on peut accéder à l’interface web.

Rien de spectaculaire. Mais déjà ici, on peut découvrir des détails importants:

  • l’ISO est-elle encore bonne?
  • la clé USB boot-elle correctement?
  • le matériel voit-il le disque?
  • la carte réseau est-elle reconnue?
  • la procédure donne-t-elle les bonnes informations?

2. Recréer le minimum réseau et stockage

Avant de restaurer les VM, il faut que Proxmox ait accès au bon stockage et au bon réseau.

Selon le cas, ça peut vouloir dire:

  • recréer un bridge réseau;
  • connecter un disque USB de backup;
  • monter un partage réseau;
  • connecter un dépôt Proxmox Backup Server;
  • ajuster les IP pour éviter de nuire à la production.

Ce sont souvent ces petits détails qui font perdre du temps. Pas parce qu’ils sont compliqués, mais parce qu’ils sont faciles à oublier.

3. Restaurer dans le bon ordre

Toutes les machines ne sont pas égales. Certaines dépendent d’autres services.

Dans un environnement typique, on pourrait restaurer dans un ordre comme:

  1. le routeur ou pare-feu virtuel, si nécessaire;
  2. DNS / DHCP / annuaire, si l’environnement en dépend;
  3. serveur de fichiers;
  4. bases de données;
  5. applications importantes;
  6. services moins critiques.

Dans un homelab, l’ordre sera peut-être plus simple. Dans une PME, ça peut faire toute la différence.

4. Vérifier le service, pas juste la VM

Après la restauration, je voudrais valider des choses concrètes:

  • est-ce que l’application ouvre?
  • est-ce que les utilisateurs peuvent se connecter?
  • est-ce que les données attendues sont là?
  • est-ce que les partages réseau répondent?
  • est-ce que les logs montrent des erreurs graves?
  • est-ce que les services démarrent après un reboot?

Si on ne vérifie que le démarrage de la VM, on peut manquer le vrai problème.

À quelle fréquence faire ça?

Idéalement, souvent. Mensuellement serait excellent pour un environnement important.

Dans la vraie vie, je sais que ce n’est pas toujours réaliste. Mais même un test trimestriel ou semestriel est infiniment mieux que jamais.

L’important, c’est que ce soit récurrent. Une procédure testée une fois en 2021 n’est pas une procédure actuelle.

Les systèmes changent. Les versions changent. Les mots de passe changent. Les gens changent de poste. Les disques meurent. Les vieux raccourcis mentaux ne suivent pas toujours.

RPO et RTO, en langage simple

Il y a deux termes qu’on voit souvent en recouvrement:

RPO: combien de données peut-on perdre?
RTO: combien de temps avant que ça revienne?

Dit autrement:

  • si le dernier backup valide date d’hier soir, on peut perdre une journée de travail;
  • si la restauration prend quatre heures, l’entreprise doit vivre avec quatre heures d’arrêt.

Ce n’est pas juste une discussion technique. C’est une discussion d’affaires.

Si une entreprise ne peut pas perdre plus qu’une heure de données, les backups une fois par jour ne suffisent pas. Si elle ne peut pas être arrêtée plus que 30 minutes, une restauration manuelle de plusieurs heures ne suffit pas non plus.

Le test de restauration permet d’avoir des chiffres au lieu d’avoir des suppositions.

Ce que je noterais après chaque exercice

Après le test, je garderais un petit journal:

  • date du test;
  • version des outils utilisés;
  • backup restauré;
  • temps requis;
  • problèmes rencontrés;
  • étapes à clarifier;
  • actions à faire avant le prochain test.

Pas besoin d’un roman. Quelques lignes peuvent suffire. Mais après quelques tests, ce journal devient très utile: on voit ce qui revient souvent, ce qui s’améliore, et ce qui reste fragile.

Le but n’est pas d’avoir l’air parfait

Un bon exercice de recouvrement va presque toujours révéler des trous.

C’est normal.

On va trouver une commande manquante, un mot de passe mal documenté, un ISO trop vieux, une étape ambiguë, un backup plus lent que prévu, une dépendance oubliée.

Tant mieux. C’est exactement le but.

Je préfère découvrir ça pendant un test tranquille que pendant une panne où le téléphone sonne, où les courriels rentrent, et où tout le monde veut savoir « ça revient quand? ».

Conclusion

Pour moi, un bon plan de recouvrement doit être assez simple pour être suivi par une personne compétente, mais stressée.

Il faut:

  • un kit physique;
  • des backups récents;
  • une copie hors site;
  • une procédure papier;
  • une façon claire de récupérer les accès;
  • un test régulier sur une machine hors production;
  • une checklist pour valider que les services fonctionnent vraiment.

Ce n’est pas glamour. Ce n’est pas la nouvelle technologie à la mode. Mais quand un serveur tombe, c’est ce genre de préparation qui fait la différence entre « on pense être corrects » et « on sait quoi faire ».