Disaster Recovery Strategien für geschäftskritische K8s-Workloads

Viele IT-Verantwortliche im Mittelstand wiegen sich in Sicherheit, weil sie “Backups machen”. Doch im Ernstfall – etwa bei einem massiven Ausfall eines Cloud-Providers, einer Ransomware-Attacke oder einem menschlichen Fehler in der Root-Config – stellen sie fest: Ein Backup ist kein Recovery-Plan.

In der Cloud-Native Welt bedeutet Disaster Recovery (DR) nicht nur das Wiederherstellen von Daten. Es bedeutet das schnelle Wiederherstellen der gesamten Applikations-Topologie.

Backup vs. Disaster Recovery: Ein entscheidender Unterschied

Ein Backup ist eine Kopie von Daten. Disaster Recovery ist das Prozess-Framework, um den Geschäftsbetrieb innerhalb einer definierten Zeit wiederherzustellen. Dabei spielen zwei Kennzahlen die Hauptrolle:

• RPO (Recovery Point Objective): Wie viel Datenverlust können wir verkraften? (z. B. “Die Daten der letzten 15 Minuten”).
• RTO (Recovery Time Objective): Wie schnell müssen wir wieder online sein? (z. B. “Innerhalb von 2 Stunden”).

Strategien für Kubernetes: Von “Backup” bis “Multi-Site”

Je nach Kritikalität Ihrer Anwendungen bieten sich drei verschiedene Architektur-Muster an:

1. Backup & Restore (The “Cold” Approach)

Der einfachste Weg. Mit Tools wie Velero sichern wir den Zustand des Clusters (YAML-Manifeste, Persistente Volumes, Secrets) in einen S3-Speicher – idealerweise bei einem anderen Provider oder On-Premises.

• Vorteil: Kostengünstig.
• Nachteil: Hohe RTO. Im Ernstfall muss ein neuer Cluster provisioniert und alle Daten zurückgespielt werden. Das kann Stunden dauern.

2. Pilot Light (The “Warm” Approach)

Ein minimaler Standby-Cluster läuft in einer zweiten Region oder einem anderen Rechenzentrum. Nur die absolut kritischen Kern-Komponenten (z. B. die Datenbank-Replikation) sind aktiv.

• Vorteil: Deutlich schnellere RTO.
• Herausforderung: Erfordert eine saubere Automatisierung via GitOps (ArgoCD/Flux), um sicherzustellen, dass die Applikations-Konfiguration in beiden Clustern identisch bleibt.

3. Multi-Site Active-Active (The “Hot” Approach)

Workloads laufen gleichzeitig in zwei Clustern. Ein globaler Loadbalancer verteilt den Traffic.

• Vorteil: Nahezu Null RTO/RPO. Fällt ein Standort aus, übernimmt der andere nahtlos.
• Technik: Hier kommen Service Meshes wie Istio oder Linkerd zum Einsatz, die Cluster-übergreifende Kommunikation ermöglichen.

Die Rolle von Velero und GitOps

Für den Mittelstand ist eine Kombination aus Velero und GitOps meist der “Sweet Spot”.

1. GitOps (Code-Ebene): Alle K8s-Manifeste liegen in Git. Wenn der Cluster stirbt, bauen wir ihn per Script neu auf und ArgoCD rollt alle Apps automatisch wieder aus.
2. Velero (Daten-Ebene): Da die Datenbank-Inhalte nicht im Git liegen, sichert Velero die Persistent Volumes(PVs) und sorgt dafür, dass die Datenstände konsistent wiederhergestellt werden.

Fazit: Testen Sie den Ernstfall (Chaos Engineering)

Ein DR-Plan, der nicht getestet wurde, funktioniert nicht. Wir empfehlen regelmäßige “Game Days”: Schalten Sie absichtlich einen Test-Cluster ab und messen Sie, wie lange Ihr Team braucht, um ihn mit den vorhandenen Tools wiederherzustellen. Erst dann wissen Sie, ob Ihre Cloud-Strategie wirklich krisenfest ist.

Technical FAQ: Disaster Recovery

Sollten Backups beim gleichen Provider liegen? Auf keinen Fall. Wenn AWS in der Region Frankfurt ein massives Problem hat, ist die Chance groß, dass auch Ihr S3-Bucket dort betroffen ist. Nutzen Sie “Cross-Provider” Backups (z. B. Backups von AWS zu einem S3 bei Wasabi, IONOS oder On-Prem).

Wie gehe ich mit Datenbanken um? Kubernetes-Snapshots (via CSI) sind gut, aber für Datenbanken oft nicht “Application Consistent”. Nutzen Sie zusätzlich native Tools der Datenbank (z. B. pg_dump oder Barman für Postgres), die von Velero mit einem Hook vor dem Backup getriggert werden.

Reicht ein Git-Repository als Recovery-Quelle? Für die Applikations-Logik ja. Aber Vorsicht: Secrets (Passwörter, Zertifikate) liegen oft verschlüsselt im Cluster oder werden extern verwaltet (z. B. HashiCorp Vault). Stellen Sie sicher, dass auch diese Tresore Teil des Recovery-Plans sind.