[92] La copie hors serveur emporte le stockage objet

lenaic commented

2026-09-04 08:23:14 +00:00

Owner

Contribue au #92, dont le critère 1 était coché mais faux en pratique.

Le trou

MinIO n'est sauvegardé nulle part. Ni la tâche PostgreSQL de 2 h 30 ni celle
de la forge de 12 h 30 ne le touchent, et l'archive rapatriée sur le poste ne
couvrait que /opt/g2-forge/backups et /var/backups/postgresql.

Toute la zone médaillon, 79 Mo et 9851 objets ce matin, tient sur un seul
disque sans copie. Et ce n'est pas rattrapable : l'API bouchon ne rend pas
d'historique au delà de sa fenêtre. Le runbook le disait déjà, « le relevé
instantané de 14h32 n'existe qu'une fois, la source ne le redonnera pas ».

stockage-minio.md proposait bien un mc mirror, mais vers
/srv/enervision/sauvegardes, c'est-à-dire le même disque que MinIO. Ça
protège d'une fausse manoeuvre, pas de la perte de la machine, et c'était
manuel.

Ce que fait la correction

L'archive emporte /srv/enervision/minio. MinIO tourne sur un seul disque, donc
la copie du répertoire de données se restaure telle quelle, .minio.sys
compris, qui porte la configuration des seaux.

La vérification compte les objets par seau plutôt que de constater la
présence d'un répertoire, qui ne prouverait que la présence d'un répertoire.
Seul bronze est exigé non vide : silver et gold peuvent l'être
légitimement tant que la transformation n'a pas tourné, et faire échouer la
copie pour ça apprendrait à ignorer ses échecs.

ARCHIVE=<chemin> vérifie une archive déjà là, sans rien retélécharger ni
purger. C'est le geste à faire avant de se fier à une copie ancienne.

Éprouvé contre le vrai serveur, dans les trois cas

archive du jour          objet bronze : 9851 ... == copie vérifiée ==     code 0
bronze vidé à la main    ÉCHEC : zone bronze vide dans la copie           code 1
archive du 3 septembre   ÉCHEC : le stockage objet est absent             code 1

Le troisième cas est réel, pas fabriqué : c'est une des copies déjà sur le
poste, d'avant ce changement. Le mode ARCHIVE est ce qui a permis de fabriquer
le second sans toucher à la production.

L'archive passe de 49 à 52 Mo, le JSON de bronze se comprimant bien.

L'horaire, qui est l'autre moitié du problème

La copie est planifiée 30 18 * * 1-5 et n'a jamais tourné. Aucun
journal.log n'a jamais été écrit dans ~/eadl/sauvegardes/, alors que le
miroir planifié à midi, lui, tourne : ce n'est donc pas cron, c'est que le poste
est éteint à 18 h 30. Les trois copies existantes sont toutes manuelles.

L'en-tête du script et forge.md documentent maintenant 12 h 15, avec la
raison. La ligne de crontab du poste reste à changer à la main, elle n'est
versionnée nulle part, ce qui est le #64.

Ce que ça ne résout toujours pas

Les deux machines sont dans la même salle et tombent ensemble. C'est un filet,
pas une sauvegarde hors site. La vraie réponse reste le stockage de secours du
#69.

Contribue au #92, dont le critère 1 était coché mais faux en pratique. ## Le trou **MinIO n'est sauvegardé nulle part.** Ni la tâche PostgreSQL de 2 h 30 ni celle de la forge de 12 h 30 ne le touchent, et l'archive rapatriée sur le poste ne couvrait que `/opt/g2-forge/backups` et `/var/backups/postgresql`. Toute la zone médaillon, **79 Mo et 9851 objets ce matin**, tient sur un seul disque sans copie. Et ce n'est pas rattrapable : l'API bouchon ne rend pas d'historique au delà de sa fenêtre. Le runbook le disait déjà, « le relevé instantané de 14h32 n'existe qu'une fois, la source ne le redonnera pas ». `stockage-minio.md` proposait bien un `mc mirror`, mais vers `/srv/enervision/sauvegardes`, **c'est-à-dire le même disque que MinIO**. Ça protège d'une fausse manoeuvre, pas de la perte de la machine, et c'était manuel. ## Ce que fait la correction L'archive emporte `/srv/enervision/minio`. MinIO tourne sur un seul disque, donc la copie du répertoire de données se restaure telle quelle, `.minio.sys` compris, qui porte la configuration des seaux. La vérification **compte les objets par seau** plutôt que de constater la présence d'un répertoire, qui ne prouverait que la présence d'un répertoire. Seul `bronze` est exigé non vide : `silver` et `gold` peuvent l'être légitimement tant que la transformation n'a pas tourné, et faire échouer la copie pour ça apprendrait à ignorer ses échecs. `ARCHIVE=<chemin>` vérifie une archive déjà là, sans rien retélécharger ni purger. C'est le geste à faire avant de se fier à une copie ancienne. ## Éprouvé contre le vrai serveur, dans les trois cas ``` archive du jour objet bronze : 9851 ... == copie vérifiée == code 0 bronze vidé à la main ÉCHEC : zone bronze vide dans la copie code 1 archive du 3 septembre ÉCHEC : le stockage objet est absent code 1 ``` Le troisième cas est réel, pas fabriqué : c'est une des copies déjà sur le poste, d'avant ce changement. Le mode `ARCHIVE` est ce qui a permis de fabriquer le second sans toucher à la production. L'archive passe de 49 à 52 Mo, le JSON de bronze se comprimant bien. ## L'horaire, qui est l'autre moitié du problème La copie est planifiée `30 18 * * 1-5` et **n'a jamais tourné**. Aucun `journal.log` n'a jamais été écrit dans `~/eadl/sauvegardes/`, alors que le miroir planifié à midi, lui, tourne : ce n'est donc pas cron, c'est que le poste est éteint à 18 h 30. Les trois copies existantes sont toutes manuelles. L'en-tête du script et `forge.md` documentent maintenant 12 h 15, avec la raison. **La ligne de crontab du poste reste à changer à la main**, elle n'est versionnée nulle part, ce qui est le #64. ## Ce que ça ne résout toujours pas Les deux machines sont dans la même salle et tombent ensemble. C'est un filet, pas une sauvegarde hors site. La vraie réponse reste le stockage de secours du #69.

lenaic added the

labels

2026-09-04 08:23:14 +00:00

lenaic self-assigned this

2026-09-04 08:23:14 +00:00

lenaic added 1 commit

2026-09-04 08:23:15 +00:00

infra: la copie hors serveur emporte le stockage objet

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 31s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 4s

Details

Intégration / Aucun secret commité (pull_request) Successful in 2s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 2m7s

Details

891cb3f68a

MinIO n'était sauvegardé nulle part. Ni la tâche PostgreSQL de 2 h 30 ni celle
de la forge de 12 h 30 ne le touchent, et l'archive rapatriée sur le poste ne
couvrait que /opt/g2-forge/backups et /var/backups/postgresql. Toute la zone
médaillon, 79 Mo et 9851 objets ce matin, tenait sur un seul disque sans copie.

Ce n'est pas rattrapable après coup : l'API bouchon ne rend pas d'historique au
delà de sa fenêtre, donc une zone bronze perdue est perdue. Le runbook le disait
déjà, « le relevé instantané de 14h32 n'existe qu'une fois ».

Le runbook proposait bien un `mc mirror`, mais vers /srv/enervision/sauvegardes,
c'est-à-dire le même disque que MinIO. Ça protège d'une fausse manoeuvre, pas de
la perte de la machine, et c'était manuel.

MinIO tourne sur un seul disque : la copie du répertoire de données se restaure
telle quelle, `.minio.sys` compris, qui porte la configuration des seaux.

La vérification compte les objets par seau plutôt que de constater la présence
d'un répertoire, qui ne prouverait que la présence d'un répertoire. Seul bronze
est exigé non vide : silver et gold peuvent l'être légitimement tant que la
transformation n'a pas tourné, et faire échouer la copie pour ça apprendrait à
ignorer ses échecs.

`ARCHIVE=<chemin>` vérifie une archive déjà là sans rien retélécharger ni
purger. C'est le geste à faire avant de se fier à une copie ancienne, et c'est
ce qui rend ces contrôles éprouvables.

Éprouvé dans les trois cas, contre le vrai serveur :

  archive du jour        objet bronze : 9851 ... copie vérifiée
  bronze vidé à la main  ÉCHEC : zone bronze vide dans la copie, code 1
  archive du 3 septembre ÉCHEC : le stockage objet est absent, code 1

L'archive passe de 49 à 52 Mo : le JSON de bronze se comprime bien.

L'en-tête documente aussi l'horaire. La copie était planifiée à 18 h 30 et n'a
jamais tourné, le poste étant éteint à cette heure là : aucun journal.log n'a
jamais été écrit, alors que le miroir planifié à midi, lui, tourne. Une
sauvegarde qui dépend d'une machine allumée se planifie quand la machine est
allumée.

Contribue au #92

lenaic requested reviews from gabriel, justine

2026-09-04 08:26:33 +00:00

lenaic added 1 commit

2026-09-04 08:28:35 +00:00

infra: planifier la copie après le vidage de la forge, pas avant

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 2m4s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 4s

Details

Intégration / Aucun secret commité (pull_request) Successful in 2s

Details

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Failing after 7m12s

Details

58b4be5677

12 h 15 tombait quinze minutes avant la tâche de la forge, qui vidange à 12 h 30.
La copie aurait donc systématiquement emporté l'archive de la veille, ce que sa
propre vérification signale déjà par « ATTENTION : la plus récente est
dump-<hier>.zip ». Un avertissement quotidien qu'on finit par ne plus lire.

45 12 laisse quinze minutes au vidage, dont l'archive fait 34 Mo.

lenaic referenced this pull request

2026-09-04 08:53:08 +00:00

[infra] Copie des sauvegardes hors du serveur, et outillage d'administration à recâbler #92

lenaic commented

2026-09-04 08:53:57 +00:00

Author

Owner

Chaîne rouge, mais pas à cause de cette demande : c'est le #147, une panne du
point d'audit npm qui bloque aussi la #142, la #143 et develop lui-même.

npm ci réussit dans les journaux, seul l'appel d'audit tombe.

Chaîne rouge, mais **pas à cause de cette demande** : c'est le #147, une panne du point d'audit npm qui bloque aussi la #142, la #143 et `develop` lui-même. `npm ci` réussit dans les journaux, seul l'appel d'audit tombe.

lenaic removed review request for justine

2026-09-04 09:31:42 +00:00