Disaster Recovery Plan erstellen: Vom Notfall zurück zum Normalbetrieb

Was ein Disaster Recovery Plan ist und was nicht

Ein Disaster Recovery Plan (DR-Plan) beschreibt, wie du nach einem schwerwiegenden IT-Ausfall deine Systeme, Anwendungen und Daten wiederherstellst. Er beantwortet die Frage: Was tun wir, wenn unsere IT-Infrastruktur ganz oder teilweise ausfällt, und wie kommen wir in einen funktionsfähigen Zustand zurück?

Der Begriff wird oft mit Business Continuity Plan (BCP) verwechselt oder synonym verwendet. Das ist nicht korrekt. Der BCP betrachtet die Geschäftsprozesse und fragt: Wie halten wir den Geschäftsbetrieb aufrecht, auch wenn Systeme ausfallen? Der DR-Plan ist der technische Teil des BCP und konzentriert sich auf die IT-Wiederherstellung. Ein BCP kann Maßnahmen enthalten wie "Mitarbeiter arbeiten vorübergehend mit Papierformularen", während der DR-Plan beschreibt, wie das ERP-System wieder online kommt.

Ebenso ist der DR-Plan kein Incident-Response-Plan. Der Incident-Response-Plan beschreibt, wie du einen Sicherheitsvorfall erkennst, eindämmst und analysierst. Der DR-Plan setzt dort an, wo der Incident-Response-Plan endet: Die Bedrohung ist eingedämmt, jetzt geht es um die Wiederherstellung.

In der Praxis greifen alle drei Pläne ineinander. Der Incident-Response-Plan stellt fest, dass ein Ransomware-Angriff stattgefunden hat, und leitet Sofortmaßnahmen ein. Der DR-Plan beschreibt, wie die verschlüsselten Systeme aus Backups wiederhergestellt werden. Der BCP regelt, wie der Geschäftsbetrieb während der Wiederherstellung aufrechterhalten wird.

Warum jedes Unternehmen einen DR-Plan braucht

Es gibt drei treibende Kräfte, die einen DR-Plan notwendig machen: regulatorische Anforderungen, wirtschaftliche Realität und die zunehmende Abhängigkeit von IT-Systemen.

Regulatorische Anforderungen

NIS2 Artikel 21 fordert in Absatz 2 Buchstabe c explizit die "Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement". Das ist keine vage Empfehlung, sondern eine konkrete Pflicht für alle Unternehmen, die unter NIS2 fallen.

Der BSI IT-Grundschutz widmet dem Thema den Baustein DER.4 (Notfallmanagement). Er fordert unter anderem ein Notfallvorsorgekonzept, ein Notfallhandbuch mit konkreten Handlungsanweisungen und regelmäßige Tests und Übungen.

ISO 27001 adressiert das Thema in Annex A, Kontrolle A.5.30 (ICT readiness for business continuity). Die Kontrolle verlangt, dass die IT-Bereitschaft geplant, implementiert, aufrechterhalten und getestet wird.

Wirtschaftliche Realität

Die Kosten eines IT-Ausfalls sind für die meisten Unternehmen höher, als sie vermuten. Eine einfache Rechnung: Wenn ein Unternehmen mit 100 Mitarbeitern einen Jahresumsatz von 20 Millionen Euro macht, entspricht ein Tag Stillstand einem Umsatzausfall von rund 55.000 Euro. Dazu kommen Kosten für Überstunden, externe Dienstleister, Vertragsstrafen und Reputationsschäden, die sich nicht in einfachen Zahlen ausdrücken lassen.

Ransomware-Angriffe führen im Durchschnitt zu 21 Tagen Betriebsunterbrechung, wenn kein funktionierender DR-Plan existiert. Mit einem getesteten DR-Plan und sauberen Backups lässt sich diese Zeit auf wenige Tage reduzieren.

IT-Abhängigkeit

Kaum ein Geschäftsprozess funktioniert heute ohne IT. Wenn das ERP-System ausfällt, können keine Aufträge bearbeitet, keine Rechnungen geschrieben und keine Lieferungen geplant werden. Wenn das E-Mail-System ausfällt, bricht die interne und externe Kommunikation zusammen. Wenn das Active Directory ausfällt, kann sich niemand mehr anmelden. Die Frage ist nicht, ob ein solcher Ausfall eintritt, sondern wann und wie gut du darauf vorbereitet bist.

Die Bausteine eines DR-Plans

Ein vollständiger DR-Plan besteht aus mehreren Abschnitten, die zusammen ein konsistentes Ganzes ergeben. Hier sind die wesentlichen Bausteine.

1. Geltungsbereich und Zielsetzung

Definiere, welche Systeme und Standorte der DR-Plan abdeckt. Nicht jedes System braucht denselben DR-Plan. Ein internes Wiki hat andere Wiederherstellungsanforderungen als das ERP-System. Lege fest, welche Szenarien der Plan abdeckt: Hardware-Ausfall, Ransomware, Naturkatastrophen, Ausfall des Cloud-Providers, menschliches Versagen.

2. Rollen und Verantwortlichkeiten

Benenne die Personen, die im Ernstfall Entscheidungen treffen und Maßnahmen umsetzen. Jede Rolle braucht mindestens eine Stellvertretung. Die typischen Rollen in einem DR-Szenario sind der DR-Koordinator (leitet den Wiederherstellungsprozess, koordiniert alle Beteiligten), die IT-Wiederherstellungsteams (führen die technischen Wiederherstellungsmaßnahmen durch), der Kommunikationsverantwortliche (informiert Geschäftsleitung, Mitarbeiter, Kunden und bei Bedarf Behörden) und der Eskalationskontakt zur Geschäftsleitung (trifft Entscheidungen, die über die Befugnisse des DR-Teams hinausgehen, z.B. die Beauftragung externer Forensiker).

Zu jeder Rolle gehören aktuelle Kontaktdaten: Mobilnummer, private E-Mail-Adresse (die Firmen-E-Mail funktioniert im Notfall möglicherweise nicht) und die Erreichbarkeit am Wochenende. Diese Kontaktliste muss außerhalb der betroffenen IT-Systeme verfügbar sein, also ausgedruckt und an einem bekannten Ort aufbewahrt.

3. Inventar der kritischen Systeme

Liste alle IT-Systeme auf, die der DR-Plan abdeckt, und ordne jedem System folgende Informationen zu:

• Systemname und Funktion: z.B. "ERP-System SAP Business One, Auftragsabwicklung und Rechnungswesen"
• RTO (Recovery Time Objective): Maximale tolerierbare Ausfallzeit. Wie lange darf das System maximal offline sein?
• RPO (Recovery Point Objective): Maximaler tolerierbarer Datenverlust. Wie viele Stunden oder Minuten an Daten dürfen verloren gehen?
• Abhängigkeiten: Welche anderen Systeme müssen zuerst laufen, damit dieses System funktioniert? (z.B. Active Directory, DNS, Datenbankserver)
• Backup-Standort und -Methode: Wo liegen die Backups und wie werden sie erstellt?
• Wiederherstellungsverfahren: Kurzreferenz auf die detaillierte Wiederherstellungsanleitung
• Verantwortlicher: Wer führt die Wiederherstellung durch?

4. Wiederherstellungsreihenfolge

Die Reihenfolge der Wiederherstellung ist einer der kritischsten Aspekte des DR-Plans und wird häufig unterschätzt. Du kannst nicht einfach alle Systeme gleichzeitig wiederherstellen, weil sie voneinander abhängen.

Eine typische Wiederherstellungsreihenfolge für ein mittelständisches Unternehmen sieht so aus:

Phase 1 (Infrastruktur-Basis, 0-4 Stunden): Netzwerk-Infrastruktur (Firewalls, Switches, Router), Virtualisierungsplattform (VMware, Hyper-V, Proxmox), Storage-Systeme.

Phase 2 (Kerndienste, 4-8 Stunden): Active Directory und DNS, DHCP, Zertifizierungsstelle (falls vorhanden), Monitoring-System (damit du den Fortschritt der weiteren Wiederherstellung überwachen kannst).

Phase 3 (Geschäftskritische Anwendungen, 8-24 Stunden): Datenbankserver, ERP-System, E-Mail-System, Fileserver mit den wichtigsten Freigaben.

Phase 4 (Wichtige Anwendungen, 24-48 Stunden): Fachanwendungen, Intranet, Zeiterfassung, Druckserver.

Phase 5 (Nachrangige Systeme, 48-72 Stunden): Entwicklungs- und Testumgebungen, Archivierungssysteme, nicht kritische Dienste.

Diese Zeitangaben sind Beispiele. Deine tatsächlichen Zeiten hängen von der Größe deiner Umgebung, der Backup-Geschwindigkeit und den verfügbaren Ressourcen ab.

5. Detaillierte Wiederherstellungsanleitungen

Für jedes kritische System brauchst du eine Schritt-für-Schritt-Anleitung, die so detailliert ist, dass ein kompetenter IT-Mitarbeiter sie auch unter Stress ausführen kann, selbst wenn er das System nicht im Detail kennt. Im Notfall ist möglicherweise nicht die Person verfügbar, die das System normalerweise betreut.

Eine gute Wiederherstellungsanleitung enthält die Voraussetzungen (welche Hardware, Software, Lizenzen und Zugangsdaten werden benötigt), die konkreten Schritte (mit Screenshots oder Kommandozeilen-Befehlen), die Verifikation (wie prüfst du, ob die Wiederherstellung erfolgreich war) und bekannte Probleme (Fallstricke, die bei früheren Tests aufgefallen sind, und deren Lösung).

6. Kommunikationsplan

Im Disaster-Fall müssen verschiedene Stakeholder informiert werden. Der Kommunikationsplan definiert, wer wann über welchen Kanal informiert wird.

Die Geschäftsleitung muss sofort informiert werden, sobald ein DR-Szenario eintritt. Mitarbeiter brauchen klare Anweisungen, was sie tun sollen (und was nicht). Kunden müssen informiert werden, wenn Dienstleistungen beeinträchtigt sind. Bei personenbezogenen Daten greift die DSGVO-Meldepflicht an die Aufsichtsbehörde (72 Stunden). NIS2 fordert eine Erstmeldung an das BSI innerhalb von 24 Stunden.

Lege für jede Stakeholder-Gruppe Textvorlagen bereit, die im Notfall nur noch angepasst werden müssen. Im Stress vergisst man leicht wichtige Informationen oder formuliert unglücklich.

7. Externe Dienstleister und Verträge

Dokumentiere alle externen Dienstleister, die du im DR-Fall benötigst: Systemhäuser, Cloud-Provider, Hardware-Lieferanten, Forensik-Dienstleister, Rechtsanwälte mit IT-Expertise. Zu jedem Dienstleister gehören Kontaktdaten (Notfall-Hotline, nicht nur die reguläre Support-Nummer), Vertragsnummern und SLA-Zeiten, die Leistungen, die im Vertrag enthalten sind, und die Eskalationspfade.

Prüfe vorab, welche SLAs deine Dienstleister im Notfall tatsächlich einhalten können. Ein SLA von "Reaktionszeit 4 Stunden" bedeutet nicht, dass das Problem in 4 Stunden gelöst ist. Es bedeutet, dass sich jemand innerhalb von 4 Stunden meldet.

DR-Plan erstellen: Schritt für Schritt

Jetzt wird es konkret. So gehst du vor, um einen DR-Plan von Grund auf zu erstellen.

Schritt 1: Business Impact Analyse (BIA) als Grundlage

Bevor du den DR-Plan schreibst, brauchst du eine Business Impact Analyse. Die BIA beantwortet die Frage: Welche Geschäftsprozesse sind wie kritisch, und welche IT-Systeme unterstützen sie?

Ohne BIA definierst du RTOs und RPOs im luftleeren Raum. Du weißt nicht, ob ein RTO von 24 Stunden für das ERP-System angemessen ist oder ob es 4 Stunden sein müssen, weil der Produktionsprozess ohne ERP-Zugang stillsteht und jede Stunde 10.000 Euro kostet.

Die BIA muss nicht umfangreich sein. Für ein mittelständisches Unternehmen reicht oft eine Tabelle mit den Spalten: Geschäftsprozess, unterstützende IT-Systeme, Auswirkung bei Ausfall (finanziell, operativ, regulatorisch, Reputation), maximal tolerierbare Ausfallzeit und maximal tolerierbarer Datenverlust.

Schritt 2: IT-Systeme inventarisieren und priorisieren

Auf Basis der BIA erstellst du ein Inventar aller IT-Systeme und ordnest sie in Prioritätsklassen ein. Eine bewährte Klassifizierung ist:

Priorität 1 (kritisch): Ausfall führt innerhalb von Stunden zu erheblichen Geschäftsschäden. Beispiele: ERP, Active Directory, E-Mail, Firewall.

Priorität 2 (wichtig): Ausfall ist tolerierbar für 1-3 Tage, danach treten ernsthafte Beeinträchtigungen auf. Beispiele: Fileserver, Zeiterfassung, CRM.

Priorität 3 (normal): Ausfall kann mehrere Tage bis Wochen toleriert werden. Beispiele: Intranet, Archiv, Testumgebungen.

Schritt 3: RTO und RPO für jedes System definieren

Für jedes System aus dem Inventar definierst du RTO und RPO. Diese Werte ergeben sich direkt aus der BIA. Wichtig: RTO und RPO müssen realistisch sein. Ein RTO von 1 Stunde für ein System, dessen Bare-Metal-Restore erfahrungsgemäß 6 Stunden dauert, ist eine Lüge auf Papier. Entweder investierst du in Infrastruktur, die den schnelleren Restore ermöglicht (z.B. Hot-Standby, Replikation), oder du passt das RTO an die Realität an.

Schritt 4: Wiederherstellungsstrategie pro System festlegen

Für jedes System legst du fest, wie es wiederhergestellt wird. Die gängigen Strategien sind:

Restore aus Backup: Das Standardverfahren. Du stellst das System aus dem letzten verfügbaren Backup wieder her. Geeignet für Systeme mit einem RTO von mehreren Stunden und einem RPO, das dem Backup-Intervall entspricht.

Failover auf Standby-System: Du betreibst ein zweites System, das die Daten des Primärsystems repliziert. Im Ausfall schaltest du auf das Standby um. Geeignet für Systeme mit sehr kurzen RTOs (Minuten bis wenige Stunden).

Cloud-basierter DR: Du replizierst deine lokalen Systeme in die Cloud (z.B. Azure Site Recovery, AWS Elastic Disaster Recovery, Zerto). Im Ausfall startest du die Systeme in der Cloud. Geeignet für Unternehmen, die keine zweite Lokation betreiben möchten.

Neuinstallation: Du installierst das System komplett neu und spielst die Daten aus dem Backup ein. Geeignet für unkritische Systeme, deren Konfiguration dokumentiert oder automatisiert ist (z.B. via Ansible, Puppet).

Schritt 5: Detaillierte Runbooks schreiben

Für jedes kritische System schreibst du ein Runbook: eine Schritt-für-Schritt-Anleitung für die Wiederherstellung. Das Runbook muss so geschrieben sein, dass ein qualifizierter IT-Mitarbeiter es auch ohne Vorwissen über das spezifische System ausführen kann.

Ein gutes Runbook beginnt mit einer Checkliste der Voraussetzungen: Welche Hardware muss verfügbar sein? Welche Software-Medien? Welche Lizenzen? Welche Zugangsdaten? Wo liegen die Backups? Dann folgen die konkreten Schritte, nummeriert und eindeutig. Jeder Schritt sollte überprüfbar sein: "Starte den SQL-Server-Dienst und überprüfe im SQL Server Management Studio, ob alle Datenbanken den Status 'Online' haben."

Schritt 6: Den Plan testen

Ein DR-Plan, der nie getestet wurde, ist ein Hoffnungsdokument. Tests decken Probleme auf, die beim Schreiben niemand bedacht hat: Fehlende Zugangsdaten, inkompatible Hardware, falsche Wiederherstellungsreihenfolge, unrealistische Zeitschätzungen.

Es gibt verschiedene Teststufen. Tabletop-Übungen (jährlich) sind Durchsprechübungen, bei denen das DR-Team ein Szenario durchgeht, ohne tatsächlich Systeme wiederherzustellen. Kosten: wenige Stunden. Nutzen: Deckt logische Fehler und fehlende Informationen auf.

Partial-Recovery-Tests (quartalsweise) sind Tests, bei denen einzelne Systeme tatsächlich wiederhergestellt werden, typischerweise in einer isolierten Testumgebung. Kosten: ein halber bis ganzer Tag. Nutzen: Überprüft die technische Funktionsfähigkeit der Runbooks.

Full-Scale-DR-Tests (jährlich) sind Tests, bei denen die gesamte Infrastruktur oder ein wesentlicher Teil davon wiederhergestellt wird, idealerweise an einem alternativen Standort oder in der Cloud. Kosten: 1-3 Tage. Nutzen: Der ultimative Nachweis, dass der DR-Plan funktioniert.

Nach jedem Test erstellst du einen Testbericht, der festhält, was funktioniert hat, was nicht funktioniert hat und welche Korrekturmaßnahmen eingeleitet werden. Diese Berichte sind der Nachweis gegenüber Auditoren, dass du deinen DR-Plan ernst nimmst.

Schritt 7: Den Plan pflegen

Ein DR-Plan ist ein lebendes Dokument. Er muss aktualisiert werden, wenn sich die IT-Landschaft ändert (neue Systeme, abgelöste Systeme, geänderte Abhängigkeiten), wenn Personaländerungen auftreten (neue Verantwortliche, geänderte Kontaktdaten), nach jedem Test (Erkenntnisse einarbeiten), nach jedem realen Vorfall (Lessons Learned einarbeiten) und mindestens einmal jährlich auch ohne konkreten Anlass.

Szenarien: Welche Katastrophen sollte der DR-Plan abdecken?

Ein guter DR-Plan beschränkt sich nicht auf ein einzelnes Szenario. Die häufigsten Szenarien, die du durchdenken solltest, sind:

Ransomware-Angriff: Das wahrscheinlichste Szenario. Alle oder die meisten Systeme sind verschlüsselt. Active Directory ist kompromittiert. Die Wiederherstellung erfordert zunächst eine saubere Umgebung (neues AD oder verifiziertes Backup), bevor die restlichen Systeme wiederhergestellt werden können.

Hardware-Ausfall des zentralen Servers/Storages: Ein Klassiker. Ein einzelnes System fällt aus, die restliche Infrastruktur ist intakt. Die Wiederherstellung erfolgt auf Ersatzhardware oder in einer VM.

Ausfall des Rechenzentrums/Serverraums: Brand, Hochwasser, Stromausfall mit USV-Versagen. Alle lokalen Systeme sind betroffen. Die Wiederherstellung muss an einem alternativen Standort oder in der Cloud erfolgen.

Ausfall eines Cloud-Dienstes: Dein SaaS-Provider hat einen Totalausfall. Hier ist der DR-Plan begrenzt, weil du keine Kontrolle über die Infrastruktur des Providers hast. Der Plan beschreibt Workarounds und alternative Kommunikationswege.

Insider-Sabotage oder menschliches Versagen: Ein Mitarbeiter löscht versehentlich oder absichtlich kritische Daten. Die Wiederherstellung erfolgt aus Backups, aber du musst sicherstellen, dass die Backups nicht ebenfalls betroffen sind.

Praxisbeispiel: DR-Plan für ein 100-Mitarbeiter-Unternehmen

Hier ein realistisches Beispiel, wie ein DR-Plan für ein typisches mittelständisches Fertigungsunternehmen aussehen kann.

Ausgangslage

Das Unternehmen betreibt einen VMware-Cluster mit 15 virtuellen Maschinen (Active Directory, ERP, Fileserver, Datenbankserver, Fachanwendungen), Microsoft 365 für E-Mail und Collaboration, eine On-Premise-Telefonanlage (VoIP) und 100 Windows-Clients. Die Backups liegen lokal auf einem NAS und zusätzlich in der Cloud (Wasabi S3 mit Object Lock) als Immutable Backups.

Priorisierung

Priorität 1 (RTO 4h): Active Directory, DNS, Firewall, ERP-System, Datenbankserver. Priorität 2 (RTO 24h): Fileserver, VoIP-Telefonanlage, Zeiterfassung. Priorität 3 (RTO 72h): Intranet, Entwicklungsumgebung, Druckserver.

Wiederherstellungsstrategie

Bei einem Ransomware-Angriff geht das Unternehmen wie folgt vor: Zunächst isoliert das Incident-Response-Team alle betroffenen Systeme vom Netzwerk. Dann wird eine saubere VMware-Umgebung auf der vorhandenen Hardware aufgesetzt (oder auf Ersatzhardware, falls die primäre Hardware kompromittiert ist). Active Directory wird als erstes aus dem letzten sauberen Backup wiederhergestellt, gefolgt von DNS und DHCP. Nach der Verifikation des AD folgt die Wiederherstellung des ERP-Systems und der Datenbank. Parallel kann Microsoft 365 weiter genutzt werden, da es nicht von der lokalen Infrastruktur betroffen ist.

Die geschätzte Gesamtzeit für die Wiederherstellung der Priorität-1-Systeme beträgt 8 bis 16 Stunden, abhängig von der Größe der Backups und der verfügbaren Hardware.

Häufige Fehler bei DR-Plänen

Der Plan ist zu theoretisch. Er beschreibt Prinzipien, aber keine konkreten Schritte. Im Notfall brauchen die Leute keine Erklärungen, warum Disaster Recovery wichtig ist, sondern eine Liste mit Schritten, die sie abarbeiten können.

Keine Offline-Kopie des Plans. Der DR-Plan liegt auf dem Fileserver, der gerade ausgefallen ist. Oder im Wiki, das auf dem Server läuft, der gerade verschlüsselt wurde. Halte immer eine gedruckte Kopie an einem bekannten Ort bereit und speichere eine digitale Kopie außerhalb der betroffenen Infrastruktur (z.B. als PDF im Cloud-Speicher oder auf einem USB-Stick im Tresor).

Zugangsdaten fehlen oder sind veraltet. Der Plan verweist auf "die Backup-Zugangsdaten aus dem Passwort-Manager", aber der Passwort-Manager läuft auf dem Server, der gerade nicht verfügbar ist. Halte die kritischen Zugangsdaten (Backup-Accounts, Cloud-Admin, Firewall-Admin) in einem versiegelten Umschlag im Tresor.

Die Wiederherstellungsreihenfolge wurde nie getestet. Auf dem Papier klingt es logisch, zuerst AD wiederherzustellen, dann den Datenbankserver, dann das ERP. Aber beim Test stellt sich heraus, dass das ERP eine spezifische DNS-Konfiguration benötigt, die nicht im Standard-AD-Backup enthalten ist. Solche Abhängigkeiten entdeckst du nur durch Tests.

Keine regelmäßige Aktualisierung. Das Unternehmen hat vor zwei Jahren auf eine neue ERP-Version migriert, aber der DR-Plan beschreibt noch die alte Version. Das neue Storage-System hat eine andere Snapshot-Logik, aber die Runbooks verweisen auf die alten Befehle. Ein veralteter DR-Plan ist schlimmer als kein Plan, weil er ein falsches Sicherheitsgefühl erzeugt.

Unterschätzter Zeitbedarf. Der Plan sieht für die Wiederherstellung des Fileservers 2 Stunden vor, aber der Restore von 5 TB aus dem Cloud-Backup dauert bei der verfügbaren Bandbreite 20 Stunden. Miss die tatsächlichen Restore-Zeiten bei Tests und trage sie im Plan ein.

DR-Plan und regulatorische Anforderungen

BSI IT-Grundschutz

Der Baustein DER.4 (Notfallmanagement) fordert unter anderem die Erstellung eines Notfallvorsorgekonzepts, die Definition eines Notfallteams mit klaren Rollen, die Erstellung von Wiederanlaufplänen für kritische Geschäftsprozesse, regelmäßige Notfallübungen und die Auswertung und Nachbereitung von Übungen und realen Notfällen.

NIS2

NIS2 fordert in Artikel 21 Absatz 2 Buchstabe c Maßnahmen zur Aufrechterhaltung des Betriebs, einschließlich Backup-Management und Wiederherstellung nach einem Notfall. Die Umsetzungsverordnung wird voraussichtlich konkretere Anforderungen formulieren, aber ein dokumentierter und getesteter DR-Plan erfüllt den Kern der Anforderung bereits.

ISO 27001

Annex A, Kontrolle A.5.30, fordert die Planung, Implementierung, Aufrechterhaltung und regelmäßige Prüfung der IT-Bereitschaft für die Geschäftskontinuität. Ein DR-Plan ist der zentrale Nachweis dafür.

Werkzeuge und Vorlagen

Du brauchst keine teure Software, um einen DR-Plan zu erstellen. Ein strukturiertes Textdokument (Word oder Markdown) mit klaren Abschnitten reicht aus. Wichtiger als das Format ist der Inhalt.

Hilfreiche Werkzeuge für die Umsetzung sind Veeam Recovery Orchestrator (automatisiert Wiederherstellungsabläufe und testet sie regelmäßig), Zerto (kontinuierliche Replikation mit automatisiertem Failover), Azure Site Recovery (DR in die Azure Cloud) und VMware Site Recovery Manager (Orchestrierung von DR für VMware-Umgebungen).

Für kleinere Umgebungen reicht oft ein manueller Prozess mit gut dokumentierten Runbooks. Die Orchestrierungs-Tools lohnen sich erst ab einer gewissen Umgebungsgröße, typischerweise ab 20 bis 30 virtuellen Maschinen oder wenn die RTO-Anforderungen unter 2 Stunden liegen.

Von der Theorie zur Praxis

Der schwierigste Schritt beim DR-Plan ist nicht das Schreiben, sondern das Anfangen. Viele Unternehmen schieben das Thema vor sich her, weil es aufwändig erscheint und kein unmittelbarer Druck besteht. Bis der Notfall eintritt.

Fang pragmatisch an: Identifiziere deine fünf kritischsten Systeme, definiere RTOs und RPOs, schreibe für jedes System ein Runbook und teste die Wiederherstellung eines Systems. Das dauert keine Wochen, sondern wenige Tage. Danach erweiterst du den Plan schrittweise um die weniger kritischen Systeme.

Ein unvollständiger DR-Plan, der die kritischsten Systeme abdeckt und getestet wurde, ist unendlich wertvoller als ein perfekter Plan, der nie geschrieben wurde. In ISMS Lite kannst du deinen DR-Plan strukturiert dokumentieren, RTO/RPO-Werte pro System festlegen und Testergebnisse für Audits nachweisbar protokollieren.

Weiterführende Artikel

• RPO und RTO richtig definieren: So findest du die passenden Werte
• Bare-Metal-Recovery testen: Vom Totalausfall zur laufenden Maschine
• Wiederanlaufplan erstellen: Schritt für Schritt zum strukturierten Restart
• Business-Impact-Analyse (BIA): Kritische Prozesse identifizieren
• Datensicherung nach BSI: Das 3-2-1-1-0-Prinzip in der Praxis