Linuxguide

Disaster Recovery Plan – IT-Wiederherstellung nach Katastrophen 2025

RPO, RTO und Notfallwiederherstellung systematisch planen

S
SeeColors IT
11. Juni 20264 Min. Lesezeit143 Aufrufe

RPO und RTO verstehen

RPO (Recovery Point Objective):
  "Wie viel Datenverlust kann ich akzeptieren?"
  RPO = 4h bedeutet: max. 4h alte Backups sind akzeptabel
  → Backup-Frequenz muss < RPO sein!

RTO (Recovery Time Objective):
  "Wie lang darf das System ausfallen?"
  RTO = 2h bedeutet: in 2h wieder betriebsbereit
  → Recovery-Prozess muss < RTO dauern!

Beispiele:
System            RPO     RTO
E-Mail            4h      8h
ERP/Buchhaltung   1h      4h
Webshop           30min   2h
Domain Controller 15min   1h

DR-Plan Grundstruktur

1. Risikoanalyse:
   - Welche Szenarien? (Ransomware, Brand, HW-Ausfall)
   - Welche Systeme sind kritisch?
   - Abhaengigkeiten (AD vor Exchange!)

2. Recovery-Prioritaeten:
   Tier 1 (RTO 1-2h): Domain Controller, DNS, DHCP
   Tier 2 (RTO 4h): ERP, Datenbank, Fileserver
   Tier 3 (RTO 8h): E-Mail, Druck, sekundaere Dienste

3. Backup-Infrastruktur:
   Wo sind Backups? Zugaenglichkeit im Notfall?
   Backup-Credentials (Passwort-Manager offline?)

4. Recovery-Verfahren:
   Schritt-fuer-Schritt Anleitung pro System
   Verantwortliche benennen

5. Kommunikation:
   Interne Eskalation (wen anrufen?)
   Externe Kommunikation (Kunden, Partner)

Ransomware-Wiederherstellung

Schritt 1: Eingrenzung (0-2h)
- SOFORT alle befallenen Systeme vom Netz trennen!
- Nicht herunterfahren (Forensik moeglich)
- Backup-Systeme pruefen (ebenfalls betroffen?)

Schritt 2: Schadenseinschaetzung (2-4h)
- Welche Systeme sind verschluesselt?
- Welche Backups sind sauber (vor Infektion)?
- BSI/Polizei informieren (empfohlen)

Schritt 3: Infrastruktur neu aufsetzen (4-24h)
- Frische Hardware oder neue VMs
- Domain Controller zuerst!
- Nur saubere Backups nutzen

Schritt 4: Systeme wiederherstellen (1-3 Tage)
- Systemreihenfolge einhalten (Tiers!)
- Nach jedem System: Funktionstest

Schritt 5: Nachbereitung
- Root Cause Analysis
- Luecken schliessen (wie konnte Ransomware rein?)
- DR-Plan aktualisieren

DR-Test durchfuehren

# Jaehrlicher DR-Test (Mindestanforderung)
# Optionen:
# A) Vollstaendiger Test: echte Systeme wiederherstellen
# B) Simulierter Test: Tabletop Exercise
# C) Komponententest: einzelne Systeme

# Was zu testen:
# 1. Backup-Zugriff (auch Offsite/Cloud)
# 2. Bootfaehigkeit wiederhergestellter VMs
# 3. Anwendungs-Funktionalitaet
# 4. Netzwerk-Konnektivitaet nach Recovery
# 5. RTO-Zeit messen!

# Dokumentation:
echo "DR-Test $(date): RTO erreicht in X Stunden" >> /var/log/dr-tests.log

FAQ

Was ist der groesste Fehler bei Disaster Recovery?
Den DR-Plan nie getestet zu haben. Ein untesteter Plan ist kein Plan. Im Ernstfall unter Druck und ohne vorherige Erfahrung ist Chaos vorprogrammiert.

Fazit

Disaster Recovery ist kein IT-Thema, es ist ein Geschaeftsthema: Was kostet ein Tag Betriebsausfall? Der DR-Plan kostet einen Bruchteil davon.

Disaster Recovery Planung fuer KMU in Heidelberg, Mannheim und der Rhein-Neckar-Region. Beratung anfragen.

Artikel teilen

War dieser Artikel hilfreich?

Dein Feedback hilft uns, bessere Inhalte zu erstellen.

Kommentar hinterlassen

Verwandte Artikel