Chapitre 35. Procédures de restauration et de récupération

Objectifs pédagogiques

Exécuter le remplacement d'un nœud perdu. Décider si une perte de quorum se répare ou se force, et conduire la récupération avec ses conditions et ses risques. Restaurer un snapshot sur le cluster d'origine sans détruire ce qu'on voulait sauver. Reconstruire un cluster neuf en réunissant d'abord le matériel de scellement. Employer l'option de forçage en sachant ce qu'elle autorise. Dérouler la liste de contrôle d'après restauration. Consigner l'exercice avec ses durées.

Prérequis

Chapitres 33 et 34 (la matière et la décision), chapitre 25 (l'entrée et la sortie d'un nœud), chapitre 23 (vault-transit-01, sans lequel aucune procédure n'aboutit), chapitre 19 (les credentials dynamiques, dont la restauration désaccorde le monde).

Cours

35.1 Remplacer un nœud perdu

La procédure la plus fréquente est aussi la moins spectaculaire, et le chapitre 25 l'a déjà déroulée : retirer le pair, reconstruire la machine avec un répertoire vide, rejoindre, attendre la stabilisation, détruire l'ancien disque en conscience.

Deux points méritent d'être répétés, parce que la reprise les rend critiques. Le nœud reconstruit reçoit un token de seal propre, l'ancien étant révoqué avec la machine perdue. Et l'ordre reste retirer puis éteindre : sur un cluster déjà diminué, un fantôme au compte des voix fausse l'arithmétique au moment où elle décide de tout.

Aucun snapshot n'intervient : le nouveau nœud reçoit l'état par réplication. C'est le sens même du chapitre 24, où chaque nœud détient tout, donc un survivant suffit à reconstruire les autres.

35.2 Le quorum perdu : réparer ou forcer

Quand la majorité des nœuds disparaît, le cluster cesse d'écrire. Deux voies existent, et le choix se fait sur une seule question : les machines perdues reviendront-elles ?

Si elles sont récupérables, hyperviseur à redémarrer, réseau coupé, disque système remplaçable sans perdre les données, la bonne décision est d'attendre et de réparer. Le quorum revient de lui-même, sans perte, et la patience coûte moins qu'une manœuvre irréversible.

Si elles sont définitivement perdues, la récupération consiste à dire au survivant qu'il constitue désormais le cluster à lui seul. La manœuvre s'écrit dans un fichier peers.json déposé dans le répertoire de données et lu au démarrage.

[Production]. Manœuvre de dernier recours : perte de données possible, jamais sur un cluster qui a encore un leader

sudo systemctl stop vault                       # 1. arreter le survivant
sudo -u vault tee /opt/vault/data/raft/peers.json >/dev/null <<'JSON'
[
  {
    "id": "vault-core-03",
    "address": "10.10.20.13:8201",
    "non_voter": false
  }
]
JSON
sudo systemctl start vault                      # 2. il redemarre seul maitre de son journal
vault status && vault operator raft list-peers  # 3. verifier : un seul pair, votant

Quatre conditions encadrent cette manœuvre, et aucune n'est facultative.

Le cluster ne doit plus avoir de leader : forcer une configuration pendant qu'un leader vit, c'est fabriquer deux histoires, exactement l'accident que Raft existe pour empêcher. Les nœuds listés doivent être arrêtés pendant l'écriture du fichier. Les machines écartées ne doivent jamais revenir dans cet état, leur retour avec leur ancien journal produisant la divergence : on les reconstruit à vide ou on ne les rallume pas. Enfin, on accepte la perte des écritures non répliquées : ce que l'ancien leader avait engagé sans que le survivant l'ait reçu disparaît, et personne ne peut dire précisément quoi.

Une sauvegarde du répertoire de données prise avant la manœuvre est donc obligatoire, ne serait-ce que pour pouvoir revenir en arrière si le résultat déçoit. Une fois le cluster reconstitué, on le ramène à trois voix par la procédure ordinaire du chapitre 25 : deux machines neuves, retry_join, stabilisation.

35.3 Restaurer sur le cluster d'origine

Ce cas correspond à une erreur logique plutôt qu'à une panne : un montage désactivé par mégarde, une purge malheureuse, une migration ratée. Le cluster fonctionne, on veut revenir à l'état d'avant.

[Production]. Écrasement total de l'état courant

vault operator raft snapshot restore /chemin/astrea-20261209T2100Z.snap

La commande remplace l'intégralité de l'état par celui du fichier. Tout ce qui a été écrit depuis la prise disparaît, tokens et baux compris : les applications devront se réauthentifier, et le désaccord décrit au chapitre 34 s'installe.

Trois précautions transforment cette commande en procédure. Prendre un snapshot de l'état courant avant de l'écraser, parce qu'on ne sait jamais à l'avance si l'on préférera finalement l'état présent. Annoncer la coupure, puisqu'elle en est une du point de vue des clients. Et vérifier ce que l'on restaure, fichier attendu, empreinte, horodatage : restaurer le mauvais snapshot est une manière rapide de transformer un incident en sinistre.

35.4 Reconstruire un cluster neuf

C'est la procédure des scénarios de cluster ou de site perdus, celle que le TP 15 fait exécuter. Elle a un ordre, et l'ordre est la moitié du travail.

Réunir d'abord le matériel. Le gardien avant tout, rétabli ou reconstruit à partir de sa propre sauvegarde, avec sa clé d'enveloppe intacte et son quorum disponible. Puis la clé de sauvegarde hors ligne, sortie du coffre selon la procédure à deux personnes. Puis le fichier lui-même, déchiffré et vérifié par son empreinte. Rien ne commence avant que ces trois éléments ne soient réunis, et le chronomètre du chapitre 34 compte cette phase.

Monter un cluster vide. Installation du chapitre 7 sur les machines neuves, configuration du chapitre 24 avec la strophe de seal pointant sur le même gardien et un token neuf, puis initialisation. Cette initialisation surprend toujours : on initialise un cluster dont on va écraser l'état. Elle est nécessaire pour obtenir un serveur descellé capable de recevoir la restauration, et les clés qu'elle produit seront rendues caduques par le contenu du snapshot, qui apporte son propre keyring et ses propres recovery keys.

Restaurer.

[Production]

vault operator raft snapshot restore -force /chemin/astrea-20261209T2100Z.snap

L'option -force sert ici parce que la configuration de seal du cluster neuf ne correspond pas à celle enregistrée dans le snapshot. Il faut dire précisément ce qu'elle fait et ne fait pas : elle contourne des contrôles de cohérence, elle ne contourne aucune protection cryptographique. Si le gardien n'est pas le bon, ou si le matériel de scellement de l'époque manque, la restauration aboutit à un serveur qui ne descellera pas. L'échec arrive plus tard, et il est définitif. C'est la démonstration pratique de la section 33.1, et la raison pour laquelle la première étape est le matériel, pas le fichier.

Ramener le cluster à trois voix, jonction des deux autres nœuds, stabilisation, puis remettre l'entrée en service : répartiteur, sondes, DNS. Enfin, la liste de contrôle de la section suivante.

35.5 Après la restauration : réaccorder le monde

Une restauration réussie laisse deux univers en désaccord. La liste se déroule dans l'ordre, et le chapitre 33 a montré comment on la découvre : en restaurant pour de vrai.

Côté Vault. Vérifier le type de seal et l'état descellé. L'annuaire à trois votants. Les montages attendus avec leurs configurations. Les policies, comparées au dépôt versionné. Les méthodes d'authentification et leurs rôles. Les dispositifs d'audit, qui figurent bien dans le snapshot mais dont les destinations doivent être joignables : un audit qui ne peut pas écrire arrête le serveur, ce qui, sur une machine neuve, se découvre au pire moment. Enfin les baux et leur volume, qui donnent la mesure du désaccord.

Côté cibles. Les comptes dynamiques créés après la prise existent toujours sur les bases et les clouds, sans bail correspondant : ce sont des accès non gouvernés, à inventorier et à supprimer. Les credentials émis avant la prise et révoqués depuis peuvent être ressuscités par la restauration, et leur validité côté cible se vérifie. Les rotations effectuées après la prise sont annulées côté Vault mais restent appliquées côté cible : c'est le cas le plus douloureux, car la rotation d'un compte racine de moteur est irréversible pour l'opérateur et le compte de secours hors Vault redevient la seule porte.

Côté clients. Les tokens ont disparu et les applications se réauthentifient, ce que les intégrations correctes font seules. Les certificats émis après la prise ne figurent plus dans le stockage de la PKI : ils restent valides chez leurs porteurs mais ne seront ni révocables ni inventoriés, écart à consigner et à résorber par réémission.

La reprise s'achève quand cette liste est close, pas quand le serveur affiche qu'il est descellé.

35.6 Consigner

Chaque exécution, réelle ou d'exercice, produit trois traces.

Le chronomètre, découpé par phase : réunion du matériel, montage, restauration, vérifications, remise en service. C'est lui qui alimente le RTO du chapitre 34, et la phase la plus lente n'est presque jamais celle qu'on croit.

Le journal de décision, tenu en direct comme en incident.

Et la liste des écarts : ce qui a manqué, ce qui n'était pas écrit, ce qui a surpris. Une procédure qui sort d'un exercice sans une seule correction n'a probablement pas été jouée sincèrement.

Exemple : la reconstruction jouée en conditions réelles

L'équipe rejoue le scénario du cluster perdu sur du matériel jetable, mais avec les vrais coffres et les vraies procédures, la production restant intacte.

Premier écart, dès le départ. La procédure d'accès au coffre exige deux personnes, et le second détenteur est en réunion client. Vingt-deux minutes perdues. Le plan est corrigé le jour même pour désigner un suppléant, ce qui est exactement le genre de trouvaille qu'un exercice doit produire.

La reconstruction. Matériel réuni au bout de quarante et une minutes ; le déchiffrement et le contrôle d'empreinte en prennent six. Montage du cluster jetable, configuration de seal pointant sur le gardien, initialisation ; l'ingénieur le plus junior demande pourquoi l'on initialise ce qu'on va écraser, la question est bonne et la réponse figure désormais en commentaire dans la procédure. Restauration avec forçage, quatre minutes pour 412 mégaoctets. Descellement automatique par le gardien : la preuve, cette fois expérimentale, que la section 33.1 disait vrai.

Les vérifications occupent la seconde moitié de la matinée et livrent trois enseignements. Le dispositif d'audit du snapshot pointait vers monitor-01, joignable, donc sans incident ; l'équipe note qu'un cluster reconstruit dans un sinistre réel n'aurait peut-être pas ce collecteur, et ajoute une étape conditionnelle. La comparaison des policies avec le dépôt a trouvé un écart, une policy de test créée trois semaines plus tôt et jamais versionnée, défaut de discipline découvert par une procédure de reprise. Et l'inventaire côté base a listé onze comptes dynamiques sans bail correspondant, purgés selon la méthode du chapitre 19.

Le bilan. Deux heures quarante-sept, dont vingt-deux minutes d'attente évitables. Le RTO de deux heures est confirmé sous réserve de la correction du plan. La ligne de registre conclut : « Le matériel a mis quarante et une minutes à arriver, la machine quatre. C'est le coffre qu'il faut optimiser, pas le serveur. »

Sécurité : la procédure comme surface

Le fichier de reconfiguration de pairs est un pouvoir de réécriture de l'histoire. L'accès aux répertoires de données et la connaissance de la manœuvre suffisent à fabriquer un cluster complaisant. Il ne s'écrit que sous procédure, avec traçabilité, et jamais comme dépannage rapide.

Une restauration efface les traces autant que les erreurs. L'état revient en arrière, y compris les preuves d'une compromission éventuelle. Avant toute restauration consécutive à un incident, on préserve : snapshot de l'état courant, copies des journaux, horodatages.

Le cluster de reprise naît sans défenses. Pare-feu à appliquer, audit à confirmer, certificats provisoires, comptes d'amorçage encore actifs. La procédure remet les contrôles dans l'ordre et l'exercice vérifie qu'aucun n'a été laissé de côté le temps de finir.

Les orphelins d'après restauration sont des accès non gouvernés. Des comptes vivants sur les cibles que Vault ignore : ni révocables, ni traçables, ni expirants. Leur purge fait partie de la reprise, pas du ménage ultérieur.

Erreurs fréquentes

Forcer un quorum qui pouvait revenir. La manœuvre irréversible jouée par impatience alors que l'hyperviseur redémarrait. La première question porte sur la récupérabilité des machines (section 35.2).

Rallumer un ancien nœud après un peers.json. Son journal contredit celui du survivant, et la divergence s'installe (section 35.2).

Restaurer sans snapshot préalable de l'état courant. L'aller sans retour : si le fichier restauré s'avère plus mauvais que l'état écrasé, il n'y a plus rien à faire (section 35.3).

Commencer par le fichier plutôt que par le matériel de scellement. On monte, on restaure, et l'on découvre au descellement que le gardien manque (section 35.4).

Croire que -force ouvre un snapshot orphelin. Il contourne des contrôles de cohérence, jamais la cryptographie (section 35.4).

Déclarer la reprise finie au premier descellement. Le serveur répond, mais les baux, les comptes cibles, les policies et les certificats sont en désaccord avec le monde (section 35.5).

Exercer sans chronomètre ni journal. L'exercice rassure et n'apprend rien : ni la phase lente, ni l'écart de procédure, ni le suppléant manquant (section 35.6).

Mise en pratique : décider et exécuter

Sur papier ; réponses commentées en fin de partie.

1. Deux nœuds sur trois sont injoignables depuis vingt minutes ; l'hyperviseur qui les portait redémarre, sans garantie de délai. Les nouvelles instances applicatives commencent à échouer. Rédigez votre arbre de décision, avec les informations que vous cherchez d'abord et le moment où vous basculeriez vers la reconfiguration forcée.
2. Écrivez la procédure complète de reconstruction sur site de secours, en numérotant les étapes et en indiquant pour chacune le rôle qui l'exécute, sa durée attendue et son critère de sortie.
3. Rédigez la liste de contrôle d'après restauration sous forme de tableau à trois colonnes, en précisant pour chaque ligne la commande ou la requête qui la vérifie.

Questions de compréhension

1. Pourquoi le remplacement d'un nœud ne mobilise-t-il aucun snapshot ?
2. Quelle question décide entre réparer et forcer un quorum perdu, et pourquoi la patience est-elle souvent le bon choix ?
3. Énoncez les quatre conditions de la récupération par peers.json et ce qu'on accepte de perdre.
4. Quelles trois précautions transforment la restauration en procédure sur un cluster d'origine ?
5. Détaillez l'ordre de la reconstruction et expliquez pourquoi l'on initialise un cluster dont l'état sera écrasé.
6. Que fait -force, que ne fait-il pas, et à quel moment l'erreur se manifeste-t-elle ?
7. Citez, pour chacun des trois côtés, deux vérifications de la liste d'après restauration.
8. Pourquoi le cas des rotations effectuées après la prise est-il le plus douloureux ?
9. Quelles trois traces produit chaque exécution, et à quoi sert chacune ?

Synthèse

Quatre procédures couvrent les pertes réelles. Le remplacement d'un nœud n'utilise aucun snapshot, puisqu'un survivant suffit à reconstruire les autres. La perte de quorum se traite par la patience quand les machines reviennent, et par peers.json quand elles ne reviennent plus, sous quatre conditions strictes et avec l'acceptation d'une perte non chiffrable. La restauration sur le cluster d'origine répare une erreur logique en écrasant tout, ce qui exige un snapshot de l'état courant avant de commencer. La reconstruction d'un cluster neuf suit un ordre où le matériel de scellement précède le fichier, et où -force ne dispense de rien. Aucune de ces procédures ne s'achève au premier descellement : la reprise se termine quand le monde et Vault sont réaccordés. Déclenche le TP 15 (énoncé en partie XV).