Set-OPS-Public/roles/client_backup/defaults/main.yml

---
# Sauvegarde applicative (logique) d'un nœud vers la cible restic hors-nœud.
# Chaque nœud déclare ses "jobs" ; restic chiffre côté client + applique la rétention.
client_backup_paquets:
  - restic

# Cible (nœud serveur_backup) + transport SSH.
client_backup_cible: "backup-01.{{ domaine_interne }}"
client_backup_utilisateur_distant: "restic"
client_backup_ssh_key: "/etc/setops/backup_ed25519"
# Dépôt restic (un sous-dossier par nœud, relatif au home de l'utilisateur distant).
client_backup_repo: "sftp:{{ client_backup_utilisateur_distant }}@{{ client_backup_cible }}:{{ inventory_hostname }}"
client_backup_password: "{{ vault_restic_password | default('') }}"
client_backup_ssh_privkey: "{{ vault_backup_ssh_privkey | default('') }}"

# Dossier de préparation des dumps (pg_dump, slapcat, forgejo dump...).
client_backup_staging: "/var/backups/setops"

# Rétention (restic forget).
client_backup_retention: "--keep-daily 7 --keep-weekly 4 --keep-monthly 6"

# Planification (timer systemd).
client_backup_horaire: "*-*-* 02:30:00"

# Jobs déclaratifs. Chaque job :
#   nom      : identifiant
#   commande : (optionnel) dump écrivant dans {{ staging }}/{{ nom }}
#   chemins  : liste de chemins à inclure dans le snapshot restic
#
# CATALOGUE PAR GROUPE — c'est le rôle qui POSSEDE la donnée qui dit comment la sortir.
# On sauvegarde l'ETAT NON REGENERABLE, pas ce que le code reconstruit : ni les zones
# PowerDNS ni les tableaux de bord Grafana ne figurent ici, ils se redéploient.
#
# Les chemins reprennent les defauts du role proprietaire, mais NE PEUVENT PAS y faire
# reference : `make deployer` deroule un play par groupe, et les defaults de
# `serveur_forgejo` ne sont pas charges pendant le play de `client_backup`. D'ou la forme
# `var | default(litteral)` — la variable gagne si l'inventaire la definit, sinon le
# defaut du role proprietaire, recopie ici et a garder aligne avec lui.
client_backup_catalogue:
  serveur_step_ca:
    nom: step_ca
    chemins:
      - "{{ serveur_step_ca_steppath | default('/etc/step-ca') }}"
  serveur_openldap:
    nom: openldap
    # slapcat lit la base a plat : pas d'authentification, coherent meme slapd arrete.
    commande: >-
      slapcat -b '{{ serveur_openldap_base_dn | default("dc=" + domaine_interne.split(".") | join(",dc=")) }}'
      > {{ client_backup_staging }}/openldap/annuaire.ldif
    chemins: ["{{ client_backup_staging }}/openldap"]
  serveur_postgresql:
    nom: postgresql
    # pg_dumpall : TOUTES les bases + les roles et leurs mots de passe. Une base oubliee
    # ici serait une base perdue — d'ou le dump global plutot qu'une liste a maintenir.
    commande: >-
      runuser -u postgres -- pg_dumpall --clean
      > {{ client_backup_staging }}/postgresql/toutes-bases.sql
    chemins: ["{{ client_backup_staging }}/postgresql"]
  serveur_dovecot:
    nom: courriel
    chemins: ["{{ serveur_dovecot_vmail_base | default('/var/vmail') }}"]
  serveur_forgejo:
    nom: forgejo
    chemins:
      - "{{ serveur_forgejo_data | default('/var/lib/forgejo') }}"
      - "{{ serveur_forgejo_config_dir | default('/etc/forgejo') }}"
  serveur_nextcloud:
    nom: nextcloud
    chemins:
      - "{{ serveur_nextcloud_data_dir | default('/var/www/nextcloud/data') }}"
      - "{{ (serveur_nextcloud_racine | default('/var/www/nextcloud')) + '/config' }}"
  serveur_rspamd:
    # Le bayes APPRIS est de l'etat : reconstruire le noeud reinstalle rspamd, pas ce
    # qu'il a appris. Les regles, elles, se redeploient et ne sont pas ici.
    nom: rspamd
    chemins: ["/var/lib/rspamd"]
  serveur_web_frontal:
    nom: web_frontal
    chemins: ["{{ serveur_web_frontal_racine_base | default('/srv/web') }}"]
  serveur_web_dorsal:
    nom: web_dorsal
    chemins: ["{{ serveur_web_dorsal_racine | default('/srv/webapp') }}"]

# Jeux retenus pour CE noeud : intersection du catalogue et de ses groupes. Derive, donc
# un tenant qui deplace un service emporte sa sauvegarde avec lui, sans rien re-declarer.
client_backup_jobs: >-
  {{ client_backup_catalogue | dict2items
     | selectattr('key', 'in', group_names) | map(attribute='value') | list }}

# La liste EN CLAIR des memes groupes vit dans `vars/main.yml` — sans Jinja, pour que la
# supervision et P36 puissent la lire par `include_vars` sans rendre ce catalogue.

# --- LE NOEUD VERIFIE SON PROPRE DEPOT ----------------------------------------
#
# POURQUOI ICI, ALORS QUE `serveur_backup` LE FAISAIT DEJA.
#
# Le depot etait le seul a voir ce qui etait REELLEMENT arrive : un noeud sait qu'il a
# lance sa sauvegarde, il ne sait pas qu'elle a abouti. C'etait juste tant que le depot
# appartenait au meme ecosysteme.
#
# Depuis que les ecosystemes deposent chez leur HEBERGEUR, ca ne l'est plus : le site
# heberge des octets chiffres par restic COTE CLIENT, avec un mot de passe qui ne quitte
# pas la voute du locataire. Il ne peut ni les lire, ni les ouvrir, ni dire s'ils valent
# quelque chose. C'est la propriete qui rend la mutualisation acceptable — et elle
# deplace la verification chez le seul qui detient la cle : le noeud lui-meme.
#
# Il verifie donc SON depot distant, pas le fait d'avoir lance sa sauvegarde. La nuance
# est tout : une unite systemd verte sur un depot vide est exactement ce qui a menti
# pendant un mois (2026-07-03 -> 2026-08-11).
client_backup_icinga_hote: "{{ (groups['serveur_icinga'] | default([]) | first) | default('') }}"
client_backup_icinga_utilisateur: "setops-depot"
client_backup_icinga_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
client_backup_ca_verification: "/etc/setops/icinga-ca.crt"
client_backup_icinga_ca_source: "/var/lib/icinga2/ca/ca.crt"

# `ttl` du resultat passif : au-dela, Icinga perime le service de lui-meme — c'est ce qui
# fait que le SILENCE alerte. Memes valeurs que cote depot : une verification toutes les
# 4 h, une execution peut etre manquee sans fausse alerte, deux ne le peuvent pas.
client_backup_verification_horaire: "*-*-* 01/4:00:00"
client_backup_ttl_icinga: 21600
client_backup_age_warn_h: 26
client_backup_age_crit_h: 50

# LE CONTROLE DE RESTAURATION (2026-09-28) — voir `templates/verifier-restauration.sh.j2`.
# Hebdomadaire : il relit une part du depot et restaure le dernier instantane pour de vrai.
client_backup_restauration_horaire: "Sun *-*-* 04:00:00"
client_backup_restauration_part: "10%"
# Huit jours : une semaine entre deux controles, plus une journee de marge. Au-dela sans
# nouvelle, Icinga passe le service au rouge (voir `serveur_icinga_fraicheur_restauration`).
client_backup_ttl_restauration: 691200