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".
- 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.
- 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.