Sauvegardes (3-2-1)

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Sauvegarder quoi ? Pas forcément « tout ». Si ton infra est reconstructible (par du code), les machines ne sont pas précieuses — c'est la donnée d'état (non régénérable) qui l'est.

La règle 3-2-1 : 3 copies, sur 2 supports, dont 1 hors-site. Une seule copie n'est pas une sauvegarde.

Logique vs image : logique = un export applicatif cohérent (pg_dump, slapcat) ; image = une copie brute du disque/VM. La logique est fine et portable ; l'image est grosse et rapide à restaurer.

La vérité qui fait mal : une sauvegarde jamais restaurée n'existe pas. La restauration testée est le seul critère. « Ça a tourné » ≠ « ça restaure ».

Trois propriétés d'une bonne sauvegarde : chiffrée (au repos), dédupliquée (économe), avec rétention (garder N jours/semaines, purger le reste).

② Comment Set-OPS le fait

Choix fondateur : sauvegarder la donnée (l'infra est reconstructible par le code + le template), pas les VM.

Pièce	Rôle
restic	l'outil : chiffrement côté client, déduplication, rétention.
`serveur_backup`	la cible hors-nœud (un dépôt restic par nœud) — depuis le 2026-09-01, chez l'hébergeur (`site-backup-01`), un compte Unix par écosystème.
`client_backup`	intégration par nœud : jobs déclaratifs (dump + chemins), timer quotidien, rétention — et, depuis le 2026-09-02, vérification de son propre dépôt distant.

Qui vérifie a changé. Le dépôt était le seul à voir ce qui arrivait vraiment : un nœud sait qu'il a lancé sa sauvegarde, pas qu'elle a abouti. C'était juste tant que le dépôt vivait dans l'écosystème. Depuis que les écosystèmes déposent chez leur hébergeur — qui héberge du chiffré côté client et ne peut rien juger — la vérification revient au seul qui détient la clé : le nœud lui-même. Il interroge son dépôt distant, et non le fait d'avoir lancé un timer. Une unité verte sur un dépôt vide est exactement ce qui a menti pendant un mois.

Ce qu'on protège, par tiers :

Tier 0 (vital) : les clés de la CA step-ca (/etc/step-ca) — l'ancre de confiance, irremplaçable.
Tier 1 (critique) : bases PostgreSQL (pg_dumpall), annuaire LDAP (slapcat), boîtes /var/vmail, dépôts Forgejo.

Prouvé, pas supposé : chaque tier a été restauré et vérifié (clés CA byte-identiques, les 3 bases PostgreSQL présentes, testmail retrouvé dans l'export LDAP).

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
restic	BorgBackup · Restic partout · Duplicity
dépôt hors-nœud	NFS · S3/MinIO · un NAS · un cloud souverain
3-2-1, restauration testée	principes universels — vrais pour Veeam, tar+cron, ou un cloud

Tu as appris quoi sauvegarder, la règle 3-2-1, logique vs image, et surtout restaurer-pour-prouver — pas « restic ». Ça vaut pour n'importe quel outil.

④ À toi de jouer

Lance une sauvegarde. Sur un nœud avec client_backup :
```
/usr/local/sbin/setops-sauvegarder.sh
```

Liste les instantanés (le dépôt vit hors-nœud, et hors de l'écosystème) :

# NE PAS RECOPIER UNE ADRESSE ICI : la cible est une valeur du plan, et elle a
# deja change. Le noeud la porte deja, gravee dans son propre script.
eval "$(grep -E '^export RESTIC_' /usr/local/sbin/setops-sauvegarder.sh)"
restic snapshots

Le même dépôt est interrogé chaque nuit par setops-verifier-mon-depot.sh, qui rapporte à Icinga : c'est le nœud, seul détenteur de la clé, qui juge.

Restaure — le vrai test. Restaure dans un dossier temporaire et compare :
```
restic restore latest --target /tmp/rst
diff -r /etc/step-ca /tmp/rst/etc/step-ca && echo "RESTAURATION FIDÈLE"
```
(sur infra-pki-01 ; ailleurs, compare le dump correspondant.)
Casse & répare. Supprime un fichier de donnée (une copie de test !), restaure-le depuis l'instantané, vérifie qu'il est identique. Tu viens de sentir que la valeur d'une sauvegarde est la restauration, pas la sauvegarde.

Pour aller plus loin (dépôt)

Rôles : roles/serveur_backup, roles/client_backup.
Philosophie « donnée, pas VM » + les tiers : voir le CHANGELOG (entrée sauvegardes) et les jobs en host_vars.
Le 1 hors-site de la règle 3-2-1 : make depot-hors-site VERS=<répertoire> (playbooks/maintenance/depot-hors-site.yml). Il emporte le dépôt du site — celui de l'hébergeur et ceux des locataires, puisque c'est l'hébergeur qui a pris cette promesse. La copie est opaque, et l'empreinte est prise à la source puis recalculée sur la copie : sans cela on rentre chez soi avec un répertoire, pas avec une sauvegarde. Manœuvre exécutée le 2026-09-05 — 233 fichiers, 95,7 Mo, empreintes identiques une à une.

Set-OPS

🏠 Accueil

Tu viens d'arriver

🔑 Reprendre l'écosystème

Unités d'apprentissage

Fondations

Communication

Données

Observabilité

Socle & méthode

Flotte & preuve

Opérations

Runbooks → dépôt docs/runbooks-exploitation.md

Repères

Glossaire
Référence technique → dépôt docs/