Set-OPS-Public/wiki/Sauvegardes.md

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).
client_backup	intégration par nœud : jobs déclaratifs (dump + chemins), timer quotidien, rétention.

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

1. Lance une sauvegarde. Sur un nœud avec client_backup :

   /usr/local/sbin/setops-sauvegarder.sh
   

2. Liste les instantanés (le dépôt vit hors-nœud) :

   export RESTIC_REPOSITORY=sftp:restic@backup-01.lab.chezlepro.internal:$(hostname)
   export RESTIC_PASSWORD_FILE=/etc/setops/restic.pass
   restic snapshots
   

3. 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.)
4. 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.
• Complément 3-2-1 (offsite) : reste à faire — c'est l'Étape B (frontière publique).