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

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

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

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

Set-OPS

🏠 Accueil

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/