Disaster-Recovery-Plan erstellen

Bisher hast du Bausteine gelernt: USV, Cluster, Failover, Load Balancing. Aber was passiert wenn die Katastrophe wirklich passiert? Wer entscheidet was? Wer ruft wen an? Welche Schritte werden in welcher Reihenfolge ausgeführt? Genau dafür gibt's den Disaster-Recovery-Plan (DRP) – ein dokumentiertes, getestetes Vorgehen für IT-Katastrophen.

Ein DRP ist kein nice-to-have, sondern Pflicht in vielen Branchen (ISO 27001, BSI Grundschutz, NIS-2). Diese Lektion zeigt dir die Komponenten eines DRPs, den Lebenszyklus von Planung über Test bis Aktivierung, die Unterschiede zwischen Hot/Warm/Cold-Sites, und gibt eine Checkliste für den Aufbau. In der IHK-Prüfung gehört das Thema zum Pflichtwissen für FISI.

1) Was ist Disaster Recovery?

Disaster Recovery (DR) bezeichnet alle Maßnahmen, die nötig sind um IT-Systeme nach einer Katastrophe wiederherzustellen. Eine Katastrophe in diesem Sinne ist jedes Ereignis, das die normale IT-Operation grundlegend stört – größer als ein einzelner Ausfall (siehe L3) und nicht durch normale HA-Maßnahmen lösbar.

Beispiele für DR-relevante Katastrophen:

• Naturereignisse: Brand, Wasser, Erdbeben, Sturm zerstören Rechenzentrum
• Cyberangriffe: Ransomware verschlüsselt komplette Infrastruktur
• Großflächige Stromausfälle: über die USV-Reichweite hinaus
• Pandemie: Personal nicht verfügbar (Lehre aus COVID-19)
• Sabotage / Insider-Angriff: gezielte Zerstörung von Daten
• Cloud-Provider-Ausfall: AWS-Region down, Konto gesperrt
• Versorger-Ausfall: Internet-Provider, Strom-Versorgung, Kühlung

Wichtig: ein einzelner Server-Ausfall ist kein Disaster – dafür gibt's HA/Failover. Datacenter-Komplettausfall oder Komplett-Verschlüsselung hingegen sind Disaster, die einen DRP brauchen.

2) Der DR-Lebenszyklus

Disaster Recovery ist keine einmalige Aktion, sondern ein kontinuierlicher Prozess. Vier Phasen wiederholen sich:

3) Komponenten eines DR-Plans

Ein vollständiger DR-Plan ist ein umfangreiches Dokument. Die wichtigsten Bausteine:

4) DR-Site-Typen: Hot, Warm, Cold

Ein zentraler Baustein vieler DR-Pläne ist die DR-Site – ein zweiter Standort, an den im Notfall umgezogen wird. Es gibt drei Klassen, die sich in Bereitschaftsgrad und Kosten unterscheiden:

5) Moderne Cloud-DR-Strategien

Die Cloud hat DR drastisch verändert. Statt eines physischen Standby-Rechenzentrums kann man flexibel in der Cloud DR-Setups aufbauen. AWS, Azure, Google haben formalisierte DR-Strategien:

• Backup & Restore: Daten in Cloud sichern, im Ernstfall neu deployen. Günstigste, langsamste Variante (Cold-Site-Äquivalent).
• Pilot Light: minimale Cloud-Ressourcen laufen ständig (z.B. nur DB), im Ernstfall werden Restliche provisioniert. Warm-Site-Äquivalent.
• Warm Standby: skalierte Version der Production läuft in Cloud, im Ernstfall hochskalieren. Faster Recovery.
• Multi-Site Active-Active: Produktion läuft simultan in mehreren Regionen, Lastverteilung normal. Im Ernstfall einfach die ausgefallene Region rausnehmen. Hot-Site-Äquivalent.

Vorteil der Cloud: pay-as-you-go ermöglicht günstigeres Stand-By (Pilot Light kostet vielleicht 10% der Production-Kosten). Klassisches Hot-Site-Setup mit eigenem Rechenzentrum ist dagegen sehr teuer.

6) Eskalations-Stufen im DR-Fall

Nicht jeder Vorfall ist ein Disaster. Die meisten DR-Pläne haben Eskalations-Stufen, um angemessen zu reagieren:

7) DR-Plan-Aktivierung: der Workflow

Wie läuft die Aktivierung eines DR-Plans ab? Typischer Workflow von der Erkennung bis zur Recovery:

8) DR-Plan-Test-Methoden

Ein ungetesteter DR-Plan ist wie ungetestetes Backup – Hoffnung statt Garantie. Tests in vier Stufen:

1. Tabletop Exercise: Krisenstab versammelt sich, geht den DRP durch, diskutiert Szenarien auf dem Papier. Günstig, deckt logische Lücken auf.
2. Walkthrough Test: Schritte werden detailliert durchgegangen, ohne tatsächlich Aktionen auszuführen. Prüft Vollständigkeit der Prozeduren.
3. Simulation: einzelne Komponenten werden tatsächlich aktiviert (z.B. DR-Site hochfahren) – ohne aber Production zu beeinträchtigen.
4. Full-Scale DR Drill: kompletter Failover zur DR-Site, Production läuft dort, später Failback. Echter Stresstest, aber Risiko-behaftet.

Empfohlene Frequenzen: Tabletop quartalsweise, Walkthrough halbjährlich, Simulation jährlich, Full-Scale alle 1-2 Jahre. Compliance-Anforderungen (ISO 27001, NIS-2) verlangen oft jährliche dokumentierte Tests.

9) Recovery-Reihenfolge planen

Im Disaster-Fall können nicht alle Systeme gleichzeitig hochgefahren werden. Die Reihenfolge ist kritisch:

1. Infrastruktur: Strom, Netzwerk, DNS, NTP – das Fundament
2. Authentifizierung: Active Directory, LDAP, Kerberos – ohne das keine Logins
3. Storage: SAN, NAS, File-Server
4. Datenbanken: Restore von Backups, Replikation aktivieren
5. Middleware: Message-Queues, Caches (Redis), API-Gateways
6. Anwendungen (kritisch): ERP, Online-Shop, Kunden-Portal
7. Anwendungen (nicht-kritisch): interne Tools, Reporting
8. End-User-Services: Mail, Office, VPN

Abhängigkeiten müssen dokumentiert sein. Wenn die Anwendung das AD braucht, das DNS, das NTP braucht – muss alles in dieser Reihenfolge hochgefahren werden. Sonst Kaskaden-Fehler.

10) Doku-Vorlage für DR-Plan

So sieht ein DR-Plan-Dokument typischerweise aus. Beispiel-Struktur:

11) DRP vs. BCP – die Abgrenzung

Häufig verwechselt: DRP (Disaster Recovery Plan) und BCP (Business Continuity Plan). Die Unterscheidung:

• DRP: fokussiert auf IT-Wiederherstellung. Wie kriegen wir Server, Apps, Daten wieder online?
• BCP: fokussiert auf den Geschäftsbetrieb. Wie hält die Firma im Notfall funktionsfähig (auch ohne IT, ohne Büro, ohne Personal)?

Der DRP ist ein Teil des BCP. Mehr zum BCP in L9.

12) Häufige DR-Plan-Probleme

Auch hier klassische Fallstricke:

• Plan veraltet: nach 2 Jahren ohne Update sind Kontakte falsch, Systeme anders, Prozeduren obsolet
• Plan unauffindbar: liegt auf dem ausgefallenen Server
• Nie getestet: theoretisch perfekt, praktisch unbrauchbar
• Nur ein Admin kennt sich aus: ohne ihn nichts möglich (Bus-Faktor)
• Zu komplex: 500-seitiges Dokument, im Stress unbrauchbar
• Keine Vertretungsregelung: Hauptverantwortlicher im Urlaub
• Plan nur in deutscher Sprache: ausländische Mitarbeiter ausgeschlossen
• Backup-Strategie nicht 3-2-1: alle Kopien fallen mit aus
• DR-Site im selben Stromnetz / Erdbeben-Zone: gleicher Ausfall trifft beide
• Kein Out-of-Band-Kommunikation: Mail+Slack ausgefallen, niemand erreichbar
• Lieferanten-Abhängigkeit ungeklärt: brauchen wir den Cloud-Anbieter, der gerade ausgefallen ist?
• Compliance vergessen: DSGVO-Meldepflichten, Aufsichtsbehörden-Kontakte

13) DR und Compliance

In vielen Branchen ist ein DR-Plan rechtlich vorgeschrieben:

• ISO 27001: Kontrolle A.5.30 (ICT readiness) und A.8.14 (Redundanz) verlangen dokumentierte DR-Maßnahmen
• BSI IT-Grundschutz: Baustein DER.2.1 (Behandlung von Sicherheitsvorfällen)
• NIS-2 (EU): kritische Sektoren müssen Disaster-Pläne und Tests vorweisen
• BAIT/VAIT/KAIT: Banken/Versicherungen müssen Notfallkonzepte haben
• HIPAA (US, Gesundheitswesen): Contingency-Plan-Anforderung
• SOC 2: Type-II-Audits prüfen DR-Tests
• Cyber-Versicherung: viele Anbieter fordern dokumentierte DRP

Wer ohne DRP arbeitet, riskiert nicht nur den IT-Ausfall – sondern auch Bußgelder, Versicherungs-Probleme und Reputationsschäden. Praktisch alle größeren Unternehmen müssen DRP haben.

Zusammenfassung

Disaster Recovery (DR) = Wiederherstellung nach IT-Katastrophen jenseits normaler Ausfälle. DR-Lebenszyklus: Prepare → React → Recover → Review (kontinuierlich). 8 Plan-Komponenten: Risikoanalyse/BIA, Recovery-Strategie, Rollen, Kommunikation, Runbooks, Wiederherstellungs-Reihenfolge, Test-Plan, Wartung. DR-Site-Typen: Cold (Tage RTO, günstig), Warm (Stunden RTO, mittel), Hot (Min/Sek RTO, teuer). Cloud-DR-Strategien: Backup-Restore, Pilot Light, Warm Standby, Multi-Site Active-Active. Eskalations-Stufen: Level 1 (Minor) bis Level 4 (Disaster, Krisenstab). Aktivierungs-Workflow: 11 Schritte von Detection bis Postmortem. Wiederherstellungs-Reihenfolge: Infrastruktur → Auth → Storage → DB → Middleware → kritische Apps → andere → End-User. Test-Methoden: Tabletop, Walkthrough, Simulation, Full-Scale Drill. DRP vs. BCP: DRP = IT, BCP = Geschäftsbetrieb (Übergeordnet). Häufige Probleme: veralteter Plan, unauffindbar (auf ausgefallenem Server), nie getestet, Bus-Faktor, zu komplex. Compliance: ISO 27001, BSI Grundschutz, NIS-2, BAIT, HIPAA, SOC 2 fordern DRP.