Disaster Recovery Plan erstellen: Von Backups zur vollständigen Business Continuity

65% aller kleinen Unternehmen die einen schwerwiegenden Datenverlust erleiden, schließen innerhalb von 2 Jahren. Die Ursache ist selten der Angriff selbst - es ist die fehlende Vorbereitung auf die Wiederherstellung. Ein Disaster Recovery Plan ist die Versicherung die greift wenn alles andere versagt.

Grundlagen: Was ist ein DR-Plan?

Begriffsabgrenzung

Business Continuity Plan (BCP): Der übergeordnete Plan der beschreibt wie das Geschäft weiterlaufen kann. Er umfasst Personal, Prozesse, Kommunikation und Ausweichstandorte. Die zentrale Frage: “Wie bleiben wir geschäftsfähig?”

Disaster Recovery Plan (DRP): IT-fokussiert: wie werden IT-Systeme wiederhergestellt? Er umfasst Backup-Verfahren, Recovery-Schritte und Systemprioritäten. Die zentrale Frage: “Wie bekommen wir die IT wieder zum Laufen?”

IT-Notfallmanagement verbindet BCP und DRP. Relevante Standards: BSI Standard 200-4 (Business Continuity Management) und ISO 22301 (BCM-Zertifizierung).

Typische Auslöser für DR

• Ransomware-Angriff (häufigster Auslöser)
• Hardware-Ausfall (Server, Storage, SAN)
• Naturkatastrophen (Brand, Überschwemmung, Sturm)
• Menschliches Versagen (versehentliches Löschen, Fehlkonfiguration)
• Stromausfall über längeren Zeitraum
• Lieferantenausfall (Cloud-Provider-Outage)

Business Impact Analysis (BIA)

Schritt 1: Kritische Systeme identifizieren

Für jedes System wird der Ausfall-Impact bewertet und RTO/RPO definiert:

System	Nutzer	Finanzieller Impact	RTO	RPO	Priorität
ERP-System (SAP)	150 (alle Ops)	50.000 EUR/Tag	4 Stunden	1 Stunde	KRITISCH
CRM (Salesforce)	Vertrieb	-	24 Stunden	4 Stunden	HOCH
Interne Wiki (Confluence)	alle	-	72 Stunden	24 Stunden	MITTEL
Archiv-Dokumente	wenige	-	7 Tage	24 Stunden	NIEDRIG

RPO und RTO verstehen

RPO = Recovery Point Objective - beantwortet die Frage: “Wie viel Datenverlust ist akzeptabel?”

RPO	Bedeutung	Technische Anforderung	Kosten
0	Kein Datenverlust!	Synchrone Replikation	sehr hoch
1 Stunde	Max. 1h Daten verlieren	Stündliche Backups	hoch
24 Stunden	Max. 1 Tag Daten verlieren	Tägliche Backups	mittel

RTO = Recovery Time Objective - beantwortet die Frage: “Wie lange darf das System ausfallen?”

RTO	Bedeutung	Technische Anforderung	Kosten
0	Keine Ausfallzeit!	Hot-Standby Redundanz	sehr hoch
4 Stunden	Innerhalb 4h wiederhergestellt	Warm Standby	hoch
24 Stunden	Bis zu einem Tag Ausfall	Backup & Restore	mittel

Goldene Regel: RPO und RTO von den Fachbereichen definieren lassen. IT entscheidet nicht was kritisch ist - das Geschäft entscheidet. IT kalkuliert die Kosten und das Business entscheidet die Prioritäten.

Backup-Strategie: Die 3-2-1-Regel und mehr

3-2-1-Regel (Mindeststandard)

• 3 Kopien der Daten (Original + 2 Backups)
• 2 verschiedene Medien (z.B. NAS + externe HDD oder Cloud)
• 1 Kopie offsite (anderer Gebäudetrakt oder Cloud)

Erweiterung für die Ransomware-Ära - 3-2-1-1-0-Regel:

• Plus 1 immutables/unveränderliches Backup (Ransomware kann es nicht löschen)
• Plus 0 Fehler bei Wiederherstellungstests (regelmäßig testen)

Backup-Typen

Typ	Beschreibung	Geschwindigkeit	Speicherbedarf
Full Backup	Alles, jedes Mal	langsam	hoch
Incremental Backup	Nur Änderungen seit letztem Backup	schnell	niedrig
Differential Backup	Änderungen seit letztem Full-Backup	mittel	mittel

Empfohlenes Schema (GFS: Grandfather-Father-Son)

• Täglich (Son): Incrementals Montag bis Samstag
• Wöchentlich (Father): Full-Backup Sonntag
• Monatlich (Grandfather): Full-Backup, 12 Monate aufbewahren
• Jährlich: Jahres-Backup (gesetzlich: 10 Jahre für Finanzdaten)

Backup-Lösungen

Veeam Backup & Replication (Enterprise-Standard):

• Unterstützt VMware, Hyper-V, physisch, Cloud-VM
• Hardened Repository: Linux mit immutable Backups (Ransomware-Schutz)
• Instant Recovery: VM aus Backup in Minuten starten
• Replication: Sync zu Disaster-Recovery-Site
• Preis: ab 500 EUR/Sockel

Windows Server Backup (kostenlos, für kleinere Umgebungen):

• In Windows Server integriert, Bare-Metal-Recovery möglich, begrenzter Funktionsumfang

Spezifische Systeme:

• Datenbanken: SQL Server Agent, mysqldump, pg_dump (wichtig: datenbank-konsistente Backups)
• Microsoft 365: Drittanbieter nötig - Microsoft sichert keine E-Mails (Veeam for M365, Acronis, Avepoint)
• Cloud-VMs: AWS Backup, Azure Backup (native Services)

Immutable Backups (Ransomware-Schutz)

AWS S3 Object Lock:

Bucket mit Object Lock aktivieren:
- Compliance Mode: NIEMAND kann löschen (auch Root nicht!)
- Governance Mode: nur mit speziellem Permission löschbar
- Retention Period: z.B. 30 Tage (Ransomware kann nicht löschen)

Veeam Hardened Repository:

• Linux-Server mit immutable Backups
• Nur Backup-Schreibzugriff, kein Löschen
• Separates OS ohne AD-Mitgliedschaft
• SSH-Key statt Passwort

Azure Immutable Blob Storage: WORM Policy auf Storage Account, Compliance-Modus für regulierte Branchen (FINMA, SEC).

Failover-Architekturen

Wiederherstellungs-Szenarien nach Kosten und RTO

Szenario 1 - Backup & Restore (niedrigste Kosten, längste RTO)

• Bei Ausfall auf neuer Hardware wiederherstellen
• RTO: Stunden bis Tage (je nach Systemgröße)
• Kosten: niedrig (nur Backup-Speicher)
• Geeignet: nicht-kritische Systeme mit RTO > 24h

Szenario 2 - Warm Standby

• Standby-Systeme vorhanden, nicht vollständig synchronisiert
• Bei Ausfall: Standby hochfahren + letzte Backups einspielen
• RTO: 1-4 Stunden
• Kosten: mittel (Standby-Hardware/VMs + Replikation)

Szenario 3 - Pilot Light (Cloud)

• Minimale Core-Infrastruktur immer aktiv in der Cloud
• Bei Ausfall: Rest der Infrastruktur in Minuten skalieren
• RTO: 30-60 Minuten
• AWS/Azure: Minimale EC2/VM-Instanzen + Datenbank-Replikation

Szenario 4 - Hot Standby / Active-Passive

• Vollständige Kopie aktiv bereit in anderer Region/RZ
• Daten synchron repliziert (RPO ≈ 0)
• Failover: DNS-Umschaltung, Sekunden bis Minuten
• RTO: < 30 Minuten
• Kosten: hoch (doppelte Infrastruktur)

Szenario 5 - Active-Active (Multi-Region)

• Alle Instanzen aktiv, Load Balancer verteilt
• Keine “Umschaltung” nötig, automatischer Failover
• RTO: ca. 0 (Sekunden für DNS-Propagation)
• Kosten: sehr hoch, empfohlen nur für kritischste Systeme

Cloud DR (AWS Disaster Recovery Beispiel)

Route53 Health Checks + Failover:
- Primary: on-premises Rechenzentrum
- Secondary: AWS Region eu-central-1 (Frankfurt)
- Automatischer Failover wenn Primary nicht erreichbar
- RTO: 5-10 Minuten (DNS-TTL + Health Check Interval)

AWS Elastic Disaster Recovery (DRS): Kontinuierliche Replikation on-premises Server nach AWS, Failover mit Start der Instanzen in AWS in 30-60 Minuten, Failback nach Behebung zurück zu on-premises. Preis: 0,028 USD/Stunde/Server (ca. 20 EUR/Server/Monat).

DR-Tests - der wichtigste (und meist vergessene) Teil

DR-Test-Typen (Eskalation)

1. Table-Top Exercise (Papier-Test)

• Team bespricht ein Szenario: “Ransomware verschlüsselt alle Server”
• Fragen: Was tun wir? Wer ruft wen an? Wo sind die Backup-Keys?
• Kein technischer Test, zeigt aber Prozess-Lücken
• Dauer: 2-4 Stunden
• Häufigkeit: jährlich (mindestens)

2. Component Test

• Einzelne System-Recovery testen (“Stellt den Datenbankserver aus dem Backup wieder her”)
• Misst RTO für dieses System
• Dauer: 1-2 Stunden
• Häufigkeit: vierteljährlich für kritische Systeme

3. Full DR Test

• Vollständiger Failover auf DR-Site/Cloud
• Produktionsdatenverkehr auf DR-Umgebung umschalten
• Misst Gesamt-RTO und RPO
• Dauer: halber bis ganzer Tag
• Häufigkeit: mindestens jährlich
• Produktions-Impact vorher abschätzen

4. Unangekündigter Test

• Team weiß vorher nicht dass heute getestet wird
• Testet ob alle Personen verfügbar und Prozesse bekannt sind
• Nur für reife Organisationen geeignet

Beispiel DR-Test-Protokoll

Datum:       2026-03-15
Test-Typ:    Component Test - ERP-Server Recovery
Ziel-RTO:   4 Stunden
Ziel-RPO:   1 Stunde

Ablauf:
10:00  Test-Start: Simulation "ERP-Server ausgefallen"
10:05  Backup identifiziert: letztes Backup 09:00 Uhr (RPO = 1h ✓)
10:15  Wiederherstellung auf Test-Server gestartet
11:45  System verfügbar (RTO = 1h45min ✓ Ziel: 4h)
11:50  Funktionstest: alle kritischen Prozesse funktionieren
12:00  Test abgeschlossen

Ergebnis:
  RTO erreicht: JA (1h45min < 4h Ziel)
  RPO erreicht: JA (1h Datenverlust)

Gefundene Lücken:
  - Backup-Key lag nur bei IT-Leiter (single point of failure)
  - Dokumentation für Schritt 3 veraltet

Aktionen:
  - Backup-Keys in Passwort-Manager für Team hinterlegen
  - DR-Dokumentation bis 2026-04-01 aktualisieren

Nächster Test: 2026-06-15

DR-Plan-Dokument Struktur

Ein vollständiges DR-Dokument enthält folgende Abschnitte:

1. Zweck und Geltungsbereich

Welche Systeme und Prozesse sind abgedeckt? Wer trägt welche Verantwortung (Rollen)?

2. Kontaktliste (immer druckbar halten!)

Wenn E-Mail und digitale Systeme ausfallen, muss die Kontaktliste analog verfügbar sein:

• IT-Leiter: Name, Handy, Privatnummer
• CISO: Kontaktdaten
• Geschäftsführer: Kontaktdaten
• Wichtige Dienstleister: Cloud-Provider, ISP, Hardware-Lieferant
• Cyber-Versicherung: Hotline und Policennummer

3. System-Inventar mit Prioritäten

Alle kritischen Systeme mit RTO/RPO. Abhängigkeiten dokumentieren: “System A benötigt System B um zu funktionieren”.

4. Recovery-Prozeduren (je System)

Schritt-für-Schritt-Anleitung die jeder Admin nachvollziehen kann. Keine Annahmen - “Das weiß jeder” gibt es in einem Ernstfall nicht. Backup-Speicherorte, Zugang und Passwörter (im Passwort-Manager) dokumentieren.

5. Kommunikationsplan

• Intern: wer wird wann informiert?
• Extern: Kunden, Partner, Behörden (NIS2-Meldepflicht beachten)
• Vorbereitete Templates für häufige Szenarien

6. Test-Protokolle

Dokumentation vergangener Tests und offene Findings aus dem letzten Test.

7. Plan-Review-Historie

Wann zuletzt aktualisiert? Wer hat überprüft? Gültigkeitsdatum (maximal 1 Jahr).

---

Kein DR-Plan zu haben bedeutet Improv-Theater wenn der Ernstfall eintritt - aber mit Millionen-Einsatz. AWARE7 unterstützt beim Aufbau vollständiger DR-Pläne, der Auswahl der richtigen Backup-Strategie und der Durchführung von DR-Übungen.

DR-Planung anfragen | Incident Response Planung