Daniel Allaire
7348eb93d1
Les instantanes sont chiffres cote client : ce serveur heberge des octets qu il ne peut pas ouvrir, donc pas juger. La verification suit la cle, et client_backup la fait deja depuis chaque noeud. Ce que la sonde ajoute : elle voit TOUT DE SUITE, et depuis la cause, ce que les clients ne decouvriront qu a leur prochaine execution. Lecture seule apres une erreur disque, volume plein, droits derives — le depot refuse alors tout le monde, et neuf rouges epars ne designent pas une cause commune. Elle ECRIT vraiment, sous l identite qui depose. Un test -w ment sur un montage en lecture seule et sur un quota atteint. Corrige aussi l en-tete de setops-sauvegardes.conf.j2, qui nommait encore backup-01 comme pousseur — retire le 2026-09-02, et c est tout le sujet. Le code avait suivi la decision, l en-tete non. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
69 lines
3.9 KiB
YAML
69 lines
3.9 KiB
YAML
---
|
|
# Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source).
|
|
# Les clients y accèdent en SFTP/SSH avec la clé de sauvegarde. Chiffrement côté client (restic).
|
|
serveur_backup_utilisateur: "restic"
|
|
serveur_backup_racine: "/srv/restic"
|
|
# Clé PUBLIQUE de sauvegarde autorisée (la privée est dans la voûte, côté client_backup).
|
|
serveur_backup_pubkey: ""
|
|
|
|
# CE DÉPÔT PEUT-IL OUVRIR CE QU'IL GARDE ?
|
|
#
|
|
# `true` chez un écosystème : il garde SES dépôts, il en détient le mot de passe, il
|
|
# peut donc constater ce qui est réellement arrivé — et c'est le seul à le pouvoir,
|
|
# puisqu'un nœud sait qu'il a lancé sa sauvegarde sans savoir qu'elle a abouti.
|
|
#
|
|
# `false` chez le dépôt d'un site : restic chiffre CHEZ LE CLIENT, avec un mot de passe
|
|
# qui reste dans la voûte du locataire. Le site héberge des octets qu'il ne peut ni
|
|
# lire ni ouvrir. Ce n'est pas une lacune : c'est ce qui rend l'hébergement mutualisé
|
|
# acceptable. La vérification a alors lieu chez le locataire, qui détient la clé.
|
|
#
|
|
# `serveur_backup_site` met cette valeur à `false` et dit pourquoi.
|
|
serveur_backup_verification_locale: true
|
|
|
|
# --- Vérification des dépôts et rapport passif vers Icinga ---
|
|
# Le dépôt est le SEUL à voir ce qui est réellement arrivé. Un nœud sait qu'il a lancé sa
|
|
# sauvegarde ; il ne sait pas qu'elle a abouti. D'où la vérification ici, et pas là-bas.
|
|
# Toutes les 4 h, pas une fois par jour : la vérification doit renouveler le `ttl` bien
|
|
# avant qu'il n'expire, sinon un simple retard du timer se lirait comme une sauvegarde
|
|
# perdue. Elle est peu coûteuse (lecture des métadonnées restic).
|
|
serveur_backup_verification_horaire: "*-*-* 00/4:00:00"
|
|
|
|
# Seuils d'âge. Le critère « n'emporte rien » ne se règle pas ici : il se mesure en
|
|
# NOMBRE DE FICHIERS dans l'instantané (zéro = rien emporté), ce qui est exact, alors
|
|
# qu'un seuil en octets signalait à tort un export LDIF de 2,3 Ko.
|
|
serveur_backup_age_warn_h: 26
|
|
serveur_backup_age_crit_h: 50
|
|
|
|
# `ttl` du résultat passif : au-delà, Icinga périme le service de lui-même — c'est ce qui
|
|
# fait que le SILENCE alerte. 6 h pour une vérification toutes les 4 h : une exécution peut
|
|
# être manquée sans fausse alerte, deux ne le peuvent pas.
|
|
serveur_backup_ttl_icinga: 21600
|
|
|
|
# AC à opposer au pair en appelant l'API Icinga. C'est celle d'ICINGA, pas step-ca :
|
|
# Icinga refuse de servir un certificat qu'il n'a pas émis (il renouvelle tout ce qui
|
|
# expire sous 30 jours, nos certificats vivent 24 h). Domaine de confiance fermé, pair
|
|
# authentifié malgré tout — ce qui était le vrai enjeu.
|
|
serveur_backup_icinga_ca_source: "/var/lib/icinga2/ca/ca.crt"
|
|
serveur_backup_ca_verification: "/etc/setops/icinga-ca.crt"
|
|
|
|
# Compte d'API Icinga (portée : uniquement process-check-result sur « sauvegarde: * »).
|
|
serveur_backup_icinga_utilisateur: "setops-depot"
|
|
serveur_backup_icinga_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
|
|
serveur_backup_icinga_hote: "{{ (groups['serveur_icinga'] | default([]) | first) | default('') }}"
|
|
|
|
# Nœuds dont un instantané est ATTENDU : ceux qui portent client_backup ET détiennent
|
|
# réellement de l'état. Même règle que `client_backup_jobs`, même source que P36.
|
|
serveur_backup_noeuds_attendus: >-
|
|
{{ (client_backup_groupes_etat | default([]) | map('extract', groups)
|
|
| select('defined') | flatten | unique | list)
|
|
| intersect(groups['client_backup'] | default([])) }}
|
|
|
|
# --- SONDE DE SUPERVISION -------------------------------------------------------------
|
|
#
|
|
# L'ENDROIT QUE LA SONDE ESSAIE D'ECRIRE. C'est la racine du depot par defaut — celle que
|
|
# les clients atteignent en sftp.
|
|
#
|
|
# C'EST AUSSI LA MISE EN DEFAUT : pointer un chemin non inscriptible (ou inexistant) rend
|
|
# CRITIQUE sans toucher au vrai depot, ce qui rend la seconde preuve REJOUABLE. Une sonde
|
|
# se prouve deux fois — verte sur le sain, rouge sur le casse.
|
|
serveur_backup_sonde_racine: "{{ serveur_backup_racine }}"
|