Set-OPS-Public/wiki/Sauvegardes.md
Daniel Allaire 5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
documentation : la tournee des 74 documents, parce qu un balayage ne lit pas
La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-06 16:18:23 -04:00

104 lines
5.1 KiB
Markdown

# 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=<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.