← Zurück zu Backup & Cronjobs
🚨

Disaster Recovery

Wenn alles schiefgeht: Wie du deine Systeme aus dem Backup wiederherstellst.

⏱️ 30 Minuten 📊 Fortgeschritten
🚨

Ruhe bewahren

Im Ernstfall ist Panik der größte Feind. Ein dokumentierter, getesteter Plan macht den Unterschied. Lies diese Seite JETZT - nicht erst wenn es brennt.
💥 Schritt 0: Was ist ein Disaster? +

Szenarien, die eine vollständige Wiederherstellung erfordern:

Hardware-Ausfall

Server tot, Festplatte defekt, RAID degradiert

Ransomware

Daten verschlüsselt, System kompromittiert

Physischer Verlust

Brand, Wasserschaden, Diebstahl

Menschlicher Fehler

rm -rf /, DROP DATABASE, fatales Update

💡

RTO und RPO

RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung maximal dauern?
RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? (z.B. max. 24h)
📋 Schritt 1: Disaster Recovery Plan erstellen +

Ein DR-Plan sollte BEVOR es passiert existieren und folgendes enthalten:

DR-Plan Template:

  1. Kontaktliste: Wer muss informiert werden?
  2. Zugriff auf Backups: Wo liegen sie, wie komme ich ran?
  3. Prioritäten: Welche Systeme zuerst?
  4. Hardware-Beschaffung: Woher bekomme ich Ersatz?
  5. Schritt-für-Schritt Restore: Für jedes System
  6. Verifizierung: Wie prüfe ich, ob alles läuft?
  7. Kommunikation: Wer informiert Kunden/User?
⚠️

Offline-Kopie des Plans!

Der DR-Plan muss auch ohne funktionierenden Server zugänglich sein. Ausgedruckt, im Passwort-Manager, auf dem Handy - NICHT nur auf dem betroffenen Server.
🖥️ Schritt 2: Bare-Metal Recovery +

Wiederherstellung auf komplett neuer Hardware:

Schritt 1: Neuen Server vorbereiten

  • OS installieren (gleiche Version wie vorher!)
  • Netzwerk konfigurieren
  • SSH-Zugang einrichten
  • Backup-Tools installieren (restic, borg, etc.)

Schritt 2: Backup-Zugriff herstellen

bash 
# Passwort bereithalten (aus Passwort-Manager/Safe)
export RESTIC_PASSWORD="..."

# Remote-Repository mounten
restic -r sftp:user@backup-server:/repo mount /mnt/restore

# Oder: Lokales Backup-Medium anschließen
mount /dev/sdb1 /mnt/backup

Schritt 3: System-Konfiguration wiederherstellen

bash 
# /etc wiederherstellen (Konfigurationsdateien)
restic restore latest --target / --include /etc

# Wichtig: Nicht blind alles überschreiben!
# Besser: In temporäres Verzeichnis und selektiv kopieren
restic restore latest --target /tmp/restore --include /etc
cp -p /tmp/restore/etc/nginx/* /etc/nginx/
cp -p /tmp/restore/etc/postgresql/* /etc/postgresql/

Schritt 4: Daten wiederherstellen

bash 
# Home-Verzeichnisse
restic restore latest --target / --include /home

# Webseiten
restic restore latest --target / --include /var/www

# Docker Volumes
restic restore latest --target / --include /var/lib/docker/volumes

Schritt 5: Datenbanken wiederherstellen

bash 
# PostgreSQL
sudo -u postgres createdb meine_datenbank
sudo -u postgres pg_restore -d meine_datenbank /tmp/restore/backup/postgres.dump

# MySQL/MariaDB
mysql meine_datenbank < /tmp/restore/backup/mysql.sql

# MongoDB
mongorestore --db meine_datenbank /tmp/restore/backup/mongodb/
📦 Schritt 3: VM/Container Recovery (Proxmox) +

Wiederherstellung von VMs und Containern aus Proxmox Backup Server:

bash 
# Backup-Storage in Proxmox hinzufügen (falls nicht vorhanden)
# Datacenter > Storage > Add > Proxmox Backup Server

# Via GUI:
# 1. VM/Container auswählen > Backup > Restore
# 2. Backup-Zeitpunkt wählen
# 3. Ziel-Storage und VM-ID angeben
# 4. "Start after restore" aktivieren

# Via CLI:
# VM wiederherstellen
qmrestore /mnt/pbs/dump/vzdump-qemu-100-2026_01_15.vma 100

# Container wiederherstellen
pct restore 101 /mnt/pbs/dump/vzdump-lxc-101-2026_01_15.tar.zst
✅

Proxmox Backup Server Vorteil

PBS speichert Backups dedupliziert und verschlüsselt. Wiederherstellung auch einzelner Dateien aus VM-Backups möglich - ohne die ganze VM zu starten.
🦠 Schritt 4: Ransomware Recovery +
🚨

STOP - Bevor du irgendetwas tust

Bei Ransomware: Sofort alle betroffenen Systeme vom Netzwerk trennen! Nicht den Server neu starten. Forensik könnte wichtig sein.

1. Isolation

  • Netzwerkkabel ziehen / WLAN deaktivieren
  • Andere Systeme im Netzwerk prüfen
  • Backup-Systeme isolieren (falls noch nicht betroffen)

2. Bewertung

  • Welche Systeme sind betroffen?
  • Ist das Offsite-Backup sauber? (Separater Zugang prüfen!)
  • Wann war die letzte saubere Sicherung?

3. Saubere Umgebung aufbauen

  • Komplett neue Server-Installation (nicht reparieren!)
  • Alle Passwörter ändern
  • SSH-Keys neu generieren
  • Restore aus bekannt sauberem Backup

4. Einfallstor finden

  • Wie kam die Ransomware rein?
  • Sicherheitslücke schließen vor Wiederinbetriebnahme
  • Ggf. externe Hilfe (Incident Response Team)
⚠️

Niemals Lösegeld zahlen

1) Es gibt keine Garantie, dass du die Daten zurückbekommst. 2) Du finanzierst Kriminelle. 3) Du markierst dich als "zahlt" für zukünftige Angriffe.
✅ Schritt 5: Post-Recovery Checkliste +

Nach der Wiederherstellung - nicht vergessen:

Post-Recovery Checkliste:

  • Alle Services laufen und sind erreichbar
  • Datenbank-Integrität geprüft
  • SSL-Zertifikate gültig
  • Cronjobs laufen wieder
  • Backup-Jobs laufen wieder
  • Monitoring aktiv und grün
  • Firewall-Regeln korrekt
  • Alle Passwörter geändert (bei Kompromittierung)
  • Incident dokumentiert (Lessons Learned)
  • Betroffene Parteien informiert
💡

Post-Mortem

Nach jedem Incident: Was ist passiert? Warum? Wie verhindern wir es in Zukunft? Diese Analyse ist genauso wichtig wie die Wiederherstellung selbst.

Häufige Fragen

Wie schnell muss ich reagieren? ▸
Bei Ransomware: Sofort isolieren. Bei Hardware-Ausfall: Ruhe bewahren, Plan befolgen. Die Geschwindigkeit hängt von deinem RTO ab - wie lange kann dein Business ohne die Systeme?
Sollte ich die Polizei informieren? ▸
Bei Ransomware und anderen Cyberangriffen: Ja. Auch wenn die Chancen gering sind, hilft es bei der Bekämpfung. In manchen Fällen (DSGVO-Breach) bist du sogar verpflichtet.
Wann brauche ich professionelle Hilfe? ▸
Wenn: 1) Unklar ist, wie der Angreifer reinkam, 2) Verdacht auf Datenabfluss besteht, 3) Du die Recovery nicht selbst sicher durchführen kannst, 4) Rechtliche Fragen aufkommen (Meldepflichten, Haftung).
Wie oft sollte ich den DR-Plan testen? ▸
Mindestens jährlich ein vollständiger DR-Test. Einzelne Restore-Tests häufiger (quartalsweise). Nach jeder größeren Änderung an der Infrastruktur den Plan aktualisieren.
← Zurück: Best Practices Zur Backup Übersicht →