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

lenaic commented

2026-09-02 14:22:00 +00:00

Owner

Exigence couverte

ENF-05, ENF-09, ENF-15

Épreuve servie

EC04 · Cloud et sécurisation

Charge estimée

1 j.h

Ce qu'on veut obtenir

Sortir une copie des sauvegardes du serveur, et remettre en marche l'outillage d'administration que le durcissement SSH vient de couper.

Les sauvegardes tournent, c'est vérifié : vidage de la forge à 12h30 (11 Mo aujourd'hui), vidage PostgreSQL à 2h30, rétention de sept jours. Mais tout reste sur la machine. Une perte du conteneur LXC emporte le dépôt, les tickets, les bases et leurs sauvegardes d'un seul coup.

Critères d'acceptation

Une copie quotidienne des vidages part hors du serveur, vers le stockage de secours du #69 ou vers un poste de l'équipe.
La copie est vérifiée : un fichier présent n'est pas une sauvegarde valide, il faut lire sa table des matières.
Une restauration est jouée depuis la copie hors serveur, chronométrée, cible de quatre heures (ENF-05).
Les scripts d'administration du poste passent par un compte nominatif au lieu de root. Critère amendé le 3 septembre : il disait « par le compte deploy » ; le motif du changement est en commentaire ci-dessous. Le périmètre réel était de huit scripts, pas trois.
Le manuel de la forge est corrigé : il décrit encore un accès root qui n'existe plus.

Comment on le vérifie

Commande la copie hors serveur listée depuis le poste, puis unzip -l sur l'archive de la forge
Attendu une archive datée du jour, contenant gitea-db.sql et gitea-repo/
Preuve la sortie du listing et le chronomètre de la restauration

Manuel d'exploitation à mettre à jour

docs/runbooks/forge.md, section sauvegarde, et docs/FORGE.md pour l'accès

Risque et retour arrière

Une copie qui part vers un poste de l'équipe déplace le risque plutôt que de le supprimer : deux machines dans la même salle tombent ensemble. Le stockage de secours cloud du #69 est la vraie réponse, ce ticket peut se contenter d'une copie locale en attendant, à condition de le dire.

### Exigence couverte ENF-05, ENF-09, ENF-15 ### Épreuve servie EC04 · Cloud et sécurisation ### Charge estimée 1 j.h ### Ce qu'on veut obtenir Sortir une copie des sauvegardes du serveur, et remettre en marche l'outillage d'administration que le durcissement SSH vient de couper. Les sauvegardes tournent, c'est vérifié : vidage de la forge à 12h30 (11 Mo aujourd'hui), vidage PostgreSQL à 2h30, rétention de sept jours. Mais **tout reste sur la machine**. Une perte du conteneur LXC emporte le dépôt, les tickets, les bases et leurs sauvegardes d'un seul coup. ### Critères d'acceptation - [x] Une copie quotidienne des vidages part hors du serveur, vers le stockage de secours du #69 ou vers un poste de l'équipe. - [x] La copie est vérifiée : un fichier présent n'est pas une sauvegarde valide, il faut lire sa table des matières. - [x] Une restauration est jouée depuis la copie hors serveur, chronométrée, cible de quatre heures (ENF-05). - [x] Les scripts d'administration du poste passent par un **compte nominatif** au lieu de `root`. **Critère amendé le 3 septembre** : il disait « par le compte `deploy` » ; le motif du changement est en commentaire ci-dessous. Le périmètre réel était de **huit scripts**, pas trois. - [x] Le manuel de la forge est corrigé : il décrit encore un accès `root` qui n'existe plus. ### Comment on le vérifie Commande la copie hors serveur listée depuis le poste, puis unzip -l sur l'archive de la forge Attendu une archive datée du jour, contenant gitea-db.sql et gitea-repo/ Preuve la sortie du listing et le chronomètre de la restauration ### Manuel d'exploitation à mettre à jour `docs/runbooks/forge.md`, section sauvegarde, et `docs/FORGE.md` pour l'accès ### Risque et retour arrière Une copie qui part vers un poste de l'équipe déplace le risque plutôt que de le supprimer : deux machines dans la même salle tombent ensemble. Le stockage de secours cloud du #69 est la vraie réponse, ce ticket peut se contenter d'une copie locale en attendant, à condition de le dire.

lenaic added the

labels

2026-09-02 14:22:00 +00:00

lenaic self-assigned this

2026-09-02 14:22:00 +00:00

lenaic referenced this issue

2026-09-02 14:33:29 +00:00

infra: copie vérifiée des sauvegardes hors du serveur #93

lenaic commented

2026-09-02 14:33:30 +00:00

Author

Owner

Deux critères sur cinq sont tenus, demande de fusion ci-dessus.

La copie hors serveur existe et tourne. Planifiée à 18h30 du lundi au vendredi vers ~/eadl/sauvegardes/, rétention de quatorze jours. Première exécution faite : 14 Mo, archive du jour vérifiée.

Elle est vérifiée, pas seulement comptée. Et la vérification a servi immédiatement : le manuel annonçait gitea-db.sql et gitea-repo/, noms hérités de l'ancêtre du projet. Forgejo 12 écrit forgejo-db.sql et repos/. Quelqu'un qui aurait suivi le manuel pour contrôler une sauvegarde l'aurait crue vide alors qu'elle contient 2 406 fichiers.

Restent trois choses : la restauration jouée chronomètre en main, le recâblage des scripts d'administration qui passaient par root, et le raccordement au stockage de secours du #69 quand il existera. Les deux machines sont dans la même salle : cette copie réduit le risque, elle ne le supprime pas.

Deux critères sur cinq sont tenus, demande de fusion ci-dessus. **La copie hors serveur existe et tourne.** Planifiée à 18h30 du lundi au vendredi vers `~/eadl/sauvegardes/`, rétention de quatorze jours. Première exécution faite : 14 Mo, archive du jour vérifiée. **Elle est vérifiée, pas seulement comptée.** Et la vérification a servi immédiatement : le manuel annonçait `gitea-db.sql` et `gitea-repo/`, noms hérités de l'ancêtre du projet. Forgejo 12 écrit `forgejo-db.sql` et `repos/`. Quelqu'un qui aurait suivi le manuel pour contrôler une sauvegarde l'aurait crue vide alors qu'elle contient 2 406 fichiers. Restent trois choses : la restauration jouée chronomètre en main, le recâblage des scripts d'administration qui passaient par `root`, et le raccordement au stockage de secours du #69 quand il existera. Les deux machines sont dans la même salle : cette copie réduit le risque, elle ne le supprime pas.

florian added this to the EnerVision project

2026-09-02 14:51:21 +00:00

lenaic referenced this issue from a commit

2026-09-02 20:50:30 +00:00

docs: restauration hors serveur jouée et chronométrée (9 min 51 s), manuels à jour (#92)

lenaic referenced this issue

2026-09-02 20:50:49 +00:00

docs: restauration hors serveur jouée et chronométrée, manuels à jour (#92) #99

lenaic commented

2026-09-02 20:50:51 +00:00

Author

Owner

Restauration jouée ce soir depuis la copie hors serveur, sur machine vierge (mon poste, hors salle). Chronométrée : 9 min 51 s, pour une cible de 4 heures.

Périmètre restauré et vérifié :

Forge : conteneur Forgejo 12.0.4 monté sur le vidage du jour — healthz: pass, 2 dépôts, 75 tickets, les 7 comptes (forgejo admin user list). Détail utile : le vidage contient forgejo.db prêt à l'emploi, ne pas rejouer forgejo-db.sql par-dessus.
PostgreSQL : image maison reconstruite depuis le dépôt, rôles globaux + 3 bases restaurés, TimescaleDB 2.29.2 active. Piège consigné : shared_preload_libraries=timescaledb obligatoire, sinon pg_restore échoue. Les bases sont quasi vides à ce stade — l'exercice sera à rejouer quand la collecte produira. Procédure et frictions consignées dans docs/runbooks/reprise.md (MR #99).

Chrono : départ 21:31:10 (début du rapatriement de la copie), arrivée 21:41:01 (forge et base interrogées sur la machine de secours).

Reste un critère : le recâblage des scripts du poste (sync-cles.sh, qui.sh, 50-backup.sh) sur le compte deploy — demain en salle, les scripts vivent sur le poste.

Restauration jouée ce soir depuis la copie hors serveur, sur machine vierge (mon poste, hors salle). Chronométrée : **9 min 51 s**, pour une cible de 4 heures. Périmètre restauré et vérifié : - **Forge** : conteneur Forgejo 12.0.4 monté sur le vidage du jour — `healthz: pass`, **2 dépôts, 75 tickets, les 7 comptes** (`forgejo admin user list`). Détail utile : le vidage contient `forgejo.db` prêt à l'emploi, ne pas rejouer `forgejo-db.sql` par-dessus. - **PostgreSQL** : image maison reconstruite depuis le dépôt, rôles globaux + 3 bases restaurés, TimescaleDB 2.29.2 active. Piège consigné : `shared_preload_libraries=timescaledb` obligatoire, sinon `pg_restore` échoue. Les bases sont quasi vides à ce stade — l'exercice sera à rejouer quand la collecte produira. Procédure et frictions consignées dans `docs/runbooks/reprise.md` (MR #99). Chrono : départ 21:31:10 (début du rapatriement de la copie), arrivée 21:41:01 (forge et base interrogées sur la machine de secours). Reste un critère : le recâblage des scripts du poste (`sync-cles.sh`, `qui.sh`, `50-backup.sh`) sur le compte `deploy` — demain en salle, les scripts vivent sur le poste.

lenaic commented

2026-09-03 12:20:38 +00:00

Author

Owner

Critère 4 fait, et il était plus large que ce que le ticket disait

Le ticket nommait trois scripts. Il y en avait huit qui se connectaient encore en
root@, et ils étaient tous cassés : le durcissement du 1er septembre a retiré root
d'AllowUsers, donc ssh root@10.105.200.41 rend Permission denied depuis deux jours.
Personne ne s'en était aperçu parce que personne ne les avait relancés.

qui.sh   revoquer-cles-provisoires.sh   bascule-reseaux.sh   sync-cles.sh
config-miroir.sh   sync-forgejo-cle.sh   creer-comptes.sh   50-backup.sh

Tous passent désormais par ADMIN_USER, nominatif, avec une élévation sudo explicite
sur la charge distante.

Pourquoi un compte nominatif et non `deploy`

Le critère disait « par le compte deploy ». Je m'en écarte, pour deux raisons.

La première est de fond. deploy est l'identité de la chaîne de déploiement, celle
qu'Ansible et le déploiement continu empruntent. Faire passer l'outillage humain par elle
mettrait chaque geste manuel sous un nom qui signifie « la chaîne l'a fait ». C'est
exactement ce que le passage aux comptes nominatifs a permis de distinguer, et ce que
qui.sh sert à lire.

La seconde est matérielle. /opt/g2-forge est en 0750 root:root : deploy ne peut
même pas le traverser. 50-backup.sh aurait échoué au premier cd.

Deux scripts n'étaient pas à recâbler, ils étaient obsolètes

sync-cles.sh et revoquer-cles-provisoires.sh écrivaient dans
/root/.ssh/authorized_keys, fichier qui ne sert plus à rien depuis que chacun a son
compte. Ils ne cassaient rien : ils ne faisaient plus rien du tout. Réécrits pour poser et
retirer les clés dans le compte de chacun.

revoquer-cles-provisoires.sh gagne au passage un garde-fou : il refuse de retirer la clé
provisoire d'un membre dont aucune clé personnelle n'est connue. Sans lui, il coupait la
personne du serveur.

Un défaut trouvé dans ma propre réécriture, avant de la lancer

Ma première version de sync-cles.sh ne poussait que les clés personnelles et retirait
la clé d'automatisation du compte d'administration. Or les huit scripts s'y connectent
avec elle : elle aurait coupé tout l'outillage d'un coup, sans que rien ne le dise avant
le lancement suivant. C'est la famille de panne du 3 septembre. La clé est de nouveau
posée en tête, et le commentaire dit pourquoi.

Vérifications réelles

qui.sh, joué sur le serveur :

sept. 03 12:12:57   marvin    10.105.200.24    marvin
sept. 03 12:14:50   olivier   172.26.44.23     olivier
sept. 03 12:15:00   deploy    10.105.200.32    lenaic (provisoire)

Il révèle au passage que je me connecte encore avec ma clé provisoire, pas une clé
personnelle. Son découpage a dû être repris : il reposait sur une expression régulière
calée sur la date en anglais, alors que le serveur journalise en français. Elle ne
reconnaissait aucune ligne, en silence.

50-backup.sh, joué sur le serveur :

Finish dumping in file /data/dump-20260903.zip
Disque : 41G libres sur 63G
Copie hors serveur récupérée : backups/dump-20260903.zip (33M)

Son scp lisait un chemin que seul root peut traverser, échec avalé par un 2>/dev/null.
Le vidage passe maintenant par un relais dans /tmp, appartenant au compte, supprimé
après rapatriement. Et l'échec est désormais bruyant.

Ce qui reste

sync-cles.sh et revoquer-cles-provisoires.sh sont réécrits mais pas joués. Ils
réécrivent l'accès des six personnes ; ça se lance délibérément, pas au fil d'une
correction.
Les critères 3 et 5 attendent la fusion de la #99, ouverte depuis hier 20 h 50,
approuvée par Florian et Gabriel, chaîne au vert, sans conflit.
Ces scripts vivent sur le poste et non dans le dépôt. Les y porter est le #64.

### Critère 4 fait, et il était plus large que ce que le ticket disait Le ticket nommait trois scripts. Il y en avait **huit** qui se connectaient encore en `root@`, et ils étaient tous **cassés** : le durcissement du 1er septembre a retiré root d'`AllowUsers`, donc `ssh root@10.105.200.41` rend `Permission denied` depuis deux jours. Personne ne s'en était aperçu parce que personne ne les avait relancés. ``` qui.sh revoquer-cles-provisoires.sh bascule-reseaux.sh sync-cles.sh config-miroir.sh sync-forgejo-cle.sh creer-comptes.sh 50-backup.sh ``` Tous passent désormais par `ADMIN_USER`, nominatif, avec une élévation `sudo` explicite sur la charge distante. ### Pourquoi un compte nominatif et non `deploy` Le critère disait « par le compte `deploy` ». Je m'en écarte, pour deux raisons. **La première est de fond.** `deploy` est l'identité de la chaîne de déploiement, celle qu'Ansible et le déploiement continu empruntent. Faire passer l'outillage humain par elle mettrait chaque geste manuel sous un nom qui signifie « la chaîne l'a fait ». C'est exactement ce que le passage aux comptes nominatifs a permis de distinguer, et ce que `qui.sh` sert à lire. **La seconde est matérielle.** `/opt/g2-forge` est en `0750 root:root` : `deploy` ne peut même pas le traverser. `50-backup.sh` aurait échoué au premier `cd`. ### Deux scripts n'étaient pas à recâbler, ils étaient obsolètes `sync-cles.sh` et `revoquer-cles-provisoires.sh` écrivaient dans `/root/.ssh/authorized_keys`, fichier qui ne sert plus à rien depuis que chacun a son compte. Ils ne cassaient rien : ils ne faisaient plus rien du tout. Réécrits pour poser et retirer les clés **dans le compte de chacun**. `revoquer-cles-provisoires.sh` gagne au passage un garde-fou : il refuse de retirer la clé provisoire d'un membre dont aucune clé personnelle n'est connue. Sans lui, il coupait la personne du serveur. ### Un défaut trouvé dans ma propre réécriture, avant de la lancer Ma première version de `sync-cles.sh` ne poussait que les clés personnelles et **retirait la clé d'automatisation** du compte d'administration. Or les huit scripts s'y connectent avec elle : elle aurait coupé tout l'outillage d'un coup, sans que rien ne le dise avant le lancement suivant. C'est la famille de panne du 3 septembre. La clé est de nouveau posée en tête, et le commentaire dit pourquoi. ### Vérifications réelles `qui.sh`, joué sur le serveur : ``` sept. 03 12:12:57 marvin 10.105.200.24 marvin sept. 03 12:14:50 olivier 172.26.44.23 olivier sept. 03 12:15:00 deploy 10.105.200.32 lenaic (provisoire) ``` Il révèle au passage que je me connecte encore avec ma **clé provisoire**, pas une clé personnelle. Son découpage a dû être repris : il reposait sur une expression régulière calée sur la date en anglais, alors que le serveur journalise en français. Elle ne reconnaissait aucune ligne, en silence. `50-backup.sh`, joué sur le serveur : ``` Finish dumping in file /data/dump-20260903.zip Disque : 41G libres sur 63G Copie hors serveur récupérée : backups/dump-20260903.zip (33M) ``` Son `scp` lisait un chemin que seul root peut traverser, échec avalé par un `2>/dev/null`. Le vidage passe maintenant par un relais dans `/tmp`, appartenant au compte, supprimé après rapatriement. Et l'échec est désormais bruyant. ### Ce qui reste - **`sync-cles.sh` et `revoquer-cles-provisoires.sh` sont réécrits mais pas joués.** Ils réécrivent l'accès des six personnes ; ça se lance délibérément, pas au fil d'une correction. - **Les critères 3 et 5 attendent la fusion de la #99**, ouverte depuis hier 20 h 50, approuvée par Florian et Gabriel, chaîne au vert, sans conflit. - Ces scripts vivent sur le poste et non dans le dépôt. Les y porter est le **#64**.

gabriel added

and removed

labels

2026-09-03 12:25:56 +00:00

gabriel added this to the J1 — 04/09 bout-en-bout milestone

2026-09-03 12:26:21 +00:00

gabriel added the due date 2026-09-04

2026-09-03 12:40:57 +00:00

lenaic referenced this issue from a commit

2026-09-03 12:56:41 +00:00

Merge pull request 'docs: restauration hors serveur jouée et chronométrée, manuels à jour (#92)' (#99) from lenaic/92-restauration-hors-serveur into develop

lenaic referenced this issue

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

[92] La copie hors serveur emporte le stockage objet #146

lenaic referenced this issue from a commit

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

infra: la copie hors serveur emporte le stockage objet

lenaic commented

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

Author

Owner

Point du 4 septembre, après vérification sur le serveur et sur le poste. Deux
critères passent, un revient en arrière.

Critère 3, la restauration : fait

Jouée le 3 septembre depuis la copie hors serveur, sur machine vierge, en
9 min 51 s pour une cible de quatre heures. La preuve est dans le
commentaire du 3 septembre, elle n'avait simplement pas été cochée.

Critère 5, le manuel : fait

Plus aucune occurrence de root@ dans docs/. forge.md décrit
ssh <prénom>@10.105.200.41 avec sudo sans mot de passe.

Critère 1, la copie quotidienne : décoché, il était faux

La planification existait, 30 18 * * 1-5, mais elle n'a jamais tourné.
Aucun journal.log n'a jamais été écrit dans ~/eadl/sauvegardes/. Ce n'est pas
cron : le miroir, planifié à midi et à 18 h, a bien tourné à midi le 3 et pas à
18 h. Le poste est éteint à cette heure là.

Les trois copies existantes, des 2, 3 et 4 septembre, sont donc toutes manuelles.
Une sauvegarde qui dépend d'une machine allumée se planifie quand la machine est
allumée.

Corrigé : la ligne passe à 45 12 * * 1-5. Après le vidage de la forge de
12 h 30, pas avant, sans quoi la copie emporterait systématiquement l'archive de
la veille. Le critère se recochera quand un journal.log existera, c'est-à-dire
aujourd'hui à 12 h 45.

Et un trou qui n'était dans aucun critère : MinIO

Le stockage objet 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 ne
couvrait que /opt/g2-forge/backups et /var/backups/postgresql.

Toute la zone médaillon, 79 Mo et 9851 objets, tenait 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.

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

Traité par la #146, éprouvée dans les trois cas contre le vrai serveur :

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

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

Ce qui reste

Le critère 1, jusqu'à 12 h 45 aujourd'hui. Et la fusion de la #146, actuellement
bloquée par une panne du point d'audit npm qui n'a rien à voir avec ce ticket.

Point du 4 septembre, après vérification sur le serveur et sur le poste. **Deux critères passent, un revient en arrière.** ### Critère 3, la restauration : fait Jouée le 3 septembre depuis la copie hors serveur, sur machine vierge, en **9 min 51 s** pour une cible de quatre heures. La preuve est dans le commentaire du 3 septembre, elle n'avait simplement pas été cochée. ### Critère 5, le manuel : fait Plus aucune occurrence de `root@` dans `docs/`. `forge.md` décrit `ssh <prénom>@10.105.200.41` avec `sudo` sans mot de passe. ### Critère 1, la copie quotidienne : décoché, il était faux La planification existait, `30 18 * * 1-5`, mais **elle n'a jamais tourné**. Aucun `journal.log` n'a jamais été écrit dans `~/eadl/sauvegardes/`. Ce n'est pas cron : le miroir, planifié à midi et à 18 h, a bien tourné à midi le 3 et pas à 18 h. **Le poste est éteint à cette heure là.** Les trois copies existantes, des 2, 3 et 4 septembre, sont donc toutes manuelles. Une sauvegarde qui dépend d'une machine allumée se planifie quand la machine est allumée. Corrigé : la ligne passe à `45 12 * * 1-5`. Après le vidage de la forge de 12 h 30, pas avant, sans quoi la copie emporterait systématiquement l'archive de la veille. Le critère se recochera quand un `journal.log` existera, c'est-à-dire aujourd'hui à 12 h 45. ### Et un trou qui n'était dans aucun critère : MinIO **Le stockage objet 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 ne couvrait que `/opt/g2-forge/backups` et `/var/backups/postgresql`. Toute la zone médaillon, **79 Mo et 9851 objets**, tenait 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. `stockage-minio.md` proposait bien un `mc mirror`, mais vers `/srv/enervision/sauvegardes`, **le même disque que MinIO**. Ça protège d'une fausse manoeuvre, pas de la perte de la machine. Traité par la #146, éprouvée dans les trois cas contre le vrai serveur : ``` 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 ``` L'archive passe de 49 à 52 Mo seulement, le JSON de bronze se comprimant bien. ### Ce qui reste Le critère 1, jusqu'à 12 h 45 aujourd'hui. Et la fusion de la #146, actuellement bloquée par une panne du point d'audit npm qui n'a rien à voir avec ce ticket.

lenaic commented

2026-09-04 13:39:33 +00:00

Author

Owner

Critère 1 atteint, les cinq sont cochés.

La copie planifiée a tourné seule aujourd'hui à 12 h 45, pour la première
fois. ~/eadl/sauvegardes/journal.log existe et porte sa sortie, l'archive du
jour est datée de 12 h 45, et le script l'a vérifiée.

Rappel de ce qui bloquait : la ligne était planifiée à 30 18 * * 1-5 et n'avait
jamais tourné, le poste étant éteint à cette heure là. Ce n'était pas cron :
le miroir, planifié à midi et à 18 h, tournait bien à midi et jamais à 18 h. La
ligne est passée à 45 12 * * 1-5, après le vidage de la forge de 12 h 30 et non
avant, sans quoi la copie emporterait systématiquement l'archive de la veille.

Le stockage objet est dedans

La #146 étant fusionnée, le script du poste a été resynchronisé depuis le dépôt.
Éprouvé à l'instant :

archive reçue : sauvegardes-2026-09-04.tar.gz (129M)
objet   bronze : 12755
objet   silver : 3
objet   gold : 0
objet   mlflow : 5
== copie vérifiée ==

L'archive passe de 52 à 129 Mo dans la journée : la zone bronze a grossi, et la
zone argent y est maintenant, la transformation tournant toutes les heures depuis
le #136.

Un point d'exploitation à connaître : le script du poste est une copie, pas
un lien vers le dépôt. Une fusion qui le modifie ne met pas la machine à jour. Un
cp depuis infra/scripts/ reste nécessaire, et c'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.

**Critère 1 atteint, les cinq sont cochés.** La copie planifiée a tourné seule aujourd'hui à **12 h 45**, pour la première fois. `~/eadl/sauvegardes/journal.log` existe et porte sa sortie, l'archive du jour est datée de 12 h 45, et le script l'a vérifiée. Rappel de ce qui bloquait : la ligne était planifiée à `30 18 * * 1-5` et n'avait **jamais** tourné, le poste étant éteint à cette heure là. Ce n'était pas cron : le miroir, planifié à midi et à 18 h, tournait bien à midi et jamais à 18 h. La ligne est passée à `45 12 * * 1-5`, après le vidage de la forge de 12 h 30 et non avant, sans quoi la copie emporterait systématiquement l'archive de la veille. ### Le stockage objet est dedans La #146 étant fusionnée, le script du poste a été resynchronisé depuis le dépôt. Éprouvé à l'instant : ``` archive reçue : sauvegardes-2026-09-04.tar.gz (129M) objet bronze : 12755 objet silver : 3 objet gold : 0 objet mlflow : 5 == copie vérifiée == ``` L'archive passe de 52 à 129 Mo dans la journée : la zone bronze a grossi, et la zone argent y est maintenant, la transformation tournant toutes les heures depuis le #136. Un point d'exploitation à connaître : **le script du poste est une copie**, pas un lien vers le dépôt. Une fusion qui le modifie ne met pas la machine à jour. Un `cp` depuis `infra/scripts/` reste nécessaire, et c'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 closed this issue

2026-09-04 13:39:33 +00:00

gabriel referenced this issue from a commit

2026-09-09 08:29:43 +00:00

docs: reprise.md devient autoportante, les trois trous du rejeu tiers (#44)

gabriel referenced this issue

2026-09-09 08:30:06 +00:00

runbook : reprise.md autoportante, les trois trous du rejeu tiers (#44) #230