Daniel Allaire
6653f49f2e
Some checks are pending
verifier / verifier (push) Waiting to run
serveur_backup verifiait pour tout le monde — juste tant que le depot vivait dans l ecosysteme. Depuis qu ils deposent chez leur hebergeur, le site 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, le noeud. client_backup verifie SON depot distant — pas le fait d avoir lance sa sauvegarde. Une unite verte sur un depot vide est ce qui a menti un mois. serveur_icinga n exige plus un hote serveur_backup et se branche sur deux modeles : depot local (services sur son hote, nommes sauvegarde: <noeud>) ou pas de depot (services sur chaque noeud, nommes sauvegarde). Le 404 qui n etait pas une absence : les noeuds recevaient No objects found alors que icinga2 object list montrait le service charge. Le filtre du compte d API ne portait que la premiere forme de nom — c est la PERMISSION qui refusait, avec les mots d une absence. Aussi : ingress 5665 depuis client_backup, le pair ne nommait que serveur_backup. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
15 lines
530 B
Django/Jinja
15 lines
530 B
Django/Jinja
# Géré par Set-OPS (rôle client_backup). Ne pas éditer à la main.
|
|
#
|
|
# DÉCALÉ D'UNE HEURE APRÈS LA SAUVEGARDE (02:30) : vérifier avant que l'instantané du
|
|
# jour ne soit déposé rendrait un « EN RETARD » chaque matin, sur une sauvegarde qui se
|
|
# porte bien. Une alerte qui crie tous les jours cesse d'être lue.
|
|
[Unit]
|
|
Description=Planification de la vérification du dépôt distant
|
|
|
|
[Timer]
|
|
OnCalendar={{ client_backup_verification_horaire }}
|
|
RandomizedDelaySec=300
|
|
Persistent=true
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|