Sauvegarde & restauration¶

Guide de configuration exhaustif

Pour toutes les étapes (préparation S3, création de chaque secret dans le coffre, ordre d'installation, politique de résilience, backup control plane / organisations, vérifications), suivez le Guide pas à pas — configuration des sauvegardes.

La haute disponibilité (réplicas Longhorn, erasure coding MinIO, réplicas CNPG) protège contre une panne de nœud — pas contre la perte du cluster entier, une corruption logique ou un ransomware. Les sauvegardes SAAM visent un plan de reprise (DR) avec copies hors cluster, sur un stockage S3 externe (autre site, autre compte, NAS compatible S3).

Règle d'or

Ne jamais utiliser le MinIO du même cluster comme seule destination de sauvegarde. Les buckets DR (Velero, Barman, miroir MinIO, snapshots etcd, coffre chiffré) doivent être externes au cluster sauvegardé.

Ce que couvre SAAM¶

Périmètre	Contenu sauvegardé	Où configurer
Cluster data	etcd, PV Kubernetes (Velero), Postgres apps (Barman CNPG), lac MinIO (miroir + versioning), coffre secrets SAAM	Page cluster → Résilience & backups
Control plane	Base Postgres `saam-db` (métadonnées SAAM + Keycloak)	Réglages → Backup control plane (super-admin)
Organisation	Métadonnées portables (users, groupes, clusters déclarés, politiques…)	Réglages → Backup organisations (super-admin)

Le cluster control-plane (hôte de l'outil SAAM) n'apparaît pas dans les listes data : il est visible en Monitoring. Son backup Postgres se configure séparément du DR des clusters data.

RPO cible (Niveau 1) : ≤ 24 h. RTO : quelques heures (équipe ops).

Configurer les backups d'un cluster data¶

Voir le guide pas à pas complet (étapes 0 à 7). Résumé :

Prérequis : secrets DR dans le coffre¶

Avant d'activer les couches, renseignez les clés dans le coffre du cluster (Stack technique → Clusters Kubernetes → fiche cluster → Coffre de secrets) :

Famille de clés	Usage	Détail
`velero_s3_*` (+ `region`, `prefix`)	Sauvegarde Kubernetes / PV (Velero)	§ 2.1
`postgresql_backup_s3_*`	Barman CNPG (Airflow, Superset, Polaris…)	§ 2.2
`minio_dr_s3_*`	Miroir du lac MinIO vers S3 externe	§ 2.3
`etcd_snapshot_s3_*`	Snapshots etcd RKE2 hors cluster	§ 2.4
`vault_dr_passphrase`	Chiffrement du bundle coffre exporté	§ 2.5

Le composant catalogue Velero doit être installé pour la couche Kubernetes. L'opérateur CloudNativePG 1.30+ et le plugin Barman Cloud sont requis pour Postgres.

Politique de résilience (UI)¶

Ouvrez Stack technique → Clusters Kubernetes et sélectionnez le cluster.
Carte Résilience & backups.
Activez la politique et cochez les couches souhaitées :

Couche	Mécanisme	Quand l'activer
etcd	Snapshots RKE2 + sync vers S3	Cluster installé par SAAM (RKE2)
Velero	Backup namespaces / PV vers S3	Socle Longhorn + Velero installés
CNPG	Barman Cloud → S3	Postgres apps avec credentials DR
MinIO	Versioning buckets + miroir CronJob	Lac Iceberg / stockage objet
Coffre	Export chiffré `vault-latest.enc` vers S3	Rebuild guidé prévu

Définissez le planning (schedule_cron, fuseau UTC) et la rétention (retention_days pour Velero).
Enregistrez. Le backend SAAM exécute le planning chaque minute ; seules les couches cochées partent. enabled=false coupe le planning automatique (les boutons manuels restent disponibles).

Sauvegardes manuelles¶

Depuis la même carte, lancez un backup à la demande par couche (etcd, Velero, CNPG, miroir MinIO, export coffre). Utile avant une maintenance ou pour valider la chaîne DR.

Zone DNS¶

Le champ zone DNS du cluster (dns_zone) conditionne les hôtes des composants (minio.<zone>, trino.<zone>, …). Renseignez-le à la création ou à l'import — indispensable pour un rebuild guidé cohérent.

Restore guidé (cluster data)¶

Disponible sur un cluster enregistré avec RKE2 prêt (kubeconfig valide). Stack technique → cluster → Résilience → Restore guidé — assistant en 3 étapes :

Étape 1 — Coffre DR¶

Importez le fichier vault-latest.enc (exporté lors des backups coffre), la passphrase et la zone DNS. SAAM restaure les secrets du cluster dans le coffre local.

Étape 2 — Socle¶

Installez en chaîne les composants de base : Longhorn → Velero → MinIO → PostgreSQL (CNPG), avec les values Helm ajustables si besoin.

Étape 3 — Restauration des données¶

Choisissez le backup Velero à restaurer. SAAM enchaîne :

restore Velero (PV / namespaces) ;
miroir MinIO inverse depuis le bucket DR ;
recovery CNPG depuis l'object store Barman (même fenêtre temporelle que MinIO).

Iceberg / Polaris

Restaurez toujours les objets MinIO et le catalogue (Polaris / Postgres) de la même fenêtre de backup. Un décalage entre le lac et les métadonnées casse la cohérence Iceberg.

Backup du control plane (super-admin)¶

Réglages → Backup control plane configure le Barman de la base saam-db (Postgres CNPG de l'outil SAAM) vers un S3 dédié, distinct du DR Velero/CNPG des clusters data.

Paramètre	Description
Endpoint S3	URL du stockage objet (ex. Scaleway, AWS, MinIO externe)
Chemin destination	Préfixe bucket (`s3://…`)
Région	Région S3
Planning	CRON (défaut : 02:00 UTC)
Rétention	Politique Barman (ex. `30d`)

À activer dès la mise en production. En cas de perte du control plane, le recovery saam-db depuis Barman restaure orgs, users, secrets chiffrés et politiques — à condition de redéployer Helm avec la même MASTER_KEY.

Backup des organisations (super-admin)¶

Réglages → Backup organisations exporte périodiquement les métadonnées de chaque organisation vers le S3 du control plane (mêmes credentials que l'onglet Backup control plane — pas le bucket Velero d'un cluster data).

Objets : saam-control/organisations/{slug}/latest.tar.gz (+ historique horodaté).
Lancer maintenant : export immédiat.
Chiffrement : clé maître locale (MASTER_KEY) — réimport sur cette instance SAAM.

Procédure détaillée : § Étape 6 du guide de configuration.

Ce que l'export org ne contient pas

L'export organisation sauve la métadonnée control-plane (users, groupes, clusters déclarés, tenant_spaces, politiques…). Il ne remplace pas le lac MinIO / Iceberg : le data plane se restaure via Velero + miroir MinIO + Barman CNPG.

Export / import coffre DR¶

Export automatique : à chaque backup (si couche coffre active), CRON horaire, bouton Export coffre DR, et après modification d'un secret.
Emplacement S3 : {bucket}/saam-control/{cluster_name}/vault-latest.enc
Indispensable pour le rebuild guidé sans ressaisir manuellement des dizaines de secrets.

Niveau Premium — warm standby¶

Pour un RPO ≤ 1 h et RTO ≤ 2 h, configurez dans la politique de résilience :

sla_tier = premium
standby_cluster_id → cluster B pré-installé (Velero + MinIO + CNPG)
standby_dns_target → FQDN public à basculer

Procédure de bascule : stopper les écritures sur A → vérifier la réplication DR → promote sur B si besoin → bascule DNS (TTL bas, 60–300 s) → mettre à jour les URLs dans SAAM.

Drill trimestriel (checklist)¶

[ ] Backup Velero on-demand OK
[ ] Miroir MinIO DR exécuté (< 24 h)
[ ] Snapshot etcd présent hors cluster
[ ] Backup CNPG présent (credentials DR renseignés)
[ ] Export coffre DR récent
[ ] Restore Velero test dans un namespace / cluster lab
[ ] MASTER_KEY et secrets Helm CP documentés hors cluster
[ ] Temps mesuré vs RTO annoncé + compte-rendu partagé

Transfert de cluster (sans changer d'organisation)¶

Pour migrer les charges du cluster A vers B dans la même organisation :

Backups DR à jour sur A.
Provisionner B (RKE2) et l'enregistrer dans la même organisation.
Restore guidé sur B (mêmes buckets DR).
Export / import cluster (méta SAAM uniquement, sans users/org) depuis la console ou l'API.
Basculer le DNS ; décommissionner A après smoke-tests.

Voir le détail des scénarios dans Scénarios de restauration.

Prérequis cluster : Provisionner un cluster · Composants DR : Installer les composants (Velero, Longhorn, MinIO, PostgreSQL)