History

Daniel Allaire f1a7e43645 supervision : c'est le DEPOT qui dit ou en sont les sauvegardes Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement la config Debian d'origine sur localhost. Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme : l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc ses depots et pousse un resultat passif par noeud vers l'API Icinga. Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est recent (26 h / 50 h), il contient au moins un fichier. Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse — compromettre mon-01 ne donne aucun acces aux sauvegardes. Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les services tout seul. C'est le silence qui a laisse le defaut vivre un mois. Deux erreurs corrigees par la mesure : - --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS et l'auth marchaient, seule la charge etait perdue. - le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont disparu » de « il n'y en a pas encore ». Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-11 21:39:05 -04:00
..
defaults	supervision : c'est le DEPOT qui dit ou en sont les sauvegardes	2026-08-11 21:39:05 -04:00
meta	supervision : c'est le DEPOT qui dit ou en sont les sauvegardes	2026-08-11 21:39:05 -04:00
tasks	supervision : c'est le DEPOT qui dit ou en sont les sauvegardes	2026-08-11 21:39:05 -04:00
templates	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

README.md

serveur_backup

Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source), servis en SFTP/SSH à un utilisateur restreint. Le pendant de client_backup.

Rôle

Crée l'utilisateur système restic et la racine des dépôts /srv/restic.
Sécurise cette racine (droits stricts).
Autorise la clé publique de sauvegarde dans son authorized_keys.

C'est tout : le rôle est délibérément minimal. Aucun démon, aucune logique de sauvegarde — tout se passe côté client (dumps, chiffrement, rétention).

Sécurité

Le chiffrement est fait par le client (restic) : ce nœud ne détient que des blocs chiffrés et n'a jamais le mot de passe des dépôts. Compromettre la cible ne donne pas accès aux données.

La clé privée correspondante vit dans la voûte, côté client_backup (vault_backup_ssh_privkey) ; seule la publique est déclarée ici.

Variables

Variable	Défaut	Rôle
`serveur_backup_utilisateur`	`restic`	Compte de dépôt
`serveur_backup_racine`	`/srv/restic`	Racine des dépôts
`serveur_backup_pubkey`	(vide — obligatoire)	Clé publique autorisée

Le rôle exige serveur_backup_pubkey (assertion) : sans elle, la cible serait déployée mais inaccessible.

Flux (`meta/flux.yml`)

22/tcp entrant depuis client_backup (SSH, clé dédiée). Aucun autre port.

Notes / limites

Hors-nœud, pas hors-site : la cible protège de la perte d'une VM, pas de la perte du cluster. Une copie hors-site reste à faire.
Dimensionner le disque en conséquence (meta/empreinte.yml : 64 Go par défaut) — c'est la ressource critique de ce nœud.
Le compte restic n'est pas confiné à un shell restreint (rrsync/ForceCommand) : durcissement possible si la cible venait à sortir du périmètre de confiance.

Prérequis

Couche services (avant les agents client_backup).