Set-OPS-Public/roles/serveur_backup
Daniel Allaire 7348eb93d1 serveur_backup : ce qu un depot peut affirmer sans pouvoir lire
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
2026-09-14 09:58:54 -04:00
..
defaults serveur_backup : ce qu un depot peut affirmer sans pouvoir lire 2026-09-14 09:58:54 -04:00
meta serveur_backup : ce qu un depot peut affirmer sans pouvoir lire 2026-09-14 09:58:54 -04:00
tasks serveur_backup : ce qu un depot peut affirmer sans pouvoir lire 2026-09-14 09:58:54 -04:00
templates serveur_backup : ce qu un depot peut affirmer sans pouvoir lire 2026-09-14 09:58:54 -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

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).