Scénarios de restauration¶

Guide opérationnel pour les 6 cas d'incident courants sur SAAM. Chaque scénario précise les backups requis et la démarche de reprise. Pour la configuration initiale, voir Sauvegarde & restauration et le guide pas à pas.

Vocabulaire¶

Plan	Contenu
Control plane (CP)	Outil SAAM : Postgres `saam-db`, backend, Keycloak, monitoring Mimir/Loki, secrets Helm (`MASTER_KEY`…)
Data plane (DP)	Cluster(s) data : RKE2/etcd, Longhorn, Velero, MinIO (lac Iceberg), CNPG apps, Trino, Airflow…

flowchart TB
  subgraph cp [Control plane]
    SaamDB[saam-db CNPG]
    Backend[Backend SAAM]
    Keycloak
  end
  subgraph dp [Data plane]
    Etcd[etcd RKE2]
    Velero
    MinIO
    CNPG[CNPG apps]
  end
  subgraph dr [Stockage DR externe S3]
    VeleroBSL[Velero]
    Barman[Barman CNPG]
    MinIOMirror[Miroir MinIO]
    EtcdSnaps[Snapshots etcd]
    VaultEnc[Coffre chiffré]
    CpPgDump[Barman saam-db]
    OrgExport[Exports org]
  end
  Velero --> VeleroBSL
  CNPG --> Barman
  MinIO --> MinIOMirror
  Etcd --> EtcdSnaps
  SaamDB --> CpPgDump

Matrice des backups (prérequis)¶

Couche	Mécanisme	Obligatoire pour…
DP etcd	Snapshots RKE2 + `etcd_snapshot_s3_*`	Perte DP / totale
DP K8s / PV	Velero + `velero_s3_*`	Perte DP / composants / totale
DP Postgres	Barman CNPG + `postgresql_backup_s3_*`	Perte PG / corruption méta
DP lac	Versioning MinIO + `minio_dr_s3_*`	Perte MinIO / corruption lac
DP coffre	Export `vault-latest.enc`	Rebuild guidé
CP Postgres	Barman `saam-db` (Réglages → Backup control plane)	Perte CP / totale
CP méta portable	Export organisation (cron)	Perte CP (repli sans Barman)
CP `MASTER_KEY`	Coffre ops externe	Toujours — sans elle, secrets DP illisibles

1. Perte totale (CP + DP)¶

Symptôme : plus d'outil SAAM, plus de cluster(s) data.

Démarche¶

Récupérer hors bande : MASTER_KEY, mots de passe Helm, accès buckets DR, archives saam-org-export si disponibles.
Reconstruire le CP : nouveau cluster RKE2 + helm upgrade --install avec la même MASTER_KEY.
Restore CP : recovery Barman saam-db ou bootstrap admin + import des exports org.
Pour chaque cluster data : nouveau RKE2 → enregistrer dans SAAM → Restore guidé (coffre → socle → Velero + MinIO + CNPG).
Réconcilier Iceberg : objets MinIO + catalog Polaris/PG de la même fenêtre.
DNS, smoke-tests (IdP, Trino, Superset, Airflow), post-mortem.

Ordre critique : control plane d'abord, puis data plane.

2. Perte du data plane seul (CP intact)¶

Symptôme : console SAAM OK ; cluster data injoignable ou détruit.

Démarche¶

Constater (kubeconfig mort, API K8s HS).
Nouveau cluster RKE2 (ou restore etcd manuel depuis snapshots DR si sains).
Restore guidé sur le cluster enregistré :
Import coffre DR + zone DNS ;
Socle Longhorn → Velero → MinIO → PostgreSQL ;
Restore Velero + miroir MinIO inverse + recovery CNPG.
Vérifier TenantSpace et URLs ; smoke-tests.
Jobs manquants : resync depuis MinIO saam-dags si besoin.

Tip

Ne pas ré-exporter l'organisation : elle est intacte sur le control plane.

3. Perte du control plane seul (DP intact)¶

Symptôme : clusters data tournent ; UI SAAM / IdP HS.

Démarche¶

Prévoir une fenêtre de maintenance : OIDC Keycloak CP peut casser Superset/MinIO.
Reconstruire le CP (Helm) avec la même MASTER_KEY.
Restore préféré :
- A. Recovery Barman saam-db → état complet ;
- B. Sinon : bootstrap + import archives org + resync jobs depuis MinIO des clusters.
Remonter DNS (api, idp, console).
Vérifier kubeconfigs en base ; re-upload si nécessaire.

MASTER_KEY

Sans la clé d'origine, les cluster_secrets chiffrés restent illisibles même après restore Postgres.

4. Perte d'un composant stateful (DP)¶

Composant	Démarche
MinIO lac	Nouveau MinIO → miroir inverse depuis DR → versioning si delete partiel
CNPG (Airflow, Superset, Polaris)	Bootstrap recovery depuis ObjectStore Barman → redémarrer l'app
Namespaces apps (sans PV data)	Restore Velero ciblé
PV applicatif	Inclus dans Velero si non exclu ; sinon rebuild catalogue
DAGs / jobs SAAM	Meta dans MinIO `saam-dags` → resync API

Lancez des backups manuels par couche depuis Résilience & backups avant toute opération risquée.

5. Corruption des données (DP up, données incohérentes)¶

Symptôme : mauvais job, delete accidentel, ransomware logique.

Démarche¶

Geler les écritures (pause DAGs, readonly buckets si possible).
Identifier le périmètre (préfixe MinIO, table Iceberg, base CNPG).
MinIO : restaurer une version antérieure (versioning local) ou pull depuis miroir DR.
Catalog Iceberg : restore Barman PITR aligné sur les objets MinIO.
Invalider caches Trino ; smoke-tests métier.
Ne jamais écraser un backup DR sain pour « réparer ».

Pas d'UI « restore table as-of T » en V1 : procédure ops + versioning + Barman.

6. Transfert de cluster (même organisation)¶

Objectif : déplacer les charges de A vers B ; org, users et groupes inchangés.

Backups DR à jour sur A.
Provisionner B ; l'enregistrer dans la même organisation.
Restore guidé sur B (mêmes buckets DR).
Export cluster (méta SAAM) depuis A → import sur B.
Basculer DNS ; décommissionner A.

Depuis une archive organisation (saam-org-export) :

Inspecter l'archive (clusters contenus).
Importer vers le cluster cible avec include_org_objects=true si users/groupes doivent être réalignés.

Synthèse¶

Scénario	CP	DP	Méta SAAM
1 Totale	Helm + Barman CP ou import org	Restore guidé × N	Import org + coffre
2 DP seul	—	Restore guidé	Inchangé
3 CP seul	Helm + Barman CP / import org	— (déjà UP)	PG ou import
4 Composant	—	Ciblé Velero / MinIO / CNPG	Parfois resync jobs
5 Corruption	—	Versioning + PITR aligné	—
6 Transfert cluster	—	Restore physique sur B	Export / import cluster

Checklist avant incident¶

[ ] MASTER_KEY + secrets Helm CP dans un coffre externe
[ ] Barman CP activé vers S3 DR
[ ] Exports org planifiés si Barman CP absent
[ ] Sur chaque cluster data : Velero, CNPG Barman, MinIO DR, etcd offsite, coffre DR
[ ] Drill trimestriel documenté
[ ] FQDN et TTL DNS connus (bascule Premium)