Sauvegarde et restauration

L'état de Scrydon réside dans trois magasins : PostgreSQL pour l'état relationnel, le stockage d'objets (SeaweedFS ou S3) pour les blobs, et un entrepôt OLAP (StarRocks) pour les lignes analytiques. Ce runbook couvre la sauvegarde et la restauration des trois.

Où se trouve quoi

Cadence de sauvegarde

Référence de base recommandée :

Pour les environnements réglementés, étendez la rétention selon les exigences de votre cadre de conformité.

Sauvegarde PostgreSQL

Si vous utilisez un Postgres managé (Azure Database for PostgreSQL, Amazon RDS, …), utilisez les outils PITR et snapshot du fournisseur.

Si vous utilisez le Postgres fourni avec la plateforme (déconseillé en production), le pattern recommandé est pg_basebackup pour les sauvegardes complètes + archive WAL pour le PITR. Le chart Helm documente les montages de volumes.

Sauvegarde du stockage d'objets

Si vous utilisez SeaweedFS (le stockage de blobs fourni), configurez la réplication de volumes vers un emplacement secondaire. SeaweedFS prend en charge la réplication inter-régions via la fonctionnalité de réplication du filer.

Si vous utilisez S3 / Azure Blob / GCS, la réplication inter-régions du fournisseur est directe.

Sauvegarde StarRocks

Le StarRocks fourni avec la plateforme est une image mono-pod avec un mécanisme de snapshot pour les tables individuelles. Pour la HA en production, utilisez l'opérateur Kubernetes StarRocks avec la sauvegarde native FE/BE.

Restauration — reprise après sinistre complète

Ordre des opérations pour un scénario de DR complet :

1. Provisionnez le cluster cible avec la même version Kubernetes et la même version Scrydon.
2. Restaurez PostgreSQL à partir de votre sauvegarde la plus récente (ou cible PITR). Les cinq bases de données activées (auth, agentic, analytics, cortex, ontology) doivent être restaurées ensemble — la licence, les organisations, les intégrations, les workflows et les packs d'ontologie sont liés entre elles.
3. Restaurez le stockage d'objets vers les mêmes chemins.
4. Restaurez les snapshots StarRocks.
5. Appliquez le chart Helm en pointant vers les magasins restaurés.
6. Aucune étape de réapplication de licence. La licence réside dans la ligne platform_config de la base de données auth restaurée — dès que Postgres revient, api-platform la lit à la prochaine requête. Si vous devez faire tourner la licence après la restauration, utilisez Paramètres → Licence → Mettre à jour la licence dans l'interface (voir Rotation de licence).
7. Validez en vous connectant et en confirmant que les workflows, tables et bases de connaissances sont visibles.

Clé maître crypto Dapr

Le composant crypto Dapr chiffre chaque valeur secrète écrite par la plateforme (secrets client OAuth, clés API vendeur, variables d'environnement chiffrées transmises aux fournisseurs d'intégration) avant qu'elle n'atterrisse dans Postgres. La clé de chiffrement réside dans un Secret Kubernetes nommé master-key dans le namespace de la release Scrydon.

Le chart génère automatiquement cette clé lors d'une nouvelle installation via la fonction Helm lookup — mais elle ne fait jamais partie d'une release Helm ultérieure, ce qui signifie qu'un cycle helm uninstall + helm install de routine, ou toute restauration réappliquant le chart sur un namespace vierge, générera une nouvelle clé. Toutes les lignes de secrets chiffrés dans le Postgres restauré seront alors irrécupérables.

Sauvegardez le Secret hors-bande et restaurez-le avant d'appliquer le chart :

# Capture the key into a YAML file (run this on the source cluster).
kubectl get secret master-key -n scrydon-platform -o yaml \
  | grep -v '^\s*resourceVersion\|^\s*uid\|^\s*creationTimestamp' \
  > master-key.backup.yaml

# Store master-key.backup.yaml off-cluster — encrypted at rest. Treat it
# with the same protection class as your Postgres backups.

# Restoring on the target cluster (BEFORE running helm install):
kubectl apply -f master-key.backup.yaml -n scrydon-platform

Alternatives si votre équipe utilise déjà l'un de ces outils :

• Sealed Secrets — scellez le Secret master-key avec la clé du contrôleur du cluster ; le fichier scellé peut être commité en toute sécurité. Réappliquez-le lors d'une reprise après sinistre avant le chart.
• External Secrets Operator — sourcez master-key.key depuis votre gestionnaire de clés cloud (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault). Le chemin de génération automatique via lookup du chart n'écrasera pas un Secret portant déjà les annotations de propriété Helm.
• Snapshots etcd — capture chaque Secret Kubernetes, y compris master-key. Utile pour une DR de cluster complet ; moins utile pour une restauration inter-cluster.

Correspondance conformité. ISO 27001:2022 A.5.16 / A.8.24 — la gestion des clés cryptographiques exige une procédure documentée de sauvegarde, rotation et récupération pour toute clé protégeant des données de production. La procédure de rotation de master-key est couverte dans l'ADR Dapr interne ; pour les besoins des clients, traitez cette sauvegarde comme un prérequis impératif à une restauration PostgreSQL opérationnelle.

Restauration — magasin unique

Si vous n'avez besoin de restaurer qu'un seul magasin (ex. : un blob de base de connaissances corrompu), effectuez la restauration ciblée sur ce magasin. Les autres magasins restent actifs.

Pour PostgreSQL, la restauration d'une seule table nécessite un dump logique ciblant spécifiquement cette table (pg_dump -t).

Vérification d'une sauvegarde

Une sauvegarde qui n'a pas été restaurée n'est pas une sauvegarde. Réalisez un exercice mensuel :

1. Restaurez le dump PostgreSQL de la veille dans un cluster de test.
2. Connectez-vous avec un compte administrateur connu.
3. Ouvrez un workflow, un document de base de connaissances et une table gérée.
4. Confirmez que le journal d'audit affiche les événements de la veille.
5. Détruisez le cluster de test.

En cas d'échec à l'une des étapes, escaladez immédiatement — une sauvegarde qui échoue silencieusement est un risque opérationnel avéré.

Ressources associées

• Runbook de mise à jour — la restauration est l'un des chemins de rollback.
• Migrations de base de données — aspects liés au schéma lors de la restauration.
• Licences — réapplication de la licence après restauration.