Der Admin-Leitfaden: Disaster Recovery 2025

Lesezeit
5 Minuten
Bis jetzt gelesen

Der Admin-Leitfaden: Disaster Recovery 2025

17.11.2025 - 11:28
Veröffentlicht in:

Katastrophen passieren nicht nur durch Feuer, Überschwemmungen und Stromausfälle. Immer häufiger sind deren Auslöser auch Malware, Ransomware, Fehlkonfigurationen und Cloudausfälle. Dieser Admin-Leitfaden gibt daher eine praxisnahe Anleitung, um IT-Systeme nach ihrem Ausfall schnell, sicher und nachweisbar wiederherzustellen: unabhängig der Umgebung, Plattform und Branche.

1. Was ist Disaster Recovery?

Disaster Recovery (DR), übersetzt auch Notfallwiederherstellung oder Katastrophenwiederherstellung, bezeichnet das Wiederherstellen der IT-Infrastruktur, der Daten und der Anwendungen nach einem schwerwiegenden Ausfallereignis. Dazu zählen Hardwarefehler, Cyberangriffe und Naturkatastrophen. DR zielt darauf ab, betriebliche Abläufe schnell wiederherzustellen, um Ausfallzeiten zu minimieren, Datenverluste zu vermeiden und einen ungestörten Geschäftsbetrieb zu sicherzustellen. 

1.1 Was sind Grundbegriffe der Disaster Recovery?

Diese Vergleichstabelle samt realitätsnahen Beispielen gibt einen guten Überblick über die Grundbegriffe der Disaster Recovery:

Tabellarischer Vergleich von Grundbegriffen der Disaster Recovery (DR)

Praxisbeispiel: Ein Online-Händler stuft seinen Zahlungsdienst als kritisch ein (RTO: eine Stunde, RPO: fünf Minuten), während der Produktkatalog sechs Stunden Ausfall toleriert.

1.2. Wie wirkt ein Disaster-Recovery-Plan?

Ein Disaster-Recovery-Plan (DRP) definiert detaillierte Anweisungen dazu, wie auf ein Ereignis reagiert und Systeme wiederhergestellt werden sollen. Beinhalten sollten er in jedem Fall regelmäßiges Datensichern an externen und/oder cloudbasierten Standorten. Um sicherzustellen, dass ein DRP funktioniert, sollte er regelmäßig getestet werden: Denn ein Disaster-Recovery-Plan ist nur so gut wie sein letzter Test. Entsprechend der aus den Tests gewonnenen Erkenntnisse sollte ein Disaster-Recovery-Plan regelmäßig angepasst werden.

Zum Testen eignen sich insbesondere diese drei Testtypen:

  1. Tabletop: Durchspielen verschiedener Szenarien im Meeting.
  2. Simulation: Simulieren und messen eines Teil-Failovers.
  3. Full-Failover: Real Wiederherstellen auf Ersatzsystemen.

Praxistipp: Verplanen Sie vierteljährliche Tests im Kalender und führen Sie nach jedem Test eine „Post-Mortem“-Analyse durch.

1.3. Wie hat sich Disaster Recovery 2025 verändert?

2025 war in der Disaster Recovery geprägt von Cloud-first-Ansätzen, von hybriden Infrastrukturen und von  zunehmenden Ransomware-Angriffen. Diese Entwicklungen haben klassische Backupstrategien überholt. Daher bedeutet DR inzwischen vermehrt auch die Replikation und die Automatisierung.

Praxistipp: Erstellen Sie für jede kritische Anwendung einen Disaster-Recovery-Plan mit detaillierten Anweisungen zur optimalen Notreaktion auf ein Ausfallereignis mit diesen Kriterien:

  1. Systemname und Owner
  2. Speicherort der Backups
  3. RTO (Recovery Time Objective)
  4. RPO (Recovery Point Objective)
  5. Kommunikationswege
  6. Notfallkontakte

2. Wie gelingt eine schnelle Risikoanalyse samt Asset-Mapping?

Eine effektive Risikoanalyse beginnt mit einer gründlichen Inventarisierung, denn sie bildet das unverzichtbare Fundament jeder weiteren Bewertung. Automatisierte Tools erzielen dabei schnelle, verlässliche Ergebnisse. Zudem schaffen sie die Ausgangsposition für ein präzises Asset-Mapping, das alle Abhängigkeiten, die Kritikalität einzelner Systeme und potenzielle Schwachstellen sichtbar macht. Auf dieser strukturierten Grundlage lässt sich das Risiko realistisch bewerten, klar priorisieren und unmittelbar in konkrete Maßnahmen überführen. In kurzer Zeit entsteht dadurch eine belastbare Entscheidungsgrundlage für Disaster Recovery, Business Continuity und Sicherheitsstrategien.

2.1. Checkliste: Was gehört ins Inventar?

✅ Physische und virtuelle Server,
✅ Container und Kubernetes-Cluster,
✅ Datenbanken und Storage-Systeme,
✅ Netzwerkgeräte, wie Firewalls und Switches,
✅ DNS, Loadbalancer und  VPN,
✅ SaaS-Dienste und API-Abhängigkeiten,
✅ Schlüssel, Zertifikate und Secrets.

Praxisbeispiel: Ein Finanzdienstleister nutzt ein automatisches Discovery-Tool, das jede Nacht CMDB-Einträge (Configuration Management Database) aktualisiert und Änderungen versioniert in GitLab speichert. Die CMDB-Einträge sind in einer zentralen Datenbank gespeichert und beinhalten Informationen über Konfigurationselemente (CIs, Configuration Items) zum Verwalten von IT-Services.

3. Wie unterscheiden sich Recovery-Strategien?

Im nächsten Schritt gilt es, die passende Recovery-Strategie zu wählen. Diese Tabelle vergleicht beliebte Strategien und zeigt praxisnahe Beispiele, sie einzusetzen:

Tabellarischer Vergleich häufiger Ansätze für Recoverystrategien und Architekturentscheidungen.

Praxistipp: Setzen Sie bei Cloudworkloads auf Multi-Region-Designs mit orchestriertem Failover. Anbieter wie Azure Site Recovery und AWS Elastic DR bieten APIs für automatisierte Tests.

4. Wie schafft richtiges Backup Datenintegrität?

Backup gemäß der 3-2-1-Grundregel stellt sicher, dass Daten über ihren gesamten Lebenszyklus hinweg korrekt, vollständig, konsistent und vertrauenswürdig sind. Dadurch sind sie geschützt vor unbefugtem Ändern, Löschen und Beschädigen. Auch ihre Genauigkeit bleibt dadurch gewahrt.

Die 3-2-1-Grundregel beinhaltet:

  • Drei Kopien der Daten
  • Auf wenigstens zwei verschiedene Speichermedien, wobei
  • Mindestens eine Kopie außerhalb des Netzwerks liegt: physisch getrennt (air-gapped) oder unveränderlich (immutable).

Praxistipps:

  1. Planen Sie wöchentliche Restore-Tests und dokumentieren Sie deren Erfolg und Dauer.
  2. Nutzen Sie immutable Storage (wie S3 Object Lock, WORM).
  3. Schützen Sie Backup-Systeme durch getrennte Authentifizierung (MFA).

5. Wie gelingt das Wiederherstellen virtueller Umgebungen?

Um ausgefallene Server oder virtuelle Maschinen (VMs) schnell und zuverlässig wiederherzustellen, gibt es je nach Umgebung verschiedene Strategien:

  • VMware / Hyper-V: Diese Plattformen können Snapshots anlegen. Mit den Momentaufnahmen des Systems lässt sich der Zustand des Zeitpunkts der letzten Momentaufnahme zurückholen. Beispiel: Wenn ein Update schiefgeht, kann man mit einem Snapshot alles auf den vorherigen Stand zurücksetzen.
  • Kubernetes: Da die Anwendungen hier in Containern betrieben werden, ist es wichtig, regelmäßig Backups von etcd (dem zentralen Datenspeicher) und Snapshots von Persistent Volumes (den gespeicherten Daten) zu machen.
  • Cloud: In Cloudumgebungen lässt sich die gesamte Infrastruktur über Code (Infrastructure-as-Code, kurz IaC) wiederherstellen, etwa mit Terraform oder Ansible.

Beispiel:
terraform init
terraform apply -var-file="recovery.tfvars"

Praxistipp: Speichern Sie die Wiederherstellungsdateien (IaC-States) außerhalb der Produktionsumgebung, etwa in einem isolierten, sicheren Git-Repository.

6. Welche Rolle spielen Netzwerk und DNS?

Sind Netzwerke oder DNS-Einträge fehlerhaft, scheitert oft die gesamte Wiederherstellung. Damit die Notfallwiederherstellung funktioniert, muss auch das Netzwerk sauber konfiguriert sein: insbesondere der DNS-Dienst, der Namen wie „meinefirma.de“ in IP-Adressen übersetzt.

Checkliste für DNS-Failover:
✅ Zeit bis zur Aktualisierung (TTL) auf 60 Sekunden setzen.
✅ Gesundheitsprüfungen (Health Checks) aktivieren.
✅ Automatisches Umschalten testen.
✅ Rückfallstrategie (Rollback-Plan) dokumentieren.

Praxistipp: Planen Sie BGP- oder Anycast-Mechanismen für Hochverfügbarkeit bei besonders kritischen Diensten wie VPN, DNS oder CDN. Dadurch aktivieren Sie bei einem Ausfall automatisch andere Server.

7. Ransomware: Was tun, wenn jede Minute zählt?

Ein Ransomware-Angriff ist der Albtraum jeder Organisation. Verschlüsseln Angreifer Daten durch Ransomware, zählt jede Minute. Jetzt gilt es, Ruhe zu bewahren und systematisch vorzugehen. Die ersten Schritte sind entscheidend:

  1. Befallene Systeme sofort isolieren / vom Netzwerk trennen
  2. Snapshots sichern: zum Beweis und zur Analyse
  3. Backups auf Veränderungen überprüfen.
  4. Systeme nur aus geprüften, verifizierten Backups wiederherstellen.
  5. Kommunikationsplan aktivieren: intern und extern.

Praxisbeispiel: Ein mittelständisches Unternehmen identifiziert durch Immutable Backups den sauberen Wiederherstellungspunkt binnen zwei Stunden. Dadurch bleibt die Ausfallzeit (Downtime) unter sechs Stunden.

8. Was tun bei SaaS- und Third-Party-Recovery?

Eine häufige Schwachstelle: SaaS-Daten liegen beim Anbieter, doch Sie tragen die Verantwortung. Viele Organisationen nutzen Clouddienste wie Microsoft 365 oder Salesforce. Doch auch dort sind Sie für Ihre Daten verantwortlich, nicht die Anbieter. Werden Sie Ihrer Verantwortung in drei Schritten gerecht:

  1. Prüfen Sie Exportmöglichkeiten der Daten (etwa via API, CSV und API-Snapshot).
  2. Dokumentieren Sie die Daten von Kontaktpersonen und Notfallverfahren.
  3. Dokumentieren Sie Service Level Agreements (SLA) und Exit-Klauseln in Verträgen für den Ernstfall.

9. Automatisierung und Runbooks

Ein Runbook ist eine Art Drehbuch für Administratoren mit dokumentierten, getesteten Abläufen. Es beschreibt detailliert, automatisierbar und wiederholbar, was in welcher Reihenfolge zu tun ist. Hier ein Beispiel:

runbook:
name: DB Restore
trigger: "Database corruption alert"
steps:
    - shutdown db01
    - restore snapshot 2025-10-27
    - verify checksum
    - restart db01
rollback: "restore previous snapshot"

Praxistipp: Speichern Sie Runbooks mit Versionskontrolle (etwa in Git) und überprüfen Sie diese regelmäßig bei Änderungen der Infrastruktur oder von Prozessen.

10. Wie unterstützt KI Disaster-Recovery-Prozesse?

KI-Systeme wie Large Language Models (LLMs) können DR-Teams entlasten, etwa indem sie automatisch Checklisten und Reports erstellen, lange Incident-Log-Dateien zusammenfassen und Wiederherstellungspläne/Playbooks automatisiert vorschlage.

Beachten Sie jedoch, dass LLMs halluzinieren, wenn sie ohne aktuelle Daten arbeiten. Daher ersetzt KI keine Fachleute und Ergebnisse sollten immer von qualifizierten Menschen geprüft werden.

Praxisbeispiel: Ein Admin-Team nutzt ein internes LLM mit RAG-Anbindung auf DR-Dokumente: Es erstellt nach jedem Testlauf automatisch Post-Mortems, lernt aus den Protokollen und macht Verbesserungsvorschläge für die Wiederherstellungsprozesse.

11. Compliance, Dokumentation und Reporting

Disaster Recovery ist auch eine Frage der Regeltreue. Viele Branchen unterliegen Vorgaben und Standards wie:

  • ISO 22301: Standard für Business Continuity Management
  • NIS2: EU-Richtlinie für Netz- und Informationssicherheit
  • DORA (Digital Operational Resilience Act): Digitale Resilienz für Finanzunternehmen
  • BSI-IT-Grundschutz: Deutscher Sicherheitsrahmen

Praxistipp: Verknüpfe jedes DR-Dokument mit der passenden Norm / Compliance-Anforderung, etwa „Backup-Policy → ISO 22301 §8.4“.

12. Beispielszenarien

Szenario A: Regionale Cloudstörung

  • Trigger: Region fällt aus
  • Reaktion: Automatischer Failover per DRaaS / Wechsel auf andere Cloudregion
  • Ergebnis: Lediglich 90 Sekunden Ausfallzeit (Downtime)

Szenario B: Ransomware-Angriff

  • Trigger: Erkennen verdächtiger Dateiverschlüsselung
  • Aktion: Umgehende Isolation, forensische Analyse, Restore aus sauberem / immutable Backup
  • Ergebnis: Datenverlust unter 10 Minuten, Wiederanlauf nach 4 Stunden

Szenario C: DNS-Hijack/-Manipulation

  • Trigger: Erkennen externer Manipulation
  • Aktion: Rollback, Split-DNS aktiviert, Kunden informiert
  • Ergebnis: Keine Datenverluste, keine Kundendaten kompromittiert

13. Checklisten und Vorlagen

Für einen strukturierten DR-Prozess helfen zentrale Dokumente, wie:

  • Eine Kurzübersicht Disaster Recovery (PDF)
  • Eine Vorlage für Runbooks (etwa in Markdown/YAML)
  • Eine Backup- und Restore-Checkliste
  • Ein Krisenkommunikationsplan
  • Eine Vorlage für Testberichte (Test-Report-Template)
  • Ein Terraform-Snippet zum automatisierten Wiederherstellen (Test-Report-Template)
  • Ein DNS-Failover-Skript

Praxistipp: Legen Sie alle Vorlagen in einem zentralen, versionierten Git-Repository ab. Dadurch kann das ganze DR-Team darauf zugreifen und Änderungen nachvollziehen.

Hier eine beispielhafte DR-Roadmap für die ersten 90 Tage:

Tabellarische Übersicht als Roadmap für Ziele und Maßnahmen der ersten 90 Tage.

14. Fazit

Disaster Recovery ist ein dauerhafter Prozess, kein einmaliges Projekt. Backups zu haben ist das eine, entscheidend ist aber auch, wie schnell Sie im Notfall in der Lage sind, sie zu aktivieren und Ausfallzeiten so gering wie möglich zu halten. Mit automatisierten Tests, klaren Abläufen und transparenter Kommunikation bilden Sie messbare Resilienz, schaffen Vertrauen und echte Ausfallsicherheit.

15. Weiterführende Inhalte zu Disaster Recovery

Weiterführende, praxisnahe Inhalte zu Disaster Recovery lesen Sie in unserer aktuellen Ausgabe 11/2025 zum Thema und hier:

Bleiben Sie auf dem neuesten Stand der professionellen System- und Netzwerkadministration und bestellen Sie jetzt das IT-Administrator Magazin als Einzelheft oder im Abo. Lesen Sie das IT-Administrator Magazin zusätzlich bequem als E-Paper auf dem PC und auf Ihren mobilen Endgeräten, inklusive Zugang zum digitalen Heftarchiv mit allen Heft-PDFs zum Download.