Document généré automatiquement depuis /home/jerome/pub/docs/07-tester-sans-casser.md sur kimsufi3, le 11 September 2026 à 14:03. Toute modification faite ici sera écrasée à la prochaine régénération : éditer le fichier source.
La phase 7 est la plus risquée du projet. Elle ne se prend pas en bloc : quatre paliers, chacun franchi seulement quand le précédent est concluant.
Pourquoi la faire quand même
En une journée de mise en place, cinq défauts réels ont été trouvés, dont aucun ne se serait manifesté avant le jour de la vraie panne :
| Défaut | Ce qu’il aurait provoqué |
|---|---|
ufw limit sur le port SSH |
réplication bloquée en silence |
| k3 banni définitivement par fail2ban | « Connection refused » sur tous les ports |
2>/dev/null dans la commande distante |
« pair injoignable » indiscernable d’une panne |
| store ACME jamais déposé | 19 certificats à réémettre en pleine bascule |
| sonde disparue à la réinstallation | 3 h sans aucune surveillance, sans le savoir |
Un plan de secours non testé n’est pas un plan de secours.
Palier 7a — --preparer seul · risque quasi nul
Sans toucher au DNS ni à Home Assistant. Réversible par --annuler.
Ce palier répond aux questions qui comptent le plus, et il n’engage rien :
- mailcow démarre-t-il vraiment sur k3 ?
- tient-on dans 3,8 Go de RAM ? (
docker stats, cible : sous 3,3 Go) - les dumps se restaurent-ils, et les boîtes sont-elles là ?
- le store ACME fusionné porte-t-il bien les 19 noms ?
- combien de temps prend le démarrage sur l’Atom ?
C’est l’essentiel de la valeur du test pour une fraction du risque. À faire en premier, un jour ordinaire.
Palier 7b — test à blanc · risque nul
k3 sert déjà, mais le DNS pointe toujours vers k4. On force la résolution côté client :
for h in chabod.eu mail.chabod.eu cloud.chabod.eu note.chabod.eu ha.chabod.eu; do
curl -sS -o /dev/null -w "%{http_code} %{ssl_verify_result} $hn"
--resolve "$h:443:37.59.39.138" "https://$h/"
doneOn vérifie les codes attendus, certificats compris (ssl_verify_result à 0). Rappel de HERITAGE.md : chabod.eu répond 403 et note.chabod.eu 302 — ce sont les réponses normales, pas des pannes.
Puis on annule, et on n’a rien risqué du tout.
Palier 7c — bascule réelle courte · risque réel, maîtrisé
Seulement si 7a et 7b sont propres. Précautions, toutes nécessaires :
- un créneau calme : pas un vendredi soir, pas avant un déplacement ;
- la sauvegarde de la nuit vérifiée (
/opt/backup/backup.bashà 23 h) ; - Nextcloud en lecture seule pendant toute la bascule — c’est ce qui rend le retour trivial : sans écriture, aucun delta de 725 Go à rapatrier ;
- une durée courte et décidée d’avance : 30 minutes, pas « on verra ».
Le courrier est le point le plus tolérant : un serveur distant qui ne joint pas mail.chabod.eu réessaie pendant plusieurs jours. Un retard n’est pas une perte.
Palier 7d — le retour · le vrai moment délicat
C’est ici que deux jeux de données divergents coexistent.
Règle absolue : --dry-run du retour, relu, avant d’armer le --delete. Le sens de la réplication s’inverse, donc --delete traite désormais k3 comme la référence. Une erreur de chemin y détruit des données sur k4.
Ce qui a divergé pendant la bascule, et comment :
| Donnée | Divergence | Traitement |
|---|---|---|
| Courrier reçu sur k3 | additive (nouveaux maildirs) | le rsync retour les rapatrie |
| Base mailcow | modifiée | dump sur k3, restauré sur k4 |
| Nextcloud | aucune (lecture seule) | rien à faire |
| Historique HA | quelques heures d’écart | copie cohérente au retour |
L’ordre ne se négocie pas : --ceder sur k3, puis --dry-run relu, puis la réplication, puis --prendre sur k4.
Ce qui reste vrai quoi qu’il arrive
k3 n’est pas une sauvegarde. Si un palier tourne mal, le filet est /opt/backup/daily-backup-2.tar.encrypt — sauf pour NCData, qui n’y figure pas. C’est précisément pourquoi Nextcloud reste en lecture seule pendant toute l’opération : ce qui n’est pas écrit ne peut pas être perdu.
Leave a Reply