Backups sind kein Disaster Recovery — der Unterschied, der dich teuer zu stehen kommt

Es ist 3 Uhr nachts und die primäre Region ist weg. Der Bereitschaftsingenieur ist zunächst ruhig — „wir haben Backups, alles gut.“ Die Backups sind makellos. Jedes Byte ist da.

Vierzehn Stunden später ist der Dienst immer noch offline. Nicht, weil sich die Daten nicht zurückspielen ließen — das ging in zwanzig Minuten. Sondern weil niemand einen Plan hatte, das Netzwerk neu aufzubauen, DNS umzubiegen, die IAM-Rollen neu zu erstellen und die Infrastruktur hochzuziehen, in die diese Backups zurückgespielt werden mussten. Das Backup war perfekt. Die Wiederherstellung war ein live erfundenes Gewurstel, zum denkbar schlechtesten Zeitpunkt.

Das ist das teuerste Missverständnis im Betrieb: „wir haben Backups“ ist nicht dasselbe wie „wir können wiederherstellen.“ Das eine ist eine Kopie deiner Daten. Das andere ist die Fähigkeit, dein Geschäft wieder zum Laufen zu bringen. Beides zu verwechseln macht aus einem zweistündigen Vorfall einen zweitägigen Ausfall.

Hier ist der Unterschied, ausbuchstabiert — und wie du das aufbaust, was dich wirklich rettet.

Ein Backup beantwortet eine Frage. DR beantwortet eine größere.

Nimm das Fachchinesisch weg, und es ist einfach:

• Ein Backup ist eine zeitpunktbezogene Kopie deiner Daten. Es beantwortet genau eine Frage: bekomme ich die Daten zurück?
• Disaster Recovery ist der ganze Plan und die Fähigkeit, einen Dienst nach einer Katastrophe wieder online zu bringen. Es beantwortet die Fragen, die dem Geschäft wirklich wichtig sind: wie schnell sind wir zurück, und wie viel haben wir verloren?

Ein Backup ist eine Komponente von Disaster Recovery — eine notwendige — aber bei Weitem nicht das Ganze. DR umfasst auch die Infrastruktur zum Laufen, das Netzwerk und DNS zum Routen des Verkehrs, die Secrets und Zertifikate für Vertrauen, das IAM für Zugriff und das Runbook, dem ein gestresster Mensch um 3 Uhr nachts folgt.

Du kannst fehlerfreie Backups haben und trotzdem katastrophal scheitern, weil die Daten nirgends landen konnten. Das ist nicht hypothetisch — es ist die häufigste Art, wie DR schiefgeht.

RTO und RPO: Die zwei Zahlen, die alles bestimmen

Bevor du eine Strategie wählst, brauchst du zwei Zahlen, und die meisten Teams werfen sie in einen Topf. Es sind unterschiedliche Fragen mit unterschiedlichen Kosten.

• RPO — Recovery Point Objective: wie viel Daten kannst du dir leisten zu verlieren? Es blickt von der Katastrophe zurück auf deinen letzten wiederherstellbaren Stand. Ein RPO von 1 Stunde heißt, du sicherst oder replizierst mindestens stündlich; die letzte Stunde an Schreibvorgängen zu verlieren ist akzeptabel.
• RTO — Recovery Time Objective: wie lange kannst du dir Ausfall leisten? Es blickt von der Katastrophe nach vorn bis zum wiederhergestellten Dienst. Ein RTO von 15 Minuten heißt, du musst binnen fünfzehn Minuten zurück sein.

Diese sind unabhängig. Ein Zahlungs-Ledger verkraftet vielleicht Stunden Ausfall (hohes RTO), aber null Datenverlust (RPO nahe null). Ein Live-Analytics-Dashboard verkraftet vielleicht den Verlust einer Stunde Daten (hohes RPO), darf aber nie ausfallen (niedriges RTO). Lege sie pro Dienst, aus dem Business-Impact fest — nicht reflexartig „so niedrig wie möglich“, denn jeder Schritt Richtung null vervielfacht die Kosten.

Das RPO-Gespräch ist in Wahrheit ein verkapptes Konsistenz-Gespräch. Für die Theorie darunter siehe Das CAP-Theorem, ehrlich erklärt: Was es wirklich für die Datenbankwahl bedeutet.

Die vier DR-Strategien: Eine Kosten-gegen-Tempo-Leiter

Es gibt nicht das eine „Disaster Recovery“. Es gibt vier Standardstrategien, und sie tauschen Geld gegen Tempo. Vom günstigsten und langsamsten zum teuersten und schnellsten:

1. Backup & Restore — Backups aufbewahren; nach einer Katastrophe die Umgebung neu aufbauen und hineinspielen. Günstigster Betrieb, RTO von Stunden bis Tagen. Passt für unkritische, tolerante Workloads.
2. Pilot Light — ein minimaler Kern läuft immer in der Recovery-Region (typisch ein Live-Datenbank-Replikat), alles andere ist ruhende Infrastructure-as-Code, die du bei Bedarf hochskalierst. Niedrigeres RTO, moderate Kosten.
3. Warm Standby — eine verkleinerte, aber laufende Kopie des ganzen Stacks in der Recovery-Region, bereit, Verkehr zu übernehmen und schnell hochzuskalieren. Schnelleres RTO, höhere laufende Kosten.
4. Multi-Site Active/Active — volle Kapazität läuft gleichzeitig in zwei oder mehr Regionen und bedient Verkehr aus allen. RTO nahe null, RPO nahe null — und der teuerste Betrieb.

Der Fehler ist, eine Strategie für alles zu wählen. Der richtige Zug ist, deine Dienste zu staffeln: Multi-Site für den Checkout-Pfad, Warm Standby für die Kern-API, Pilot Light für interne Tools, schlichtes Backup & Restore für den Reporting-Job, den einen Tag lang niemand vermisst. Passe die Strategie an das RTO/RPO jedes Dienstes an, und du hörst auf, für den Schutz von Dingen zu überzahlen, die ihn nicht brauchen — und hörst auf, die zu unterschützen, die ihn brauchen.

Der ungetestete Plan ist das eigentliche Versagen

Hier ist der Teil, der Teams, die DR haben, von Teams trennt, die es zu haben glauben: ein Plan, den du nie ausgeführt hast, ist eine Hypothese, keine Fähigkeit.

Wenn eine echte Katastrophe zuschlägt, ist der Daten-Restore selten das, was versagt. Das Versagen versteckt sich in den Teilen, die niemand geprobt hat:

• DNS — Einträge mit 24-Stunden-TTL schicken Nutzer weiter zur toten Region, lange nach dem Failover. Der Dienst läuft; der Verkehr findet ihn nicht.
• Zertifikate — das TLS-Zertifikat in der Recovery-Region ist vor Monaten abgelaufen, weil dort nichts Verkehr bediente, das Alarm geschlagen hätte.
• IAM & Secrets — die Rollen und API-Keys, die die App braucht, wurden in der primären Region von Hand erstellt und existierten in der Recovery-Region nie.
• Netzwerkrouten — das Peering, die Firewall-Regeln und die Load-Balancer-Konfiguration wurden nie repliziert, also haben Pakete kein Ziel.

Nichts davon zeigt sich beim Durchlesen am Tisch. Es taucht nur auf, wenn du tatsächlich umschaltest — weshalb regelmäßige DR-Übungen (Game Days), die echten Verkehr bewegen, nicht verhandelbar sind. Automatisiertes Failover, das nie von Hand ausgelöst wurde, sollte als kaputt gelten, bis das Gegenteil bewiesen ist.

Resilienz wird vor dem Vorfall entworfen, nicht danach angeschraubt. Zur Architekturseite des Überlebens von Last und Fehlern siehe Eine Million Benachrichtigungen versenden, ohne abzustürzen.

Wie man es tatsächlich baut

Lass den Ordner weg, der Staub ansetzt. Tu diese vier Dinge:

1. Lege RTO und RPO pro Dienst fest, aus dem Business-Impact. Keine globale Zahl — eine Stufenliste. Der Checkout-Pfad und der nächtliche Report verdienen nicht denselben Schutz.
2. Wähle eine DR-Strategie pro Stufe. Multi-Site, wo Sekunden zählen, Backup & Restore, wo ein Tag in Ordnung ist. Zahle für Tempo nur, wo Tempo sich auszahlt.
3. Leg die ganze Umgebung in Code ab. Infrastruktur, Netzwerk, DNS, IAM — wenn die Wiederherstellung davon abhängt, dass sich jemand erinnert, wie es gebaut wurde, hast du keine Wiederherstellung. Terraform/OpenTofu, damit die Recovery-Region ein plan und apply entfernt ist.
4. Teste es nach Zeitplan, richtig. Mindestens vierteljährlich und nach jeder größeren Änderung. Schalte produktionsähnlichen Verkehr um, miss gegen dein RTO/RPO und behebe jede Lücke, die die Übung aufdeckt. Die Übung, die nie scheitert, ist keine echte Übung.

Die Regel fürs Feld

Backups sind kein Disaster Recovery. Ein Backup beantwortet „bekomme ich die Daten zurück“; Disaster Recovery beantwortet „wie schnell laufen wir wieder, und wie viel haben wir verloren.“ Definiere diese zwei Zahlen — RTO und RPO — pro Dienst aus dem Business-Impact, wähle eine der vier Strategien pro Stufe, damit du für Tempo nur zahlst, wo es zählt, leg die gesamte Umgebung in Code ab, damit die Daten irgendwo landen, und teste das Ganze nach Zeitplan durch echtes Failover. Tu das, und der 3-Uhr-Ausfall ist eine kontrollierte, gemessene Wiederherstellung — kein vierzehnstündiges Gewurstel, deine Infrastruktur neu zu erfinden, während die Uhr und die Verluste laufen.