icinga : deux temoins de sauvegarde, et non l un ou l autre

Au site, la verification que chaque noeud fait de son depot visait un service
que le gabarit ne creait que sans depot dans l ecosysteme : 404 toutes les 4 h
depuis le 20 septembre sur site-forge-01, site-mon-01 et site-pki-01. Les
deux temoins existent maintenant ; six services au vert, relus dans Icinga.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,26 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-28 (1) — La sauvegarde de la forge du génome passait ; sa vérification parlait dans le vide
+
+**Question de l'exploitant : la sauvegarde de `site-forge-01` passe-t-elle vraiment ?** Oui,
+et c'est maintenant mesuré jusqu'à la restauration : `setops-sauvegarde` réussit chaque nuit
+(dernier instantané 2026-09-28 02:43, 9 conservés, ~45 Mio), et `set-ops-public.git`
+restauré depuis `latest` passe `git fsck`, avec pour tête `859ac07` — exactement ce que la
+forge portait à 02:43, avant les poussées de la journée.
+
+**Ce que la mesure a trouvé en chemin.** La vérification que chaque nœud fait de SON dépôt
+(`setops-verification-depot`, celle qui détient la clé) échouait toutes les quatre heures
+depuis le 2026-09-20 sur `site-forge-01`, `site-mon-01` et `site-pki-01` : 48 fois
+« ECHEC du rapport Icinga : 404 No objects found ». Le nœud rapportait à
+`<nœud>!sauvegarde` ; `setops-sauvegardes.conf.j2` ne créait ce service que dans un
+écosystème SANS dépôt. Le site en a un (`site-backup-01`) : seuls existaient les services
+du témoin du dépôt, `site-backup-01!sauvegarde: <nœud>` — au vert, et donc crus complets.
+
+Le gabarit choisissait l'un OU l'autre témoin ; il crée désormais les deux quand un dépôt
+existe. Déployé sur `site-mon-01`, vérification relancée sur les trois nœuds : six
+services au vert, et les deux témoins disent la même chose (1723 fichiers, 40 Mo pour la
+forge). Chez les tenants, sans dépôt, rien ne change.
+
 ## 2026-09-27 (1) — Patient 0 effacé, l'index 29 libéré
 
 Ses machines n'existaient plus depuis le 2026-09-06 (D-83), mais son plan restait sur

roles/serveur_icinga/templates/setops-sauvegardes.conf.j2

@@ -29,10 +29,25 @@ object CheckCommand "setops-passif" {
   command = [ "/bin/true" ]
 }
 
+{#
+   DEUX TEMOINS, ET NON L'UN OU L'AUTRE (2026-09-28).
+
+   Ce fichier choisissait : s'il existait un depot dans l'ecosysteme, les services
+   s'attachaient au DEPOT ; sinon, aux NOEUDS. Or depuis que « la verification suit la
+   cle », `client_backup` installe sa verification sur CHAQUE noeud, depot ou pas. Au
+   site, qui a son depot (`site-backup-01`), le rapport des noeuds visait donc un service
+   que ce fichier n'avait pas cree : `site-forge-01`, `site-mon-01` et `site-pki-01`
+   ont recu un 404 toutes les quatre heures du 2026-09-20 au 2026-09-28, et leur
+   verification — la seule qui detienne la cle — n'est arrivee nulle part. Leur unite
+   echouait ; Icinga, lui, ne voyait que le temoignage du depot, et le croyait complet.
+
+   Les deux se completent : le depot dit ce qu'on peut affirmer SANS lire (des octets
+   arrivent, et quand) ; le noeud dit ce qu'on ne sait qu'AVEC la cle (l'instantane
+   s'ouvre, il n'est pas vide). Ils ont chacun leur service.
+#}
 {% if serveur_icinga_hote_sauvegarde %}
 {#
-   L'ECOSYSTEME A SON PROPRE DEPOT : c'est LUI qui rapporte, parce qu'il est le seul a
+   LE TEMOIN DU DEPOT : ce que l'hote des depots peut affirmer sans pouvoir lire.
-   voir ce qui est reellement arrive. Les services s'attachent donc a son hote.
 #}
 {% for noeud in serveur_icinga_sauvegarde_attendue | sort %}
 object Service "sauvegarde: {{ noeud }}" {
@@ -45,19 +60,17 @@ object Service "sauvegarde: {{ noeud }}" {
   vars.setops_source = "{{ noeud }}"
 }
 {% endfor %}
-{% else %}
+{% endif %}
 {#
-   AUCUN DEPOT DANS CET ECOSYSTEME — le cas normal depuis qu'ils deposent chez leur
+   LE TEMOIN DU NOEUD — toujours, qu'il y ait un depot dans l'ecosysteme ou non.
-   HEBERGEUR (2026-09-02).
 
-   Le site heberge des octets chiffres COTE CLIENT : il ne peut ni les lire, ni dire
+   Le depot heberge des octets chiffres COTE CLIENT : il ne peut ni les lire, ni dire
-   s'ils valent quelque chose. La verification revient donc au seul qui detient la cle,
+   s'ils valent quelque chose. Seul le NOEUD, qui detient la cle, le peut — et le
-   le NOEUD lui-meme — et le service s'attache a lui, ce qui est d'ailleurs plus juste :
+   service s'attache a lui, ce qui est d'ailleurs plus juste : la sauvegarde de `idm-01`
-   la sauvegarde de `idm-01` est un attribut de `idm-01`, pas d'une machine tierce.
+   est un attribut de `idm-01`, pas d'une machine tierce.
 
-   Le service n'est plus nomme « sauvegarde: <noeud> » mais simplement « sauvegarde » :
+   Le service est nomme simplement « sauvegarde » : le nom du noeud est porte par
-   le nom du noeud est desormais porte par l'hote. Repeter le nom dans le service
+   l'hote. Repeter le nom dans le service donnerait « idm-01 / sauvegarde: idm-01 ».
-   donnerait « idm-01 / sauvegarde: idm-01 ».
 #}
 {% for noeud in serveur_icinga_sauvegarde_attendue | sort %}
 object Service "sauvegarde" {
@@ -70,4 +83,3 @@ object Service "sauvegarde" {
   vars.setops_source = "{{ noeud }}"
 }
 {% endfor %}
-{% endif %}