Planning des phases

Document généré automatiquement depuis /home/jerome/pub/docs/02-planning.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.

Établi le 9 septembre 2026. Les durées de transfert sont mesurées, pas estimées.

La machine

Kimsufi KS-3 — Atom N2800, 4 Go DDR3, 2 To SATA, RBX4 (rack 50C18, ID 229830). Reconduction automatique de mois en mois : pas d’échéance à surveiller.

Les 100 Mbit/s sont la spécification vendue de cette offre, pas une panne : aucun ticket à ouvrir (cf. 03-ticket-ovh-debit.md).

La contrainte qui structure tout : 100 Mbit/s

k3 est raccordé à 100 Mbit/s, contre 1 Gbit/s pour k4. Mesure réelle d’un transfert k4 → k3 : 10 Mo/s, soit 80 % du lien — un bon rendement pour du SSH. Le réseau est saturé, pas le CPU : aucun réglage de chiffrement n’y changera rien.

La carte supporte et annonce le gigabit, mais le port est bridé par l’offre. C’est un plafond définitif : le planning ci-dessous est calculé dessus.

Conséquence à assumer : en mode dégradé, k3 servira Nextcloud sur un lien 10 fois plus étroit. Pour le mail et Home Assistant c’est indolore ; pour le téléchargement de gros fichiers, ce sera lent mais utilisable.

Vue d’ensemble

sept.        S37          S38          S39          S40      S41       S42+
         09 ─── 15    16 ─── 22    23 ─── 29    30 ─── 06  07 ── 12  20 ───
         │            │            │            │          │        │
  P0 ────┤            │            │            │          │        │
  réinstall + 19h30   │            │            │          │        │
         │            │            │            │          │        │
         P1 ─ P2 ─────┤            │            │          │        │
         rôle, réplication         │            │          │        │
                      │            │            │          │        │
                      P3 ─ P4 ─────┤            │          │        │
                      dumps, prépa k3           │          │        │
                                   │            │          │        │
                                   P5 ─ P6 ─────┤          │        │
                                   noteback, bascule       │        │
                                                │          │        │
                                                P7 ────────┤        │
                                                aller-retour        │
                                                           ▲        │
                                                    13 oct : ACME   P8
                                                    NE RIEN FAIRE   upgrade k4

Détail

Phase 0 — Réinstallation de k3 · S37, 1 jour + 1 nuit

Le transfert de NCData est le point de non-retour du calendrier : 19 h 30 pendant lesquelles NCData n’existe qu’en un exemplaire, sur k4. Le lancer un soir, le vérifier le lendemain.

Les TTL sont à traiter en premier, et pas seulement pour gagner du temps. kimsufi4.chabod.eu est à 86 400 s (24 h), et abaisser un TTL ne prend effet qu’après expiration de l’ancien : tant qu’ils ne sont pas abaissés depuis plus de 24 h, aucune bascule — test compris — ne peut aboutir en moins d’une journée. Détail dans 04-dns-bascule.md.

Phase 1 — Mécanisme de rôle · S38, ~3 h

Rôle actif/veille, dockersync-guard.service, liste blanche. Test : redémarrer k3 et vérifier que rien ne monte tout seul. Rien ne doit être répliqué avant que cette phase soit finie — c’est elle qui empêche un k4 réparé d’écraser des données fraîches.

Phase 2 — Script de réplication · S38, ~5 h + observation

Le plus gros morceau de code. Premier passage en --dry-run, sortie relue ensemble avant d’armer --delete. Puis quelques jours d’observation : k3 doit cesser de croître, ce qui n’a jamais été le cas jusqu’ici.

Phase 3 — Dumps cohérents · S39, ~3 h

Réutilise la logique de /opt/backup/backup.bash, en ajoutant la cadence horaire pour mailcow. Vérification : restaurer le dump dans un conteneur jetable et compter les boîtes.

Phase 4 — Préparer k3 à la charge · S39, ~3 h

Profil mailcow dégradé, HELO postfix, docker compose pull périodique.

Phase 5 — noteback et documentation · S40, ~4 h

Instance WordPress dédiée sur k3, généralisation de publier-docs-note.sh et extension de son garde-fou anti-fuite.

Phase 6 — Scripts de bascule · S40, ~6 h

bascule.sh --planifie et --urgence, fusion du store ACME, checklist DNS.

Phase 7 — Tests · S41, 1 journée

Test à blanc sans toucher au DNS, puis aller-retour complet chronométré. C’est le seul test qui valide le cas d’usage dist-upgrade.

Prérequis : les TTL doivent avoir été abaissés depuis plus de 24 h.

À terminer avant le 10 octobre. Le 13 octobre tombe le premier renouvellement ACME automatique (cf. HERITAGE.md) : il doit se dérouler sur k4 en conditions normales, pas au milieu d’une bascule.

⚠️ 13 octobre 2026 — renouvellement ACME

Ne rien faire ce jour-là. Rejouer ~/claude/scripts/inspect-acme-store-2026-09-01.sh pour vérifier que les 19 certificats se sont renouvelés proprement.

Phase 8 — Dist-upgrade de k4 vers 26.04 · S42 ou après, 1 journée

L’aboutissement : basculer sur k3, migrer k4, revenir. À ne lancer qu’une fois l’ACME du 13 octobre digéré, et l’aller-retour de la phase 7 réussi.

Récapitulatif

Les six semaines sont une cadence confortable, pas un chemin critique : à part les 19 h 30 de transfert initial, rien n’est incompressible. L’ordre, en revanche, ne se négocie pas — la phase 1 avant toute réplication, et la phase 7 avant la 8.