Configuration des sauvegardes — guide pas à pas¶

Ce guide décrit toutes les étapes pour mettre en place la résilience SAAM, de la préparation S3 jusqu'à la vérification des backups. Il complète la vue d'ensemble dans Sauvegarde & restauration.

Règle d'or

Ne jamais utiliser le MinIO du même cluster comme seule destination de sauvegarde. Les copies DR doivent être sur un stockage externe (autre site, autre compte cloud, NAS compatible S3).

Parcours complet (résumé)¶

Étape	Action	Qui	Où dans SAAM
0	Préparer bucket(s) S3 externe(s)	Ops / cloud	Hors SAAM
1	Enregistrer le cluster (RKE2 prêt, `dns_zone` renseignée)	DataOps	Stack technique → Clusters Kubernetes
2	Créer tous les secrets DR dans le coffre	Admin cluster / org	Fiche cluster → Coffre de secrets
3	Installer le socle : Longhorn → Velero → MinIO → PostgreSQL	DataOps	Stack technique → Composants
4	Activer la politique de résilience	Admin cluster	Fiche cluster → Résilience & backups
5	Configurer le backup Postgres du control plane	Super-admin	Réglages → Backup control plane
6	Configurer l'export automatique des organisations	Super-admin	Réglages → Backup organisations
7	Vérifier jobs, objets S3, drill	Ops	Jobs + bucket S3

Étape 0 — Préparer l'infrastructure S3¶

Bucket externe¶

Créez au moins un bucket S3 hors du cluster à sauvegarder. Fournisseurs courants : Scaleway Object Storage, AWS S3, MinIO externe, NAS Synology/QNAP (mode S3).

Recommandations :

Un bucket unique avec des préfixes distincts par cluster et par couche (simple à opérer).
Ou plusieurs buckets (séparation Velero / Barman / miroir MinIO) si la politique de sécurité l'exige.
Activez le versioning sur le bucket (protection contre suppression accidentelle).
Limitez les droits IAM au strict nécessaire (PutObject, GetObject, ListBucket, DeleteObject sur le préfixe concerné).
Notez : endpoint URL, région, access key, secret key, nom du bucket.

Arborescence S3 recommandée (un bucket `saam-dr-prod`)¶

saam-dr-prod/
├── velero/                          # backups Kubernetes (préfixe Velero)
│   └── backups/…
├── barman/                          # sauvegardes CNPG (Barman Cloud)
│   └── …
├── minio-mirror/                    # miroir du lac MinIO
│   └── warehouse/…
├── etcd/
│   └── mon-cluster/                 # snapshots RKE2 + cluster-token
│       └── …
└── saam-control/
    ├── mon-cluster/
    │   └── vault-latest.enc         # coffre chiffré SAAM
    └── organisations/
        └── banque-agricole/
            ├── latest.tar.gz
            └── export-1735123456.tar.gz

Le control plane (outil SAAM) utilise en général un bucket séparé ou un préfixe dédié (saam-control/postgres/ pour Barman de saam-db).

Droits IAM minimaux (exemple)¶

Adaptez au fournisseur. Principe : une paire de clés par couche ou une clé « DR » avec accès limité au préfixe saam-dr-prod/*.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::saam-dr-prod",
      "Condition": { "StringLike": { "s3:prefix": ["velero/*", "barman/*", "minio-mirror/*", "etcd/*", "saam-control/*"] } }
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::saam-dr-prod/*"
    }
  ]
}

Étape 1 — Enregistrer le cluster¶

Connectez-vous à la console SAAM avec un compte administrateur d'organisation ou super-admin.
Menu Stack technique → Clusters Kubernetes.
Créez le cluster (assistant) ou importez un kubeconfig existant.
Vérifiez que le statut passe à ready (RKE2 opérationnel, kubeconfig valide).
Renseignez la zone DNS du cluster (dns_zone, ex. prod.client.sn) — indispensable pour les URLs des composants et le restore guidé.

Control plane

Le cluster hôte de l'outil SAAM (control-plane) n'apparaît pas dans cette liste. Son backup Postgres se configure à l'étape 5 (Réglages super-admin).

Étape 2 — Créer les secrets dans le coffre cluster¶

Accéder au coffre¶

Stack technique → Clusters Kubernetes.
Cliquez sur le cluster cible.
Descendez jusqu'à la carte Coffre de secrets.

Les secrets sont chiffrés (Fernet). Une fois enregistrés, les valeurs ne sont plus affichées en clair ; l'affichage nécessite votre mot de passe SAAM.

Ajouter ou mettre à jour un secret¶

Cliquez sur Ajouter / mettre à jour un secret.
Clé : nom exact (sensible à la casse), ex. velero_s3_access_key.
Description (optionnel) : note libre pour l'équipe.
Valeur : collez la valeur ou cliquez sur l'icône Générer (pour les passphrases).
Enregistrer.

Répétez pour chaque clé listée ci-dessous. Les jobs de résilience et les installations de composants injectent ces clés automatiquement en extravars Ansible — pas de fichier ansible/vault à maintenir à la main.

Valeurs interdites

SAAM refuse les placeholders (change_me, replace_me, todo, etc.) lors du déploiement des composants.

2.1 — Secrets Velero (couche Kubernetes / PV)¶

Obligatoires pour installer le composant Velero et activer la couche Velero dans la politique de résilience.

Clé coffre	Label catalogue	Obligatoire	Exemple	Notes
`velero_s3_access_key`	Access key bucket DR Velero	Oui	`SCWXXXXXXXX`	Clé IAM avec droits sur le préfixe Velero
`velero_s3_secret_key`	Secret key bucket DR Velero	Oui	(secret)	Jamais réaffichée après enregistrement
`velero_s3_bucket`	Bucket DR Velero	Oui	`saam-dr-prod`	Nom du bucket (sans `s3://`)
`velero_s3_endpoint`	Endpoint S3 DR Velero	Oui	`https://s3.fr-par.scw.cloud`	URL path-style du fournisseur
`velero_s3_region`	Région S3 DR Velero	Non	`fr-par`	Défaut souvent `fr-par` (Scaleway)
`velero_s3_prefix`	Préfixe objet Velero	Non	`velero`	Défaut : `velero` — objets sous `{bucket}/{prefix}/`

Procédure :

Créez les 4 clés obligatoires (+ région et préfixe si besoin).
Installez Longhorn puis Velero depuis Stack technique → Composants (Velero dépend de Longhorn).
Vérifiez le namespace velero et le schedule daily (défaut chart : 03:00 UTC).

2.2 — Secrets PostgreSQL / Barman (couche CNPG)¶

Obligatoires pour activer la couche PostgreSQL dans la politique de résilience. Utilisés par le plugin Barman Cloud (CNPG ≥ 1.30).

Clé coffre	Label catalogue	Obligatoire	Exemple	Notes
`postgresql_backup_s3_access_key`	Access key S3 DR (Barman)	Oui*	`SCWYYYYYYYY`	*Obligatoire si couche CNPG activée
`postgresql_backup_s3_secret_key`	Secret key S3 DR (Barman)	Oui*	(secret)
`postgresql_backup_s3_bucket`	Bucket S3 DR PostgreSQL	Oui*	`saam-dr-prod`	Peut être le même bucket que Velero
`postgresql_backup_s3_endpoint`	Endpoint S3 DR PostgreSQL	Oui*	`https://s3.fr-par.scw.cloud`
`postgresql_backup_s3_region`	Région S3 DR PostgreSQL	Non	`fr-par`

Ces clés sont déclarées sur le composant PostgreSQL cluster (et réutilisées par Airflow, Superset, Polaris selon le catalogue).

Procédure :

Créez les 5 clés dans le coffre.
Installez PostgreSQL cluster (opérateur CNPG) depuis les composants.
Les bases applicatives (Airflow, Superset, Polaris…) héritent du même object store Barman.

2.3 — Secrets miroir MinIO (couche lac objet)¶

Optionnels dans le catalogue MinIO, mais requis si vous activez la couche MinIO lac dans la politique de résilience.

Clé coffre	Label catalogue	Obligatoire	Exemple	Notes
`minio_dr_s3_access_key`	Access key bucket DR (miroir MinIO)	Oui*	`SCWZZZZZZZZ`	*Si couche MinIO activée
`minio_dr_s3_secret_key`	Secret key bucket DR (miroir MinIO)	Oui*	(secret)
`minio_dr_s3_bucket`	Bucket DR miroir MinIO	Oui*	`saam-dr-prod`	Préfixe miroir recommandé : `minio-mirror/`
`minio_dr_s3_endpoint`	Endpoint S3 DR miroir MinIO	Oui*	`https://s3.fr-par.scw.cloud`

Le versioning des buckets MinIO in-cluster est toujours activé ; le miroir CronJob copie vers S3 externe (planning par défaut du rôle Ansible : 0 4 * * * UTC, déclenché aussi par la politique SAAM).

Procédure :

Créez les 4 clés.
Installez MinIO depuis les composants (après Longhorn).
Complétez aussi les secrets MinIO locaux requis à l'installation : minio_root_user, minio_root_password, minio_aistor_license (voir fiche composant MinIO).

2.4 — Secrets snapshots etcd RKE2 (couche etcd)¶

Ces clés ne figurent pas dans un composant catalogue : elles se créent manuellement dans le coffre. Requises pour la couche etcd et le bouton Sync etcd DR.

Clé coffre	Obligatoire	Exemple	Notes
`etcd_snapshot_s3_endpoint`	Oui*	`https://s3.fr-par.scw.cloud`	*Si couche etcd activée
`etcd_snapshot_s3_bucket`	Oui*	`saam-dr-prod`
`etcd_snapshot_s3_access_key`	Oui*	`SCWAAAAAAAA`
`etcd_snapshot_s3_secret_key`	Oui*	(secret)
`etcd_snapshot_s3_prefix`	Non	`etcd/mon-cluster`	Défaut : `etcd/{nom_du_cluster}`

RKE2 produit des snapshots locaux sur le premier master ; SAAM les synchronise vers S3 et copie aussi le fichier cluster-token (indispensable pour restaurer sur de nouvelles VM).

Procédure :

Créez les 4 clés obligatoires (+ préfixe si vous voulez un chemin personnalisé).
Testez avec Sync etcd DR (carte Résilience) ou attendez le backup planifié.

2.5 — Passphrase coffre DR¶

Clé coffre	Obligatoire	Exemple	Notes
`vault_dr_passphrase`	Fortement recommandé	(32+ caractères aléatoires)	Chiffre le bundle `vault-latest.enc`

Sans cette passphrase, le bundle utilise la MASTER_KEY de l'instance SAAM — le restore sur une autre instance ou après perte du control plane devient impossible sans cette clé maître.

Procédure :

Cliquez Générer dans le modal secret ou utilisez un gestionnaire de mots de passe.
Documentez la passphrase hors cluster (coffre entreprise, coffre-fort) — elle sera demandée au restore guidé (étape 1).
Activez la couche Coffre SAAM dans la politique de résilience.

2.6 — Récapitulatif : ordre de création des secrets¶

Créez les secrets avant d'installer les composants qui en dépendent :

1. velero_s3_*          (4 obligatoires + region/prefix optionnels)
2. postgresql_backup_s3_* (si CNPG prévu)
3. minio_dr_s3_*        (si miroir lac prévu)
4. etcd_snapshot_s3_*   (si cluster RKE2 géré par SAAM)
5. vault_dr_passphrase  (recommandé dès le début)

Vous pouvez utiliser le filtre du coffre (ex. velero, etcd) pour vérifier qu'aucune clé ne manque.

Étape 3 — Installer le socle DR (composants)¶

Ordre obligatoire (dépendances catalogue) :

flowchart LR
  LH[Longhorn] --> VE[Velero]
  LH --> MI[MinIO]
  LH --> PG[PostgreSQL CNPG]

Ordre	Composant	Prérequis secrets
1	Longhorn	— (stockage in-cluster)
2	Velero	`velero_s3_*`
3	MinIO	`minio_root_`, licence AIStor ; `minio_dr_s3_` pour le miroir
4	PostgreSQL cluster	rôles Postgres + `postgresql_backup_s3_*` pour Barman

Installation : Stack technique → Composants → sélectionnez le cluster → installez chaque brique. SAAM valide la présence des secrets requis avant de lancer le job Ansible.

Le restore guidé réutilise le même ordre (étape « Socle » du wizard).

Étape 4 — Politique de résilience (cluster data)¶

Sur la fiche cluster, carte Résilience & backups.

4.1 — Champs principaux¶

Champ UI	Description	Valeur type
Offre SLA	`standard` = RPO 24 h / RTO 8 h ; `premium` = warm standby	Standard en premier déploiement
Politique active	Master switch du planning automatique	`ON` après validation
Planning (cron)	Minute heure jour mois jour-semaine	`30 2 * * *` = 02:30
Fuseau horaire	Fuseau d'interprétation du cron	`UTC` (recommandé) ou `Europe/Paris`
Rétention (jours)	TTL des backups Velero on-demand	`30`

4.2 — Couches à activer¶

Cochez uniquement les couches dont les secrets sont en place :

Couche	Secret(s) requis	Composant installé
etcd	`etcd_snapshot_s3_*`	RKE2 (cluster SAAM)
Velero	`velero_s3_*`	Velero
PostgreSQL	`postgresql_backup_s3_*`	CNPG + Barman
MinIO lac	`minio_dr_s3_*`	MinIO
Coffre SAAM	`vault_dr_passphrase` (recommandé)	— (export SAAM)

4.3 — Métadonnées DR (optionnel)¶

Champ	Usage
Endpoint DR (meta)	Documentation / runbook (ex. `https://s3-dr.example.com`)
Bucket DR (meta)	Référence documentaire du bucket principal
DNS bascule Premium	FQDN public pour le warm standby (`sla_tier = premium`)
Notes	Commentaires libres

4.4 — Enregistrer et premier backup¶

Cliquez Enregistrer.
Le backend évalue le cron chaque minute ; seules les couches cochées partent.
Lancez un Lancer backup manuel pour valider la chaîne complète.
Consultez l'historique des runs et le job associé (Jobs du cluster).

4.5 — Actions manuelles disponibles¶

Bouton	Action backend	Quand l'utiliser
Lancer backup	Toutes les couches cochées	Validation initiale, avant maintenance
Export coffre DR	Upload `vault-latest.enc` vers S3	Après rotation de secrets
Drill	Enchaînement de vérifications	Drill trimestriel
Sync etcd DR	`etcd_offsite` uniquement	Test snapshots etcd
Restore guidé	Wizard 3 étapes	Rebuild après sinistre

Étape 5 — Backup control plane (super-admin)¶

Réglages (menu admin) → onglet Backup control plane.

Ce S3 est indépendant du DR des clusters data. Il sert à :

sauvegarder Postgres saam-db (métadonnées SAAM + Keycloak) via Barman ;
héberger les exports d'organisations (saam-control/organisations/…).

Procédure¶

Préparez un bucket (ou préfixe) dédié, ex. s3://saam-cp-backup/saam-control/postgres.
Renseignez les champs :

Champ	Exemple	Notes
Activer	ON
Endpoint S3	`https://s3.fr-par.scw.cloud`
Chemin destination	`s3://saam-cp-backup/saam-control/postgres`	Format `s3://bucket/préfixe`
Région	`fr-par`
Rétention	`30d`	Politique Barman
Cron ScheduledBackup	`0 0 2 * * *`	Format CNPG : `s m h dom mon dow`
Access key	(clé IAM)	Laisser vide pour conserver les clés existantes
Secret key	(secret)

Enregistrez. Vérifiez les tags :
Clés configurées (vert) ;
Secret K8s synchronisé → secret saam-db-backup-s3 dans le namespace du control plane.

MASTER_KEY

En cas de perte du control plane, le restore Barman de saam-db nécessite de redéployer Helm avec la même MASTER_KEY que l'instance d'origine.

Étape 6 — Backup organisations (super-admin)¶

Réglages → onglet Backup organisations.

Prérequis

L'onglet Backup control plane doit être configuré (endpoint + clés). Les exports organisations utilisent le même S3 control plane, pas le bucket Velero d'un cluster data.

Procédure¶

Vérifiez que le backup control plane affiche Clés configurées.
Renseignez :

Champ	Défaut	Description
Activer	OFF	Active le planning automatique
Cron	`0 2 * * *`	02:00 dans le fuseau choisi
Fuseau	`UTC`
Inclure les clusters	ON	Métadonnées des clusters déclarés dans l'org
Inclure l'historique	OFF	Historique jobs / événements (plus volumineux)
Rétention copies	`14`	Nombre d'archives `export-*.tar.gz` conservées

Enregistrez.
Cliquez Lancer maintenant pour un export immédiat de toutes les organisations.

Objets produits¶

{bucket}/saam-control/organisations/{slug}/latest.tar.gz
{bucket}/saam-control/organisations/{slug}/export-{timestamp}.tar.gz

Le slug est dérivé du domaine ou du nom de l'organisation (ex. agri-com pour agri.com).

Périmètre

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

Étape 7 — Vérifications¶

7.1 — Dans la console SAAM¶

[ ] Carte Résilience : statut ok, Planning actif, pas de message Backup périmé.
[ ] Tableau des runs : dernière exécution réussie pour chaque couche activée.
[ ] Jobs du cluster : jobs cluster_backup terminés sans erreur.
[ ] Composant Velero : backups listés (API / kubectl namespace velero).

7.2 — Dans le bucket S3¶

Chemin	Couche	Fréquence attendue
`{prefix}/backups/…` ou préfixe Velero	Velero	≤ 24 h (standard)
`barman/…` ou préfixe Barman	CNPG	≤ 24 h
`minio-mirror/…`	MinIO	≤ 24 h
`etcd/{cluster}/…` + `cluster-token`	etcd	≤ 24 h
`saam-control/{cluster}/vault-latest.enc`	Coffre	À chaque backup coffre
`saam-control/organisations/…`	Orgs (CP)	Selon cron Réglages

7.3 — Drill trimestriel¶

Utilisez le bouton Drill ou suivez la checklist complète.

Dépannage rapide¶

Symptôme	Cause probable	Action
Install Velero échoue	Secrets `velero_s3_*` manquants ou placeholder	Compléter le coffre, réinstaller
Couche CNPG ignorée	`postgresql_backup_s3_*` absent	Créer les 5 clés, recocher PostgreSQL
Sync etcd DR échoue	`etcd_snapshot_s3_*` incomplet	Vérifier les 4 clés obligatoires
Export org en erreur	Backup control plane non configuré	Réglages → Backup control plane
Restore guidé : déchiffrement coffre	Mauvaise `vault_dr_passphrase`	Utiliser la passphrase documentée hors cluster
Planning inactif	`Politique active` OFF ou cron invalide	Activer + corriger l'expression cron

Suite : Sauvegarde & restauration (restore guidé, Premium, scénarios) · Scénarios de restauration

Configuration des sauvegardes — guide pas à pas¶

Parcours complet (résumé)¶

Étape 0 — Préparer l'infrastructure S3¶

Bucket externe¶

Arborescence S3 recommandée (un bucket saam-dr-prod)¶

Droits IAM minimaux (exemple)¶

Étape 1 — Enregistrer le cluster¶

Étape 2 — Créer les secrets dans le coffre cluster¶

Accéder au coffre¶

Ajouter ou mettre à jour un secret¶

2.1 — Secrets Velero (couche Kubernetes / PV)¶

2.2 — Secrets PostgreSQL / Barman (couche CNPG)¶

2.3 — Secrets miroir MinIO (couche lac objet)¶

2.4 — Secrets snapshots etcd RKE2 (couche etcd)¶

2.5 — Passphrase coffre DR¶

2.6 — Récapitulatif : ordre de création des secrets¶

Étape 3 — Installer le socle DR (composants)¶

Étape 4 — Politique de résilience (cluster data)¶

4.1 — Champs principaux¶

4.2 — Couches à activer¶

4.3 — Métadonnées DR (optionnel)¶

4.4 — Enregistrer et premier backup¶

4.5 — Actions manuelles disponibles¶

Étape 5 — Backup control plane (super-admin)¶

Procédure¶

Étape 6 — Backup organisations (super-admin)¶

Procédure¶

Objets produits¶

Étape 7 — Vérifications¶

7.1 — Dans la console SAAM¶

7.2 — Dans le bucket S3¶

7.3 — Drill trimestriel¶

Dépannage rapide¶

Arborescence S3 recommandée (un bucket `saam-dr-prod`)¶