Disaster-Recovery-Plan erstellen: Leitfaden zur Geschäftskontinuität für KMU

Kurz gesagt: Ein Disaster-Recovery-Plan ist ein schriftliches Dokument, das festlegt, in welcher Reihenfolge, wie schnell und unter wessen Verantwortung kritische Systeme nach Ereignissen wie Serverausfall, Ransomware, Brand oder längerer Unterbrechung wieder in Betrieb genommen werden. Ein guter Plan zeigt sich nicht am Vorhandensein von Backups, sondern daran, dass die Wiederherstellung innerhalb der vereinbarten Zeit getestet wurde.

Viele Unternehmen fühlen sich vorbereitet, weil sie regelmäßig Backups erstellen. In der Krise lauten die entscheidenden Fragen jedoch: Welches System startet zuerst? Von wo, durch wen und in welcher Zeit wird das Backup zurückgespielt? Was sagen wir Kunden und Mitarbeitenden? Dieser Artikel zeigt Schritt für Schritt, wie KMU einen Plan erstellen, der diese Fragen im Voraus beantwortet.

Der Unterschied zwischen Disaster Recovery und Geschäftskontinuität

Die beiden Begriffe werden oft verwechselt. Ein Business-Continuity-Plan beschreibt, wie das gesamte Unternehmen während einer Störung weiterarbeitet (Personal, Räumlichkeiten, Lieferkette, Kommunikation). Ein Disaster-Recovery-Plan ist dessen IT-Teil und legt fest, wie Server, Anwendungen und Daten wiederhergestellt werden. Kleine Unternehmen können beides in einem Dokument zusammenfassen, die IT-Schritte müssen jedoch immer detailliert beschrieben sein.

Schritt 1: Kritische Systeme und Geschäftsauswirkungen ermitteln

Der Plan beginnt mit der Frage, wie groß der Schaden ist, wenn ein bestimmtes System ausfällt. Dies nennt man Business-Impact-Analyse. Für jedes System sollten diese Fragen beantwortet werden:

• Welche Prozesse sind betroffen, wenn dieses System ausfällt (Aufträge, Versand, Rechnungsstellung, Produktion, Buchhaltung)?
• Wie viele Stunden Ausfall sind tolerierbar, und ab wann sind Kunden oder gesetzliche Pflichten betroffen?
• Von welchen anderen Systemen hängt es ab (Datenbank, Active Directory, Internetanbindung, Lizenzserver)?
• Wem gehört das System, und wer ist technisch verantwortlich?

Am Ende dieser Analyse werden die Systeme nach Priorität gruppiert. ERP, Datenbanken und E-Mail stehen meist in der obersten Gruppe, Dateiarchive oder Testumgebungen weiter unten.

Schritt 2: RTO- und RPO-Ziele festlegen

Für jedes kritische System sollten zwei Ziele definiert werden:

• RTO (Recovery Time Objective): Die maximale Zeit, innerhalb der das System nach einem Ausfall wieder laufen muss.
• RPO (Recovery Point Objective): Der maximal akzeptable Datenverlust. Beträgt das RPO eine Stunde, sind mindestens stündliche Backups oder Replikate nötig.

Die folgende Tabelle ist nur ein Beispiel; die Werte sollten anhand der eigenen Business-Impact-Analyse festgelegt werden.

System	Beispiel-RTO	Beispiel-RPO	Begründung
ERP und Datenbank	4 Stunden	1 Stunde	Aufträge, Versand und Rechnungen stehen still
Geschäftliche E-Mail	8 Stunden	4 Stunden	Kommunikation mit Kunden und Lieferanten leidet
Dateiserver	24 Stunden	24 Stunden	Arbeit läuft weiter, einige Dokumente verzögern sich
Unternehmenswebsite	24 Stunden	1 Woche	Inhalte ändern sich selten

Kürzere RTO- und RPO-Ziele bedeuten höhere Kosten. Deshalb werden die Ziele gemeinsam mit der Geschäftsführung festgelegt und nicht vom IT-Team allein.

Schritt 3: Die Backup-Strategie an den Zielen ausrichten

Die Backups müssen das festgelegte RPO erfüllen. Allgemein anerkannt ist die 3-2-1-Regel: mindestens drei Kopien der Daten, auf zwei verschiedenen Medientypen, davon eine Kopie an einem anderen Standort.

• Gegen Ransomware: Mindestens eine Kopie sollte vom Netzwerk getrennt (offline) oder unveränderlich (immutable) sein. Backups im selben Netzwerk und mit denselben Zugangsdaten können zusammen mit allem anderen verschlüsselt werden.
• Für Datenbanken: Statt Dateikopien das datenbankeigene Sicherungsverfahren nutzen und das RPO mit Transaktionsprotokoll-Sicherungen verkürzen. Details finden Sie in unserem Artikel zur SQL-Datenbanksicherung.
• Für Konfigurationen: Auch Firewall-, Switch-, Virtualisierungs- und Anwendungseinstellungen müssen gesichert werden; reine Datensicherungen reichen nicht, um ein System neu aufzubauen.
• Für die Aufbewahrung: Kopien über mehrere Tage und Wochen aufbewahren, um bei spät entdeckter Beschädigung oder einem Angriff auf ein sauberes Backup zurückgreifen zu können.

Schritt 4: Wiederherstellungsszenarien und Schritte beschreiben

Der Plan sollte für wahrscheinliche Ereignisse getrennte Szenarien enthalten, denn jedes wird anders bewältigt:

Hardware- oder Serverausfall

Beschrieben werden die Schritte zum Neuaufbau des Systems auf Ersatzhardware oder in einer Virtualisierungsumgebung, zum Zurückspielen des Backups und zum Start abhängiger Systeme in der richtigen Reihenfolge.

Ransomware-Angriff

Zuerst werden betroffene Systeme vom Netzwerk getrennt, um die Ausbreitung zu stoppen. Vor der Wiederherstellung werden der Einstiegspunkt des Angriffs und das Datum des letzten sauberen Backups ermittelt; sonst kann dieselbe Schwachstelle erneut ausgenutzt werden. Zur Vorbereitung auf Server- und Netzwerkseite lesen Sie unsere Checkliste für Server- und Netzwerkinfrastruktur.

Verlust von Räumlichkeiten oder Anbindung

Festgelegt wird, von wo und mit welchen Werkzeugen die Mitarbeitenden arbeiten, wenn Büro oder Serverraum nicht zugänglich sind, und wie kritische Systeme an einem anderen Standort betrieben werden.

Jedes Szenario sollte Schritte, verantwortliche Person, benötigte Zugangsdaten und erwartete Dauer klar benennen. Gehen Sie nie davon aus, dass die Person, die den Plan geschrieben hat, in der Krise erreichbar ist.

Schritt 5: Rollen, Zugänge und Kommunikation festlegen

• Schriftlich festhalten, wer die Krise ausruft und wer Entscheidungen trifft.
• Kontaktdaten von Backup-Verantwortlichem, Systemadministrator und externen Dienstleistern aktuell halten.
• Administratorpasswörter, Lizenzschlüssel und Backup-Zugänge sicher, aber erreichbar aufbewahren.
• Im Voraus festlegen, über welchen Kanal und wann Mitarbeitende, Kunden und Lieferanten informiert werden.
• Bei Vorfällen mit personenbezogenen Daten gesetzliche Meldepflichten und Fristen in den Plan aufnehmen.

Schritt 6: Den Plan testen und aktuell halten

Ein ungetesteter Plan ist eine Annahme, die erstmals in der Krise ausprobiert wird. Tests lassen sich nach Schwierigkeitsgrad planen:

• Planspiel am Tisch: Das Team geht den Plan anhand eines Szenarios Schritt für Schritt durch und notiert Lücken.
• Teilweise Wiederherstellung: Eine Datenbank oder ein Server wird in eine separate Umgebung zurückgespielt, und die tatsächliche Dauer wird mit dem RTO verglichen.
• Vollständiger Umschalttest: Kritische Systeme werden zu einem geplanten Zeitpunkt auf die Ersatzumgebung umgeschaltet, und die Geschäftsprozesse laufen dort.

Überprüfen Sie den Plan mindestens einmal jährlich und nach jeder größeren Infrastrukturänderung (neues ERP, neuer Server, Cloud-Migration). Ein neu hinzugefügtes System, das im Plan fehlt, wird auch in der Krise vergessen.

Häufige Fehler bei der Disaster-Recovery-Planung

• Backup mit Wiederherstellung verwechseln: Es ist bekannt, dass Backups laufen, aber eine Wiederherstellung wurde nie getestet.
• Abhängigkeiten vergessen: Die Anwendung ist zurückgespielt, startet aber ohne Authentifizierung, DNS oder Lizenzserver nicht.
• Den Plan an eine Person binden: Die Schritte existieren nur im Kopf eines Mitarbeitenden, der nicht erreichbar ist.
• Den Plan einmal schreiben und vergessen: Das Dokument beschreibt eine Infrastruktur von vor Jahren.
• Backups im selben Netzwerk: Ransomware verschlüsselt die Backups zusammen mit den Live-Systemen.

Checkliste für den Disaster-Recovery-Plan

• Sind kritische Systeme und ihre Prioritäten ermittelt?
• Wurden RTO und RPO für jedes kritische System mit der Geschäftsführung vereinbart?
• Folgen die Backups der 3-2-1-Regel, mit mindestens einer Kopie offline oder unveränderlich?
• Werden auch Konfigurationen und Zugangsdaten gesichert?
• Sind Schritte, Verantwortliche und Dauer für jedes Szenario schriftlich festgehalten?
• Sind Kontaktliste und Meldeschritte aktuell?
• Wann fand der letzte Wiederherstellungstest statt, und hat die tatsächliche Dauer das Ziel erreicht?
• Wurde der Plan nach der letzten Infrastrukturänderung aktualisiert?

Ein Disaster-Recovery-Plan ist eines der greifbarsten Ergebnisse einer gründlichen Technologieberatung. Wenn Sie Ihre Infrastruktur, Ihre Backup-Routine und Ihre Wiederherstellungszeiten gemeinsam mit uns prüfen möchten, informieren Sie sich über unsere Server- und Netzwerkberatung oder nehmen Sie Kontakt mit uns auf.

Häufig gestellte Fragen