# Disaster Recovery Planning (DRP) – Die Strategie zur Systemischen Resilienz

TL;DR / Management Summary DRP ist weitaus mehr als nur die Sicherung von Daten; es ist ein strategischer Plan zur Gewährleistung der Geschäftskontinuität nach einem katastrophalen Ausfall. Nutze DRP, um die Akzeptanz von Ausfallzeiten (RTO) und Datenverlust (RPO) basierend auf der Business Impact Analysis (BIA) zu definieren. Der Hauptvorteil liegt in der Reduktion des wirtschaftlichen und reputativen Schadens durch eine getestete, automatisierte Wiederherstellungsfähigkeit, die regelmäßig (mindestens halbjährlich) mittels Fire Drills validiert wird.

# 1. Einführung & Architektur

Im Enterprise-Kontext ist der DRP die technische Operationalisierung des Business Continuity Managements (BCM). Ein DRP definiert die Prozesse, Ressourcen und Infrastrukturen, die notwendig sind, um kritische Geschäftsprozesse nach einer Störung in einem definierten Zeitrahmen wiederherzustellen.

# Warum brauchen wir das?

• Problemstellung aus der Praxis: Standard-Backups (z.B. nächtliche S3- oder Tape-Sicherungen) bieten zwar Datenintegrität, aber die Wiederherstellungszeit (RTO) ist oft inakzeptabel hoch. Bei einem Totalausfall des Rechenzentrums (RC) reicht das Backup nicht, wenn die Infrastruktur fehlt.
• Der Fokus liegt auf Zeit und Verlust:
  • Recovery Time Objective (RTO): Die maximal akzeptable Zeitspanne, innerhalb derer die Systeme nach einem Disaster wieder online und funktionsfähig sein müssen. (Ist die Zeit bis zur Wiederherstellung.)
  • Recovery Point Objective (RPO): Der maximal akzeptable Datenverlust (gemessen in Zeit) seit der letzten gültigen Sicherung. (Ist der akzeptierte Datenverlust.)
  • Maximum Tolerable Period of Disruption (MTPD/MAA): Die absolute maximale Zeit, die ein Geschäftsprozess unterbrochen werden darf, bevor der Schaden als irreparabel gilt. Der RTO muss immer kleiner sein als die MTPD.

# Vergleich mit Alternativen (HA vs. DR)

# Architektur-Diagramm (Der DRP-Zyklus)

Ein effektiver DRP muss zyklisch sein und die folgenden Phasen durchlaufen.

graph TD
    A[BIA & Risikoanalyse] --> B(DR Strategie: RTO/RPO Definition);
    B --> C{Implementierung der technischen Lösung};
    C --> D[Runbook Erstellung & Dokumentation];
    D --> E(DRP Testing: Fire Drills);
    E --> F{Post-Mortem & Review};
    F --> A;
    E -- Success --> G(Wartung & Change Management);
    G --> A;

    subgraph Infrastruktur-Strategien
        C --> C1(Hot Site);
        C --> C2(Warm Site / Pilot Light);
        C --> C3(Cold Site / Backup Restore);
    end

Kernel-Sicht (Relevant für RPO): Im Linux-Subsystem wird der RPO stark durch die gewählte Replikationsmethode und die Einhaltung der ACID-Eigenschaften der Datenbanken beeinflusst.

• Synchronous Replication: Schreibt auf beiden Seiten, bevor der Commit bestätigt wird (RPO = 0, höhere Latenz). Nutzt oft Kernel-Module wie DRBD oder Hardware-Layer-Replikation (Storage Array).
• Asynchronous Replication: Commit wird lokal bestätigt, Replikation erfolgt zeitverzögert (RPO > 0, geringere Latenz). Typisch für Cloud-Storage-Dienste oder Datenbank-Replikationsmechanismen (z.B. PostgreSQL streaming replication).

# 2. Installation & Grundkonfiguration (Praxis)

Wir richten keinen Server ein, sondern den Plan und die dafür notwendige Grundlage: die Segmentierung und Dokumentation.

# Voraussetzungen

1. Business Impact Analysis (BIA): Dokumentierte Priorisierung aller Geschäftsprozesse und der darauf basierenden Anwendungen. Dies definiert die Tiering-Struktur.
2. Configuration Management Database (CMDB) / Dependency Mapping: Eine aktuelle, zuverlässige Quelle für die Abhängigkeiten kritischer Systeme (z.B. Applikation A braucht Datenbank B und LDAP C). Fehlt dies, scheitert der DRP im Ernstfall am Boot-Reihenfolge-Problem.
3. Dedicated DR Network Segment: Ein getrenntes, idealerweise dunkel gehaltenes (dark) Netzwerksegment im DR-Standort, das die gleichen IP-Bereiche wie die Produktion abbilden kann (oder via Layer-3-VPNs geroutet wird).

# Schritt-für-Schritt Setup (Der “Runbook Happy Path”)

Der Kern jedes DRP ist das Runbook. Es muss detailliert, aktuell und vor allem: Offline verfügbar sein.

# 2.1 Definition der Wiederherstellungs-Tiers

Wir definieren Tiers basierend auf den von der BIA geforderten Metriken:

# 2.2 Runbook Struktur (Essential Core)

Ein minimales Runbook für Tier 1 sollte diese Phasen abdecken:

# RUNBOOK PHASE 1: DISASTER DECLARATION & INITIAL ASSESSMENT
# Die Entscheidung, den DRP auszulösen (DR Declaration).
echo "STATUS: 1.1 - Disaster declared by Incident Manager (IM). Time: $(date)"
export DR_SITE="eu-west-2" # Ziel-Region/Standort

# -----------------------------------------------------------
# RUNBOOK PHASE 2: ENVIRONMENT PROVISIONING (IaC)
# Automatisiertes Hochfahren der Infrastruktur im DR-Standort
# Wir nutzen Ansible/Terraform, um die Basis-VMs/Netzwerke bereitzustellen.
cd /srv/drp/terraform/tier1_network
terraform init
terraform apply -auto-approve -var "target_region=${DR_SITE}"
# (Optional: Test auf Layer 2 Connectivity zum Primary DC via Stretch-VLAN)

# -----------------------------------------------------------
# RUNBOOK PHASE 3: DATA SYNCHRONIZATION & RECOVERY
# Daten-Restore/Switchover: Sicherstellen, dass die letzte Replikation gültig ist
# Beispiel: Datenbank Failover (PostgreSQL)
/usr/local/bin/pg_dr_switchover.sh --target-server db-dr-01 \
    --confirm-lsn $(cat /tmp/last_valid_lsn)

# -----------------------------------------------------------
# RUNBOOK PHASE 4: APPLICATION STARTUP & VALIDATION
# Starten der Anwendung in der korrekten Reihenfolge (via CMDB)
ansible-playbook /srv/drp/ansible/tier1_app_startup.yml -e "host_group=app_tier1_dr"

# -----------------------------------------------------------
# RUNBOOK PHASE 5: CUTOVER & DNS SWITCH
# Umschalten der Endnutzer auf den DR-Standort
# TTL muss niedrig gesetzt sein (z.B. 60 Sekunden).
/usr/local/bin/dr_dns_switch.py --domain example.com --target-ip 10.10.20.5

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning: Optimierung von RPO und RTO

# RPO Optimierung (Datenverlust Minimierung)

1. Change Data Capture (CDC): Statt blockbasierter Replikation werden nur logische Änderungen repliziert (z.B. Debezium, Oracle GoldenGate). Reduziert den Netzwerk-Overhead drastisch und ermöglicht nahezu RPO=0.
2. Asynchrone Batch- vs. Streaming-Replikation: Bei hohem Transaktionsvolumen ist eine gut konfigurierte Streaming-Replikation (z.B. Kafka, ZeroMQ) der Datenbank-Log-Versendung vorzuziehen, da sie Latenzen besser abfängt, ohne den Primary DC zu belasten.
3. Storage Snapshot Intervalle: Bei Dateisystemen wie ZFS oder LVM sollte die Snapshot-Häufigkeit direkt dem RPO entsprechen. Ein RPO von 15 Minuten erfordert ein Snapshot-Intervall von maximal 10–15 Minuten, plus die Zeit für die Übertragung (Delta).

# RTO Optimierung (Wiederherstellungszeit Minimierung)

1. “Pilot Light” Strategie: Im DR-Standort laufen nur die minimal notwendigen Komponenten (z.B. Datenbank-Server im Read-Only Modus, Load Balancer, minimale Compute-Instanzen). Dies reduziert die Kosten, während die Hochlaufzeit (RTO) niedrig bleibt, da die Daten bereits synchronisiert sind.
2. Pre-Warming: Spezielle Caching-Server oder Applikationscontainer sollten regelmäßig im DR-Standort gestartet und wieder heruntergefahren werden, um sicherzustellen, dass Images, Konfigurationen und Lizenzen sofort verfügbar sind.

# Hardening & Security

DR-Umgebungen sind oft ein Security-Blindspot. Dies muss vermieden werden.

1. Immutable Backups (WORM): Speichern Sie die letzten kritischen Backups in einem unveränderlichen (Write Once, Read Many) Speicher (z.B. AWS S3 Object Lock, Veeam Immutability Proxy), um Schutz vor Ransomware zu bieten.
2. Netzwerk-Isolation: Die DR-Umgebung muss von der Produktion isoliert sein. Der Replikationskanal sollte nur unidirektional oder über dedizierte VPNs/Direct Connects erfolgen.
3. Identitätsmanagement (IAM/RBAC): Der Zugriff auf die DR-Umgebung muss auf das minimale Notwendige beschränkt werden (Principle of Least Privilege). Der DRP-Prozess sollte idealerweise durch einen dedizierten, stark gesicherten Service-Account mit spezifischen Notfallberechtigungen ausgeführt werden, der nur im Falle einer DR-Deklaration aktiviert wird (Break-Glass-Prozedur).
4. Verschlüsselung: Alle ruhenden Daten (Data at Rest) im DR-Standort müssen verschlüsselt sein (z.B. LUKS, Cloud KMS).

# 4. Day-2 Operations: Wartung & Alltag

Der DRP ist nutzlos, sobald er einmal geschrieben und danach vergessen wird. Change Management ist hier kritisch.

# Typische Tasks

1. Regelmäßiger Dependency Review: Bei jeder größeren Code- oder Infrastrukturänderung (z.B. neuer Load Balancer, neuer Microservice) muss das CMDB und das DRP-Runbook aktualisiert werden. Erfahrungswert: 50% der DRP-Tests scheitern an einer nicht dokumentierten neuen Abhängigkeit.
2. Runbook Walk-Throughs: Mindestens monatlich sollte das DR-Team das Runbook mental durchgehen (Tischübung), um neue Teammitglieder zu schulen und die Aktualität zu prüfen.
3. Data Consistency Checks: Validieren Sie, dass die replizierten Daten im DR-Standort nutzbar sind (z.B. periodische Mounts von Dateisystemen, Read-Only-Abfragen gegen DR-Datenbanken).

# Automatisierung (Ansible/Terraform)

Die größte RTO-Optimierung wird durch vollständige Automatisierung der Wiederherstellung erreicht. Das Ziel ist es, die menschliche Fehlerquote (MTPF – Mean Time to Primate Fault) zu eliminieren.

# Ansible Playbook zur Validierung und DNS-Bereitstellung im DR-Standort
- name: 4. Ensure DR Configuration is Idempotent
  hosts: dr_hosts
  gather_facts: false
  tasks:
    - name: Check replication status of DB cluster
      command: /usr/local/bin/check_dr_status.sh
      register: dr_status_output
      failed_when: "'FAIL' in dr_status_output.stdout"
      tags: [validation]

    - name: Configure internal DNS records for application endpoints
      community.general.ini_file:
        path: /etc/bind/zones/internal.zone
        section: "{{ item.zone }}"
        option: "{{ item.record }}"
        value: "{{ item.ip }}"
        state: present
      with_items:
        - { zone: 'app.example.com', record: '@', ip: '{{ DR_LB_IP }}' }
        - { zone: 'db_master.internal', record: '@', ip: '{{ DR_DB_MASTER_IP }}' }
      tags: [network, dns]

    - name: Verify application endpoint health check
      uri:
        url: "http://{{ DR_LB_IP }}/health"
        status_code: 200
      delay: 60  # Warten, bis die Applikation gebootet ist
      retries: 5

# 5. Troubleshooting & “War Stories”

Disaster Recovery ist nur so gut wie das letzte erfolgreiche Fire Drill.

# Top 3 Fehlerbilder

1. Symptom A: RTO nicht erreichbar, Wiederherstellung stockt bei Phase 4 (Application Startup).

   • Fehlermeldung: Application logs zeigen Connection refused oder Timeout connecting to LDAP.
   • Ursache: Das Runbook geht davon aus, dass alle Infrastruktur-Dienste sofort im DR-Standort verfügbar sind. Die CMDB war fehlerhaft und listete eine kritische Abhängigkeit (z.B. ein interner Message Broker), der nicht in Tier 1 enthalten war oder nicht in der korrekten Reihenfolge gestartet wurde.
   • Lösung: Umfassendes Dependency Mapping, Starten der abhängigen Dienste (Tier-0-Services) vor den Tier-1-Applikationen, oder Umstellen auf dezentrale, isolierte Auth-Services im DR.

2. Symptom B: RPO verfehlt, die Datenbank ist nach dem Failover nicht konsistent.

   • Analyse: Datenbank-Log-Analyse (LSN/SCN) zeigt einen signifikanten Lag. Die letzten 30 Minuten der Transaktionen fehlen, obwohl RPO = 5 Minuten definiert war.
   • Ursache: Der WAN-Link zwischen den Rechenzentren war aufgrund einer Netzwerk-Überlastung (z.B. versehentlicher großer Transfer) gesättigt. Die asynchrone Replikation konnte die Write-Rate der Primary DC nicht bewältigen.
   • Lösung: Dedizierte Bandbreiten-Garantie (QoS) für den Replikationsverkehr. Implementierung von Warnungen, wenn die Replikations-Warteschlange (Lag) einen Schwellenwert (z.B. 75% des RPO) überschreitet.

3. Symptom C: DR-Test schlägt fehl, weil Endbenutzer oder externe Dienste den neuen Standort nicht erreichen.

   • Ursache: Veraltete DNS-TTL-Einstellungen (immer noch 24 Stunden) oder eine vergessen Firewall-Regel (ACL) im DR-Standort, die nur den internen Zugriff erlaubte, nicht aber den externen Traffic vom Edge-Router.
   • Lösung: Erzwingen Sie bei kritischen DNS-Einträgen eine maximale TTL von 300 Sekunden. Das Runbook muss einen dedizierten Schritt zur Überprüfung aller relevanten Edge-Komponenten enthalten.

# Recovery Szenarien: Die Harten Entscheidungen

graph TD
    A[Disaster Declared?] --> B{Sind RTO/RPO erreichbar?};
    B -- Yes --> C(Execute Automated Runbook);
    B -- No / Uncertain --> D(Manuelle Schritte prüfen / Rollback Plan);

    C --> E[Verify System Health (Tier 0/1)];
    E -- Success --> F(DNS Cutover / Traffic Switch);
    E -- Failure --> D;

    D --> G(Analyse RTO/RPO Deviation);
    G --> H{Datenintegrität prüfen};
    H -- OK --> I(Restart Runbook from relevant step);
    H -- Critical Failure --> J(Fall-Back auf Backup / Cold Site DRP);

    J --> K(Notify Management & Legal);

Anekdote (“War Story”): In einem unserer ersten großen, automatisierten DR-Tests (Fire Drill) verlief die Infrastruktur-Provisionierung (Phase 2) perfekt. Der RTO von 4 Stunden schien realistisch. Was wir vergaßen: Die Lizenzserver (Dongle-basiert) der kritischen Applikation waren im Primary DC physisch hinterlegt und liefen nicht in der Cloud. Die Applikation startete, aber funktionierte nicht. Lektion: DRP muss die gesamte Kette umfassen – Software, Daten, Infrastruktur UND Lizenzen/Validierung.

# 6. Monitoring & Alerting

Der DRP muss selbst überwacht werden. Man spricht vom DRP Health Monitoring.

# Metriken

# Alerting-Regeln

1. RPO Breach Warning: Pager klingelt, wenn der Replikations-Lag 75% des definierten RPO überschreitet (z.B. 4 Minuten Lag bei 5 Minuten RPO). Aktion: Sofortige Bandbreitenprüfung und Drosselung nicht-kritischer Transfers.
2. Backup Immutability Check Failure: Kritischer Alarm, wenn die Unveränderlichkeitsrichtlinie (WORM) des Backup-Speichers manipuliert wurde. (Hinweis auf mögliche Ransomware-Aktivität).
3. Automatisierungsfehler: Wenn das IaC-Tool (Terraform/Ansible) im täglichen Validierungsmodus einen Fehler meldet (z.B. “Cannot connect to DR compute cluster”).

# 7. Fazit & Empfehlung

Ein DRP ist eine Versicherungspolice, die regelmäßig bezahlt (gewartet) und getestet werden muss. Ein ungeprüfter DRP ist gleichbedeutend mit keinem DRP.

Empfehlungen des Senior Engineers:

1. Teste aggressiv: Führe jährliche Full-Failover Fire Drills durch, die echte Netzwerk-Trennungen simulieren, und jährliche Überraschungstests (Blind-Tests), um die menschlichen Faktoren zu testen.
2. Automatisierung als RTO-Garantie: Investiere massiv in IaC und Runbook-Automatisierung. Jeder manuelle Schritt ist eine RTO-Verzögerung und eine potentielle Fehlerquelle.
3. Sei ehrlich beim RPO: Ein RPO von Null ist extrem teuer und selten geschäftlich gerechtfertigt. Definiere Tiers präzise, um nicht unnötig in unkritische Systeme zu investieren.

Wann würde ich es nicht einsetzen (oder anders)? Für nicht-kritische, Legacy-Systeme, deren MTPD größer als 7 Tage ist, kann ein einfaches Tape-Backup oder Cloud-Archiv (Cold Site) genügen. Für moderne, gut dokumentierte SaaS-Lösungen (z.B. Cloud-HR-Systeme) reicht es, deren RTO/RPO vertraglich zu prüfen und in den DRP zu integrieren, ohne eigene Technik zu implementieren.

Ausblick: Cyber Resilience und Chaos Engineering Zukünftig wird DRP mit der Cyber Resilience (Fähigkeit, sich von Cyber-Angriffen zu erholen) verschmelzen. Tools wie Chaos Engineering (z.B. Chaos Mesh, Netflix Chaos Monkey) werden zunehmend genutzt, um die Wiederherstellungsmechanismen bereits im laufenden Betrieb proaktiv zu testen und Schwachstellen zu identifizieren, bevor ein echter Disaster eintritt.

# Anhang: Cheatsheet (DRP Operations)

# Referenzen

• NIST Special Publication 800-34: Contingency Planning Guide for Federal Information Systems (Goldstandard für DRP-Struktur).
• The Phoenix Project / DevOps Handbook: Fokus auf die Eliminierung von Engpässen und die Automatisierung von Wiederherstellungsprozessen.
• Vendor Documentation (AWS/Azure/GCP DR Solutions): Spezifische Implementierungsdetails für Pilot Light und Warm Site Architekturen in der Cloud.