Set-OPS-Public/roles/client_backup
Daniel Allaire f8a84b78d5 reconstruction from-zero : sept defauts, tous invisibles sur une flotte debout
Chezlepro reconstruit depuis zero en 10.17.x.x. Sept defauts sont tombes, et
AUCUN n'etait detectable autrement — c'est tout l'argument de la reconstruction
comme preuve.

  1. aucune route vers le tenant sur le poste (posee a la main, jamais persistee)
  2. backup-01 exigeait l'AC d'Icinga — dependance non declaree
  3. ma correction inversait les couches : REFUSEE PAR P08 avant d'entrer
  4. base Forgejo a moitie initialisee (sequelle de l'arret du n°2)
  5. /etc/hosts : nom court avant le FQDN -> hostname -f faux sur les 14 machines
  6. API Icinga jamais activee (garde `creates:` d'api setup)
  7. restic refuse tout le lot si un chemin declare manque

LE CINQUIEME DEPASSAIT ICINGA. hostname -f rend le PREMIER nom : toute la flotte
se croyait appelee « mon-01 ». Visible sur le certificat d'Icinga, mais le meme
piege attendait Postfix (myhostname), les journaux, les certificats. FQDN d'abord.

CE QU'ON NE CORRIGE PAS : icinga2 api setup REECRIT NodeName d'apres le nom court
et nomme ses certificats d'apres lui. Aligne avant, il est ecrase ; aligne apres,
les certificats portent le mauvais nom. On adopte sa convention : le depot appelle
l'API par le nom court, celui que le certificat porte.

serveur_icinga_node_name derive desormais de l'INVENTAIRE, pas d'ansible_fqdn —
un fait qui depend du resolveur et rendait « mon-01 » alors que le FQDN etait bon.

Le commentaire ecrit pour avertir qu'une sequence accolade-diese casse les
gabarits Jinja contenait cette sequence, et cassait le gabarit. Neuf hotes en
echec pour un avertissement mal redige.

Sept devis CONFORME, prouver 36/36, make test 0. Neuf sauvegardes reussies.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 03:36:56 -04:00
..
defaults supervision : c'est le DEPOT qui dit ou en sont les sauvegardes 2026-08-11 21:39:05 -04:00
handlers sauvegarde : le catalogue derive du groupe, et P36 le prouve 2026-08-11 20:50:46 -04:00
meta Reconstruction propre : orchestrateur ordonné, registre des flux + pare-feu 2026-07-07 03:08:09 -04:00
tasks supervision : c'est le DEPOT qui dit ou en sont les sauvegardes 2026-08-11 21:39:05 -04:00
templates reconstruction from-zero : sept defauts, tous invisibles sur une flotte debout 2026-08-13 03:36:56 -04:00
vars supervision : c'est le DEPOT qui dit ou en sont les sauvegardes 2026-08-11 21:39:05 -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).