# 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 1. **Lance une sauvegarde.** Sur un nœud avec `client_backup` : ```bash /usr/local/sbin/setops-sauvegarder.sh ``` 2. **Liste les instantanés** (le dépôt vit hors-nœud, et hors de l'écosystème) : ```bash # 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.* 3. **Restaure — le vrai test.** Restaure dans un dossier temporaire et **compare** : ```bash 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. - Le **1 hors-site** de la règle 3-2-1 : `make depot-hors-site VERS=` (`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.