Set-OPS-Public/roles/client_backup
Daniel Allaire 4a1d0836d0 docs : un README par rôle (12 manquants) + carte remise à l'état du code
Solde la dette documentaire repérée à l'audit du 2026-07-03. Tous les rôles ont
désormais un README, au format maison (intention → rôle → variables →
notes/limites → prérequis). Ils documentent ce qui ne se lit PAS dans les tâches :

- serveur_debian : rôle-catégorie sans tâches — il ne porte que le flux SSH du
  plan de gestion, sans quoi les nftables générés couperaient l'accès Ansible à
  toute la flotte ; le vrai travail est dans le playbook de groupe.
- hosts_statiques : le plancher /etc/hosts comme CONDITION de l'ordre de
  reconstruction (résolution par nom avant que PowerDNS existe) ; fichier
  entièrement géré, alias d'exposition best-effort.
- resoudre_base / resoudre_annuaire : entrées, sorties (facts), et pourquoi le
  FQDN plutôt que le nom court (fédération + nom canonique pour verify-full).
- serveur_dovecot : les 3 réglages Dovecot 2.4 qui conditionnent la remise
  (static_allow_all_users, mail_inbox_path vide, mail_path par utilisateur) et
  le local-part seul comme chemin commun LMTP/IMAP ; limite mono-domaine.
- serveur_postfix : liens mailstore/milter, recopie de /etc/hosts dans le chroot.
- serveur_rspamd : clé DKIM idempotente ; le domaine signé doit être PUBLIC en
  prod, sinon la signature ne vaut rien pour les MX distants.
- client_backup / serveur_backup : jobs déclaratifs, chiffrement côté client,
  deux pièges (jobs vides = silencieux ; dépôt neuf vide après un from-zero) ;
  hors-nœud n'est pas hors-site.
- serveur_oauth2_proxy : le patron réutilisable Keycloak-devant-n'importe-quoi,
  et pourquoi allow_unverified_email est nécessaire avec un annuaire LDAP.
- serveur_icingaweb2 : modes ldap vs external, écoute à restreindre en SSO.
- client_unbound : le garde-fou de bascule (apply ET confirm, validation réelle
  avant de toucher /etc/resolv.conf).

docs/carte-set-ops.md ne décrivait plus l'état du code :
- expose EST consommé au déploiement (annoncé comme « Phase 3 à venir ») :
  expositions_des_applications + expositions.conf.j2, alias /etc/hosts, SANs
  d'edge dérivés par instancier.py ;
- 3 mécanismes transverses ajoutés (résolution d'annuaire, plancher de
  résolution, resoudre_base nommé dans les bindings app→base) ;
- 5 entrées d'index ajoutées : réseau/pare-feu, ordre de déploiement,
  preuve/recette, exploitation courante, wiki — pans du corpus non indexés ;
- ce qui reste ouvert est marqué : meta/liens.yml sur le seul serveur_postfix,
  requiert non consommé au déploiement (l'ordre vient des couches + du graphe).

make verifier vert : ansible-lint 514 fichiers, tests, syntax-check,
23 preuves CONFORME / 0 échec / 0 sauté.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-29 11:32:06 -04:00
..
defaults Sauvegardes applicatives (restic) : serveur_backup + client_backup — Tier 0 prouvé 2026-07-03 22:49:26 -04:00
meta Reconstruction propre : orchestrateur ordonné, registre des flux + pare-feu 2026-07-07 03:08:09 -04:00
tasks Sauvegardes applicatives (restic) : serveur_backup + client_backup — Tier 0 prouvé 2026-07-03 22:49:26 -04:00
templates Sauvegardes applicatives (restic) : serveur_backup + client_backup — Tier 0 prouvé 2026-07-03 22:49:26 -04:00
README.md docs : un README par rôle (12 manquants) + carte remise à l'état du code 2026-07-29 11:32:06 -04:00

client_backup

Intégration cliente sauvegarde : le nœud pousse ses données (pas sa VM) vers le dépôt restic hors-nœud (serveur_backup), chiffrées côté client, sur un timer systemd.

Principe

L'infrastructure est reconstructible par le code (make reconstruire). Ce qui ne se reconstruit pas, c'est l'état : clés de l'AC, annuaire, bases, courrier, dépôts Git. C'est cet état — et lui seul — que ce rôle sauvegarde.

Rôle

  • Installe restic.
  • Dépose la clé SSH privée de sauvegarde et le mot de passe restic dans /etc/setops (0600), depuis la voûte.
  • Configure l'accès SSH vers la cible (utilisateur restreint restic).
  • Déploie sauvegarder.sh + l'unité et le timer systemd, et l'active.

Jobs déclaratifs

Chaque nœud déclare ses client_backup_jobs (en group_vars/host_vars) :

client_backup_jobs:
  - nom: step_ca
    chemins: [/etc/step-ca]
  - nom: postgresql
    commande: "sudo -u postgres pg_dumpall > /var/backups/setops/postgresql/all.sql"
    chemins: [/var/backups/setops/postgresql]

Le script exécute, dans l'ordre : les commande (dumps vers le staging) → restic init si le dépôt est neuf → restic backup de tous les cheminsrestic forget --prune (rétention).

Secrets requis (Vault)

vault_restic_password      # mot de passe du dépôt restic (le chiffrement)
vault_backup_ssh_privkey   # clé privée SSH vers la cible (publique côté serveur_backup)

Sans eux, le rôle refuse de s'exécuter (assertion).

Variables principales

Variable Défaut Rôle
client_backup_cible backup-01.{{ domaine_interne }} Nœud dépôt
client_backup_repo sftp:restic@<cible>:<hôte> Un sous-dossier par nœud
client_backup_staging /var/backups/setops Préparation des dumps
client_backup_retention --keep-daily 7 --keep-weekly 4 --keep-monthly 6 restic forget
client_backup_horaire *-*-* 02:30:00 Timer systemd
client_backup_jobs [] À déclarer par nœud

Notes / limites

  • Chiffrement côté client : la cible ne voit que des blocs chiffrés — elle n'a donc pas besoin d'être aussi protégée que les sources.
  • client_backup_jobs: [] = le timer tourne mais ne sauvegarde rien. C'est silencieux : vérifier que chaque nœud porteur d'état déclare ses jobs.
  • Un dépôt neuf est vide jusqu'à la première exécution : après une reconstruction from-zero, déclencher une première sauvegarde plutôt que d'attendre 02:30.
  • Restauration : restic restore avec le même mot de passe (cf. docs/runbooks-exploitation.md).

Prérequis

  • serveur_backup déployé, et sa serveur_backup_pubkey correspondant à la clé privée de la voûte. Couche agents (après les services).