Backup und Wiederherstellung

Was ein MSSP sichert, wie oft und wie wiederhergestellt wird. SocTalk hält den Zustand in drei Schichten; jede hat ihren eigenen Backup- und Wiederherstellungspfad.

Diese Seite baut auf Täglicher Betrieb, Datenbank-Wiederherstellung auf, wo dieselbe Prozedur auf Runbook-Ebene dokumentiert ist. Nutze diese Seite, um die Strategie zu planen; nutze die Betriebsseite für die konkreten Handgriffe.

Was zu sichern ist

1. Postgres (die Control Plane)

soctalk-system-postgres-0 enthält:

• Mandanten-Zeilen + Lebenszyklus-Ereignisse
• Benutzer, Sitzungen, Rollen
• Untersuchungen, Fälle, Runs, Proposals
• Einstellungen (LLM, Integrationen, Branding)
• Append-only audit_log und event-sourced case_events
• Outbox-Zeilen, die auf die Verarbeitung durch den Executor warten

Verlusttoleranz: null. Ein verlorenes Postgres = verlorene Audit-Historie, keine wiederherstellbaren Untersuchungen.

2. Kubernetes Secrets in soctalk-system

Secret (Chart-gerenderter Name)	Was darin enthalten ist
soctalk-system-llm-api-key	LLM-Provider-API-Key (installationsweiter Standard)
soctalk-system-bootstrap-admin	Initiale Admin-E-Mail + Passwort (falls install.bootstrapAdmin.password in den Values gesetzt)
soctalk-system-jwt-signing-key	Signaturschlüssel für Sitzungs-Token
soctalk-system-adapter-signing-key	Signaturschlüssel für Adapter-Token
soctalk-system-postgres-admin-creds	Postgres-soctalk_admin-Anmeldedaten (Migrationen)
soctalk-system-postgres-app-creds	Postgres-soctalk_app-Anmeldedaten (Laufzeit)
soctalk-system-postgres-mssp-creds	Postgres-soctalk_mssp-Anmeldedaten (mandantenübergreifende Abfragen)
soctalk-slack-creds	Slack-Token (per Env bereitgestellt; nicht Chart-gerendert)
soctalk-thehive-creds	TheHive-API-Key (per Env bereitgestellt)
soctalk-cortex-creds	Cortex-API-Key (per Env bereitgestellt)

Ein neu generierter Satz von Secrets ist wiederherstellbar, aber laufende Sitzungen brechen ab und Integrations-Anmeldedaten müssen erneut eingefügt werden.

3. Mandantenspezifische PVCs

Für jeden tenant-<slug>-Namespace:

PVC	Was darin enthalten ist
wazuh-indexer-data	Gesamte Wazuh-Warnungs- und Ereignishistorie
wazuh-manager-data	Wazuh-Agent-Registrierungen + Manager-Zustand
cortex-data	Cortex Elasticsearch (falls Cortex aktiviert)
thehive-data	TheHive Cassandra (falls TheHive aktiviert)

Mandanten mit poc-Profil verwenden local-path, das keine echte Persistenzgarantie bietet: ein Node-Neustart kann Daten verlieren. Mandanten mit persistent-Profil verwenden die StorageClass, die die Installation als Standard markiert; sichere sie gemäß der Dokumentation dieses Provisioners.

Frequenz

Schicht	Empfohlene Frequenz	Aufbewahrung
Logisches Postgres-Backup (pg_dump)	täglich	30 Tage
Postgres-WAL-Archivierung	kontinuierlich	7 Tage
Snapshot der Kubernetes Secrets	wöchentlich + bei jeder Rotation	90 Tage
Mandantenspezifische PVCs	passend zum SLA deines Kunden (typischerweise täglich bei Compliance-Arbeit)	pro Vertrag

Compliance-Kunden (PCI, HIPAA, SOC 2) erfordern oft längere Aufbewahrung. Behandle die obigen Werte als Untergrenze.

Postgres-Backup

pg_dump (logisch)

Läuft gegen die aktive Datenbank, ohne Ausfallzeit. Langsamere Wiederherstellung als ein physisches Backup, komprimiert aber gut und ist portabel.

kubectl -n soctalk-system exec soctalk-system-postgres-0 -- \
  pg_dump -U soctalk_app -d soctalk -Fc -Z 9 \
  > soctalk-$(date +%Y%m%d).pgdump

Leite die Ausgabe an deinen üblichen Offsite-Speicher weiter (S3, GCS, Azure Blob).

WAL-Archivierung (Point-in-Time)

In diesem Release nicht über das Chart verdrahtet. Das soctalk-system-Chart stellt keinen postgres.archiveCommand-Value bereit, daher erfordert PITR ein Postgres-Deployment außerhalb des im Chart gebündelten StatefulSets. Zwei Wege:

1. Postgres extern betreiben (verwaltetes RDS / Cloud SQL / Azure Database for PostgreSQL). Konfiguriere WAL-Archivierung / PITR gemäß der Dokumentation des Providers. Das Chart auf ein externes Postgres zeigen zu lassen, ist in V1 nicht über die Values verdrahtet: das Chart codiert die Verbindungsdetails des gebündelten StatefulSets fest in die Rollen-Anmeldedaten-Secrets. Heute bedeutet das entweder, ein eigenes Helm-Overlay zu betreiben, das die DATABASE_URL-Env des API-Deployments patcht, oder soctalk-system-postgres-app-creds / -mssp-creds / -admin-creds nach der Installation zu modifizieren. Ein postgres.external-Values-Regler steht auf der Roadmap.
2. Sidecar-Archiver in deinem eigenen Helm-Overlay (z. B. spilo oder wal-g als Sidecar). Außerhalb des Umfangs des Charts; läuft als separates Deployment, das WAL an Objektspeicher streamt.

In jedem Fall bleibt die SocTalk-Seite unverändert, die Data Plane behandelt Postgres als externe Abhängigkeit. Die Verdrahtung eines Chart-seitigen archiveCommand ist für ein zukünftiges Release vorgemerkt.

Wiederherstellung (Postgres)

Siehe das Runbook. Zusammenfassung:

1. Skaliere die API auf null, damit nichts schreibt (das V1-Chart bündelt den Orchestrator in den API-Pod, ein Deployment).
2. pg_restore den Dump (erst die DB bereinigen).
3. Bei Verwendung von WAL: WAL bis zum gewünschten Point-in-Time wiedereinspielen.
4. Skaliere die API wieder hoch.

Nach der Wiederherstellung kann der API-Pod (der den Orchestrator im V1-Chart einbettet) einen Anstoß benötigen, um ausstehende Runs erneut aufzunehmen:

kubectl -n soctalk-system rollout restart deploy soctalk-system-api

Secrets-Backup

K8s Secrets sind wegen des Geheimnismaterials mühsam sicher zu sichern. Zwei Muster:

Sealed Secrets (empfohlen)

Installiere Bitnami sealed-secrets einmal pro Cluster. Wandle deine Secrets in SealedSecret-Ressourcen um; committe diese nach git. Der Controller des Clusters entschlüsselt sie zur Installationszeit. Der Verlust eines Secrets ist aus git wiederherstellbar.

Velero mit restic / kopia

Velero sichert Kubernetes-Ressourcen (einschließlich Secrets) sowie PVCs in Objektspeicher. Verwende den in-tree CSI-Snapshotter für PVCs und Standard-Ressourcen-Backup für Secrets.

velero backup create soctalk-system-daily \
  --include-namespaces soctalk-system \
  --snapshot-volumes \
  --schedule "0 2 * * *"

Mandantenspezifisches PVC-Backup

Mandanten mit persistent-Profil verwenden eine echte StorageClass; nutze die Snapshot-Tools dieses Provisioners:

• Longhorn: integrierte geplante Backups nach S3
• Rook/Ceph: RBD-Snapshots oder cephfs-mirror
• CSI-Cloud-Volumes (EBS/Persistent Disk/Azure Disk): native Snapshot-APIs

Für Velero-Nutzer deckt velero backup create tenant-<slug>-daily --include-namespaces tenant-<slug> --snapshot-volumes sowohl die PVCs als auch die K8s-Objekte in einem Durchgang ab.

Mandantenspezifische Wiederherstellung

1. Stilllege den bestehenden Mandanten (falls vorhanden), dies löscht den Namespace.
2. Stelle die PVCs in einem frischen Namespace aus dem Snapshot wieder her.
3. Onboarde einen Mandanten mit demselben Slug und Profil über POST /api/mssp/tenants/onboard: die Provisionierung ist idempotent auf dem Namespace, sodass die Helm-Installation die wiederhergestellten PVCs übernimmt.
4. Prüfe, ob Wazuh die bestehenden Agents sieht (keine erneute Registrierung nötig, wenn die PVC-Wiederherstellung sauber war).

Wenn nur die Data Plane beschädigt ist (nicht die SocTalk-Control-Plane), ist der einfachere Weg helm rollback tenant-<slug>, gefolgt von einer In-Place-Wiederherstellung der PVCs.

Wiederherstellungsübung

Führe vierteljährlich eine Wiederherstellungsübung durch. Wähle einen Non-Prod-Cluster oder einen vorübergehend stillgelegten Mandanten. Zeitlich auf 4 h begrenzen. Dokumentiere, was fehlgeschlagen ist, und aktualisiere diese Seite.

Häufige Fehler, die die Übung aufdeckt:

• WAL-Lücke (die Archivierung ist während eines Node-Ausfalls zurückgefallen)
• Secrets, die seit dem letzten Backup rotiert wurden
• StorageClass-Fehlanpassung zwischen Cluster und Snapshot
• Netzwerkrichtlinie, die den wiederhergestellten Pod daran hindert, das neue Postgres zu erreichen

Was hier nicht abgedeckt ist

• Cluster-weite Disaster Recovery (Ausfall von Control-Plane-Nodes usw.), das ist Kubernetes-Betrieb, nicht SocTalk-spezifisch. Siehe die Dokumentation deiner Distribution.
• Wiederherstellung von LLM-Provider-Anmeldedaten, außerhalb des Umfangs; verwalte sie mit deinem normalen Runbook zur Secret-Rotation.
• Backups von Kunden-Endpunkten, Verantwortung des Kunden, nicht des MSSP.