Disaster Recovery für Plattform-Infrastruktur

Lernziele

Nach dieser Lektion kannst du RTO und RPO sauber definieren und für einzelne Plattform-Komponenten getrennt festlegen, weißt, welcher Zustand in einer GitOps-Plattform überhaupt gesichert werden muss, und kannst Backup-Strategien gegen Multi-Region-Failover abwägen. Du verstehst, warum ein ungetestetes Backup kein Backup ist, und kannst einen Restore-Test als Game Day konzipieren.

Das Problem: „Wir haben doch GitOps” reicht nicht

Die verbreitetste DR-Illusion in Plattform-Teams klingt plausibel: Der gesamte Zielzustand liegt in Git (Lektion 25), also können wir jeden Cluster jederzeit neu bauen — wozu Backups? Der Satz ist halb richtig, und die falsche Hälfte tut weh.

Richtig ist: Deklarative Konfiguration, Helm-Releases, Policies, die Tenant-Definitionen — all das ist über Git reproduzierbar, und ein Cluster-Rebuild aus dem Bootstrap-Repo (Lektion 26) ist tatsächlich die robusteste Recovery-Strategie für die Konfigurationsebene. Falsch ist die stillschweigende Annahme, die Plattform sei zustandslos. Sie ist es nie. Zustand versteckt sich an mindestens fünf Stellen: PersistentVolumes der Workloads und der Plattform-Dienste selbst (interne PostgreSQL-Instanzen, Prometheus-Langzeitdaten), Secrets, die nie in Git lagen, sondern im External-Secrets-Backend oder Vault (Lektion 34), die Container-Registry mit Images, deren Quell-Pipelines es vielleicht nicht mehr gibt, CI/CD-Historie und Artefakte, und schließlich Ressourcen, die Controller zur Laufzeit erzeugt haben und die in keinem Repo stehen — Zertifikate, dynamisch provisionierte Cloud-Ressourcen, Let’s-Encrypt-Konten.

Die erste DR-Aufgabe ist deshalb eine Inventur: Was ist aus Git reproduzierbar, was ist echter Zustand? Alles in der zweiten Kategorie braucht eine Backup-Antwort.

RTO und RPO — pro Komponente, nicht pro Plattform

RTO (Recovery Time Objective) ist die maximal tolerierte Wiederherstellungszeit, RPO (Recovery Point Objective) der maximal tolerierte Datenverlust, gemessen in Zeit. Der häufigste Fehler ist, beide Werte einmal für „die Plattform” festzulegen. Sinnvoll wird es erst pro Komponente, denn die Anforderungen unterscheiden sich um Größenordnungen:

• Registry: RTO kurz (ohne Images keine Deployments und keine Pod-Restarts auf neuen Nodes), RPO moderat — Images lassen sich notfalls neu bauen.
• Git-Server (falls selbst betrieben): RTO und RPO beide kritisch, denn er ist die Quelle für alles andere. Deshalb betreiben viele Teams genau diese Komponente bewusst als Managed Service.
• Observability-Daten: RTO moderat, RPO großzügig — der Verlust von Metrik-Historie ist ärgerlich, aber kein Geschäftsausfall.
• Secrets-Backend: RTO sehr kurz, denn ohne Secrets startet fast nichts; RPO nahe null.

Aus dieser Tabelle ergibt sich die Recovery-Reihenfolge fast von selbst — und sie gehört ins DR-Runbook: erst Identity und Secrets, dann Registry, dann GitOps-Controller, der den Rest zieht. Wer die Reihenfolge im Ernstfall improvisiert, verliert Stunden an zirkulären Abhängigkeiten („der Restore-Job braucht ein Image aus der Registry, die wir gerade wiederherstellen”).

Backup-Strategien: Velero, etcd und das 3-2-1-Prinzip

Für Kubernetes-Ressourcen plus PersistentVolumes ist Velero das Standardwerkzeug: Es sichert API-Objekte selektiv (per Namespace oder Label) in einen Objektspeicher und Volumes per Snapshot oder Dateikopie, und es kann nach Zeitplan laufen. Wichtig ist die Abgrenzung zum etcd-Backup: Ein etcd-Snapshot sichert den kompletten Cluster-Zustand in einem Stück, taugt aber nur für die Wiederherstellung desselben Clusters in derselben Version — für selektive Restores („nur den Namespace von Team A”) oder die Migration auf einen neuen Cluster ist er ungeeignet. In Managed-Kubernetes-Umgebungen kommst du an etcd ohnehin nicht heran; dort ist Velero plus Git die realistische Kombination.

Unabhängig vom Werkzeug gilt das 3-2-1-Prinzip: drei Kopien, zwei verschiedene Medien bzw. Systeme, eine außerhalb der primären Umgebung. Für Plattformen heißt „außerhalb” konkret: andere Region und anderes Sicherheitsdomäne — ein Backup, das mit denselben Credentials löschbar ist wie das Original, schützt nicht gegen Ransomware oder einen kompromittierten Admin-Account. Objektspeicher mit Object Lock (Immutability) ist hier der entscheidende Hebel.

Und die unbequemste Regel zuletzt: Ein Backup, dessen Restore nie geübt wurde, ist eine Hoffnung, kein Backup. Restore-Tests gehören als wiederkehrender Termin in den Betriebskalender, nicht als Vorsatz ins Wiki.

Multi-Region: Failover ist eine Architektur, kein Knopf

Wenn das RTO einer Komponente unter dem liegt, was Backup-Restore liefern kann, bleibt nur Redundanz über Regionen — mit steil steigenden Kosten pro Stufe:

• Backup & Restore (RTO Stunden bis Tage): billigste Stufe, für die meisten internen Plattformen ausreichend.
• Pilot Light / Warm Standby (RTO Minuten bis Stunden): In der zweiten Region läuft ein minimaler Cluster, der per GitOps denselben Stand zieht; im Ernstfall wird skaliert und DNS umgeschwenkt. Für Plattformen attraktiv, weil GitOps das Synchronhalten fast geschenkt liefert — repliziert werden muss „nur” der echte Zustand: Registry-Replikation, Datenbank-Replikate, Secrets-Backend mit DR-Replica.
• Active-Active (RTO Sekunden bis Minuten): beide Regionen bedienen Last. Klingt nach dem Ideal, importiert aber die schwierigen Probleme verteilter Systeme in die Plattform selbst — konsistente Datenhaltung über Regionen, Split-Brain-Szenarien, doppelte Betriebskomplexität. Für eine interne Developer Platform ist Active-Active selten gerechtfertigt; das Geld ist in getesteten Restores fast immer besser angelegt.

Im Interview punktest du, wenn du diese Stufen mit den Kosten verbindest und explizit sagst: Die Stufe wählt das Business über RTO/RPO-Anforderungen, nicht das Platform-Team über Technikbegeisterung. Multi-Cluster-Grundlagen dazu hattest du in Lektion 10.

Praxis

Führe einen Mini-Game-Day im Lab durch (kind oder ein Test-Cluster):

1. Installiere eine Beispiel-Anwendung mit PVC und schreibe eine Datei hinein:

kubectl create ns dr-test
kubectl -n dr-test create deploy web --image=nginx
kubectl -n dr-test exec deploy/web -- sh -c 'echo "wichtig" > /tmp/daten.txt'

2. Installiere Velero mit einem lokalen Objektspeicher (z. B. MinIO) nach der offiziellen Anleitung und erstelle ein Backup: velero backup create dr-test-backup --include-namespaces dr-test.
3. Simuliere das Desaster: kubectl delete ns dr-test.
4. Stelle wieder her: velero restore create --from-backup dr-test-backup und prüfe, was zurückkam — und was nicht (Tipp: der Inhalt von /tmp liegt im Container-Dateisystem, nicht im PVC; genau solche Überraschungen soll der Test finden).
5. Stoppe die Zeit von Schritt 3 bis „Anwendung antwortet wieder” — das ist dein gemessenes RTO, und es ist fast immer länger als geschätzt.

Dokumentiere die drei größten Überraschungen. Das ist der eigentliche Ertrag der Übung.

Typische Stolperfallen

Backup vorhanden, Restore-Pfad unklar: Das Backup-Tool läuft seit Monaten grün, aber niemand weiß, in welcher Reihenfolge Secrets, Registry und Controller zurückkommen müssen. Die Recovery-Reihenfolge gehört explizit ins Runbook.

Backups in derselben Sicherheitsdomäne: Gleiche Cloud-Credentials, gleiche Region, kein Object Lock — ein Angreifer oder ein fehlerhafter Cleanup-Job löscht Original und Backup zusammen.

etcd-Snapshot als Universalantwort: Er hilft nicht bei selektiven Restores, nicht bei Cluster-Migrationen und gar nicht in Managed-Umgebungen ohne etcd-Zugriff.

RTO/RPO als Plattform-Pauschale: Ohne Differenzierung pro Komponente bezahlst du entweder überall den teuersten Schutz oder bist an der kritischsten Stelle unterversichert.

Interview-Vorbereitung

Die Standardfrage „Wie sieht deine DR-Strategie für eine Kubernetes-Plattform aus?” beantwortest du in dieser Reihenfolge: Zustands-Inventur (was kommt aus Git, was ist echter Zustand) → RTO/RPO pro Komponente mit Recovery-Reihenfolge → Werkzeuge (Velero für Ressourcen und Volumes, Git für Konfiguration, Replikation für Registry/Secrets) → Teststrategie (regelmäßige Restore-Übungen, gemessenes statt geschätztes RTO).

Typische Follow-ups:

• „Unterschied RTO und RPO?” — RTO: wie lange darf die Wiederherstellung dauern; RPO: wie viel Datenverlust (in Zeit) ist tolerierbar. Zwei unabhängige Stellschrauben mit unabhängigen Kosten.
• „Reicht GitOps als DR-Strategie?” — Für Konfiguration ja, für Zustand nein: PVs, Secrets, Registry und Laufzeit-Ressourcen brauchen eigene Antworten.
• „Velero oder etcd-Backup?” — Velero für selektive Restores und Migrationen; etcd-Snapshot nur für Same-Cluster-Recovery und in Managed-Setups meist gar nicht verfügbar.
• „Wann Active-Active?” — Nur wenn das Business ein RTO im Sekunden-/Minutenbereich wirklich bezahlt; sonst Warm Standby oder getestetes Backup-Restore.

Zusammenfassung

DR für Plattformen beginnt mit der Inventur: Git reproduziert Konfiguration, aber PersistentVolumes, Secrets, Registry und Laufzeit-Zustand brauchen Backups — nach dem 3-2-1-Prinzip, immutabel und in einer anderen Sicherheitsdomäne. RTO und RPO legst du pro Komponente fest und leitest daraus die Recovery-Reihenfolge ab. Multi-Region-Failover kaufst du in Stufen (Restore → Warm Standby → Active-Active), und jede Stufe muss das Business über seine Anforderungen rechtfertigen. Getestet wird per Game Day, nicht per Hoffnung.

Mit Reliability bist du jetzt durch. Die nächste Lektion wechselt ins Security-Modul und klärt die Frage, die sich durch alle bisherigen Lektionen zog: Wer ist eigentlich wofür verantwortlich — Platform-Team, Stream-Team oder Security?