Begriff
Disaster Recovery
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Was passiert, wenn dein Rechenzentrum abbrennt? Oder ein Hacker alle Daten verschlüsselt (Ransomware)? Disaster Recovery (DR) ist der Notfallplan. Es ist nicht einfach nur ein Backup ("Ich habe die Datei noch auf USB"). Es ist der Plan, wie die ganze Firma weiterarbeiten kann. "Wir schalten sofort auf das Reserve-Rechenzentrum in München um. Die Mitarbeiter nutzen Laptops im Home Office."
Ziel: So schnell wie möglich wieder online sein.
Merksatz: Strategien und Prozesse, um IT-Systeme nach einem schweren Ausfall (Katastrophe) wiederherzustellen.
Zwei Kennzahlen sind heilig:
- RTO (Recovery Time Objective): Wie lange dürfen wir down sein? (z. B. "Maximal 4 Stunden").
- RPO (Recovery Point Objective): Wie viele Daten dürfen wir verlieren? (z. B. "Maximal die Daten der letzten 15 Minuten").
Je kürzer die Zeit, desto teurer die Lösung. (RPO = 0 Sekunden kostet Millionen).
1. Cold vs. Warm vs. Hot Site
- Cold Site: Ein leerer Raum mit Strom. Du musst erst Server kaufen und hinfahren. (Dauert Wochen). Billig.
- Warm Site: Server stehen da, aber Daten sind alt. Du musst erst das Backup einspielen. (Dauert Tage).
- Hot Site: Eine exakte Kopie des Haupt-RZs. Die Daten werden live gespiegelt. Wenn RZ A ausfällt, übernimmt RZ B sofort. (Dauert Sekunden). Extrem teuer.
2. DRaaS (Disaster Recovery as a Service)
Cloud-Anbieter bieten DR als Abo an. Deine Server laufen lokal. Im Notfall "bootest" du Kopien davon in der Cloud (Azure/AWS).
1. RTO vs. RPO (Recovery Metrics)
- RPO (Recovery Point Objective): "Wie viele Daten dürfen wir maximal verlieren?" Ein RPO von 4 Stunden bedeutet, Backups müssen mindestens alle 4 Stunden laufen. Stürzt die DB um 11:59 Uhr ab, sind die Daten ab 08:00 Uhr unwiederbringlich verloren. Ein RPO von 0 (Null Datenverlust) erfordert synchrone Replikation auf SAN-Ebene.
- RTO (Recovery Time Objective): "Wie lange darf das Geschäft stillstehen?" Ein RTO von 2 Stunden bedeutet: In 120 Minuten müssen die Ersatz-Server booten, die Backups eingespielt sein und der Traffic per DNS Switch umgeleitet werden. Die Kosten steigen exponentiell, je näher RPO und RTO an die Null rücken (Cost of Downtime vs. Cost of Recovery).
2. Synchrone vs. Asynchrone Replikation
Wie spannt man ein Hot-Site Data Center (RZ2) parallel zu RZ1 auf?
- Synchron: JEDER Datenbank-Write in RZ1 blockiert den User, bis das Paket per Dark Fiber das 10km entfernte RZ2 erreicht hat und auch dort als geschrieben quittiert wurde (Two-Phase Commit). Garantiert RPO=0. Die Distanz ist aber durch die Lichtgeschwindigkeit auf ca. 60-100km limitiert, da sonst das TCP (Transmission Control Protocol)/IP Acknowledge die App-Latenz unerträglich macht.
- Asynchron: RZ1 schreibt den Datensatz für den User sofort (schnell). Im Hintergrund drückt RZ1 die neuen WAL-Logs im Minutentakt rüber ins RZ2 (z.B. nach Übersee). Fällt RZ1 aus, bevor der Sync lief, gibt es unweigerlich "Lost Transactions" (RPO > 0), ist dafür für globale Verteilung gedacht.
3. Failover und Split-Brain Syndrom
Der automatische Wechsel vom toten Haupt-RZ ins Notfall-RZ nennt man Failover. Die größte Gefahr für den Admin ist, dass er den Wechsel durchführt, das alte RZ1 aber gar nicht wirklich tot war, sondern nur eine kaputte Leitung hatte (Netzwerk-Segmentierung). Plötzlich laufen RZ1 und RZ2 gleichzeitig (Aktiv-Aktiv ohne Synchronität). Das nennt man Split-Brain. Die Kassensoftware schreibt Buchung X ins RZ1, der Webshop schreibt Buchung Y ins RZ2. Das Zusammenführen ("Re-Synchronisation" / Healing) dieser zwei parallelen Realitäten nach der Reparatur der Leitung zerstört verheerend die referenzielle Datenintegrität der gesamten Buchhaltung. Um dies zu verhindern, nutzt man High-Availability-Quorum-Logiken und strenge Fencing-Routinen. Dabei wird ein System im Ernstfall kontrolliert isoliert oder abgeschaltet, damit nicht zwei aktive Wahrheiten parallel entstehen.
Quick-Check
Reicht ein Backup nicht aus?
Nein. Ein Backup sind nur die Daten. DR ist die Infrastruktur. Was nützt dir das Backup auf Tape, wenn du keinen Server hast, um es einzulegen, und kein Büro, in dem der Server stehen kann?Wie oft muss man das testen?
Mindestens einmal im Jahr. Oft stellt man beim Test fest: "Ups, das Passwort für den Notfall-Server kennt nur der Kollege, der gerade im Urlaub ist." DR-Pläne altern schnell.Was ist der Unterschied zu BCP (Business Continuity Planning)?
DR kümmert sich um die IT (Server wieder hochfahren). BCP kümmert sich um das Business (Wo sitzen die Mitarbeiter? Wer informiert die Presse? Wie bezahlen wir Gehälter?).