Aller au contenu

Playbook de reprise d'activité

AKKO 2026.04 est livrée avec une stratégie de backup entièrement déclarative. Ce playbook documente les RTO / RPO mesurés et les commandes exactes pour restaurer chaque classe d'incident. Requis par DORA Art. 11 pour les workloads financiers.

Chaque chiffre ci-dessous est mesuré sur du matériel de référence

Vos chiffres seront différents. Relancez les exercices ci-dessous après provisioning et consignez les RTO / RPO observés dans un rapport de test signé annexé à ce document.

Périmètre

Composant stateful Mécanisme de backup Outil
PostgreSQL (Keycloak/Airflow/OM/Superset/MLflow/Polaris) Dump logique + archivage WAL CronJob pg_dumpall + Barman (optionnel)
PostgreSQL Data (fonctionnel) Dump logique + archivage WAL Idem ci-dessus
Tables Iceberg (warehouse object storage) Réplication objet + snapshots Iceberg Velero + réplication bucket object storage
Données objet object storage Réplication bucket ou mirror S3 mc mirror / Velero
Realm Keycloak + users Export JSON + dump DB API Admin + pg_dump
Catalogues Trino (dynamiques) Snapshot ConfigMap Release Helm + CM OPA Catalog Manager
Cache de requêtes ADEN + reçus Dump PostgreSQL Idem PostgreSQL ci-dessus
TSDB Prometheus / VictoriaMetrics Snapshot de volume Velero CSI snapshot
Données audit logs layer Stockage froid S3 Object Lock Native logs layer (configuré)
État Helm (releases) etcd (via Velero) Backup Velero par namespace

Cibles

Classe RTO cible RPO cible Scénario
Données critiques 2 h 1 h Corruption PostgreSQL Data / warehouse Iceberg
Control plane 4 h 4 h Indisponibilité Keycloak / OPA / catalog-manager
Observabilité 12 h 24 h Crash pod VictoriaMetrics / logs layer
Reconstruction cluster complet 24 h 4 h Cluster K8s entièrement perdu

Planning de backup

Tous les CronJobs vivent dans le namespace akko et sont pilotés par le chart :

Job Planning Rétention
akko-pg-backup (infra) 0 */4 * * * 14 j local, 90 j froid (S3)
akko-pg-data-backup (fonctionnel) 0 */2 * * * 14 j local, 180 j froid
akko-minio-replicate continu 365 j WORM
akko-keycloak-realm-export 0 3 * * * 30 j
akko-velero-ns-akko 0 1 * * * 30 j

Exercice 1 — Restaurer une seule base PostgreSQL

Scénario : quelqu'un a supprimé une table dans superset_metadata.

# 1. Arrêter le consommateur
kubectl -n akko scale deploy akko-superset --replicas=0

# 2. Récupérer le dump le plus récent depuis le stockage froid S3
aws s3 cp \
  s3://akko-backups/pg/superset_metadata_$(date +%Y%m%d)*.sql.gz \
  /tmp/restore.sql.gz

# 3. Recréer la DB + importer
kubectl -n akko exec -it akko-postgresql-0 -- \
  psql -U postgres -c "DROP DATABASE superset_metadata; CREATE DATABASE superset_metadata;"
zcat /tmp/restore.sql.gz | kubectl -n akko exec -i akko-postgresql-0 -- \
  psql -U postgres superset_metadata

# 4. Redémarrer le consommateur
kubectl -n akko scale deploy akko-superset --replicas=1

RTO mesuré : ~20 min sur matériel de référence. Notez votre chiffre ici : ____

Exercice 2 — Restaurer le cluster entier

Scénario : cluster K8s perdu (région cloud en panne).

# 1. Provisionner un nouveau cluster avec l'overlay cloud cible
bash helm/scripts/k3d-create.sh   # ou EKS / AKS / GKE / OpenShift

# 2. Installer AKKO depuis Harbor
AKKO_DOMAIN=akko.client.example AKKO_VERSION=2026.04 \
  bash helm/scripts/deploy-from-harbor.sh

# 3. Restaurer le backup Velero (inclut ressources namespace + snapshots PV)
velero restore create --from-backup akko-$(date -u +%Y%m%d) --include-namespaces akko

# 4. Rejouer les derniers dumps PostgreSQL (étape 2 de l'Exercice 1 pour chaque DB)

# 5. Repointer le DNS vers la nouvelle adresse LoadBalancer

# 6. Valider
bash tests/post-deploy/run-all.sh

RTO mesuré : ~4 h. Notez votre chiffre ici : ____

Exercice 3 — Ransomware / compromission

Scénario : un attaquant a obtenu les credentials akko-admin Keycloak et supprimé des tables.

  1. Contenir — suspendre l'identité compromise dans Keycloak et tourner ses credentials via scripts/rotate-secrets.sh.
  2. Préserver la preuve — kubectl cp les logs logs layer + reçus d'audit vers une machine hors-ligne pour forensic.
  3. Identifier — interroger logs layer sur le champ user de l'attaquant :
audit_type:* AND user:"user-compromis" AND _time:[72h ago, now]
  1. Éradiquer — supprimer les ServiceAccounts et Secrets K8s de l'attaquant.
  2. Récupérer — rejouer l'Exercice 1 / 2 selon l'ampleur. Le WORM S3 Object Lock empêche l'attaquant de toucher à la piste d'audit (mode COMPLIANCE, 365 j).
  3. Retour d'expérience — ouvrir un ADR + mettre à jour ce playbook.

Commandes de vérification

# Vérifier que les CronJobs de backup sont verts
kubectl -n akko get cronjobs -o custom-columns=NAME:.metadata.name,LASTRUN:.status.lastSuccessfulTime

# Vérifier que le dernier dump PG a moins de 4 h
kubectl -n akko exec svc/akko-postgresql -- \
  ls -l /backups/ | head

# Vérifier qu'il y a un backup Velero récent réussi
velero backup get | head -5

# Vérifier l'immutabilité de la piste d'audit (WORM)
aws s3api get-object-lock-configuration --bucket akko-audit-cold

Checklist trimestrielle

  • [ ] Lancer l'Exercice 1 sur superset_metadata et noter le RTO
  • [ ] Lancer l'Exercice 2 sur un cluster scratch et noter le RTO
  • [ ] Lancer l'Exercice 3 en tabletop avec ops + sécurité
  • [ ] Relire ce playbook, mettre à jour les chiffres mesurés
  • [ ] Sign-off par l'officier de conformité

Roadmap

  • CronJob automatique de restore-test (Sprint 44) qui monte une PG scratch, restaure le dump de la veille et reporte la durée à Prometheus → akko_dr_restore_duration_seconds.
  • Réplication Iceberg multi-région via Polaris (backlog Sprint 46).