Daniel Allaire
6653f49f2e
Some checks are pending
verifier / verifier (push) Waiting to run
serveur_backup verifiait pour tout le monde — juste tant que le depot vivait dans l ecosysteme. Depuis qu ils deposent chez leur hebergeur, le site heberge des octets chiffres COTE CLIENT : il ne peut ni les lire ni dire s ils valent quelque chose. La verification revient donc au seul qui detient la cle, le noeud. client_backup verifie SON depot distant — pas le fait d avoir lance sa sauvegarde. Une unite verte sur un depot vide est ce qui a menti un mois. serveur_icinga n exige plus un hote serveur_backup et se branche sur deux modeles : depot local (services sur son hote, nommes sauvegarde: <noeud>) ou pas de depot (services sur chaque noeud, nommes sauvegarde). Le 404 qui n etait pas une absence : les noeuds recevaient No objects found alors que icinga2 object list montrait le service charge. Le filtre du compte d API ne portait que la premiere forme de nom — c est la PERMISSION qui refusait, avec les mots d une absence. Aussi : ingress 5665 depuis client_backup, le pair ne nommait que serveur_backup. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| vars | ||
| README.md | ||
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 chemins → restic 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 restoreavec le même mot de passe (cf.docs/runbooks-exploitation.md).
Prérequis
serveur_backupdéployé, et saserveur_backup_pubkeycorrespondant à la clé privée de la voûte. Couche agents (après les services).