Kein Unternehmen plant darauf, dass Systeme ausfallen, Daten verloren gehen oder das Rechenzentrum brennt. Aber genau diese ungeplanten Ereignisse passieren – und wer dann keinen IT-Disaster-Recovery-Plan hat, zahlt teuer. Nicht nur in Euro, sondern in Vertrauen, Zeit und manchmal auch in der eigenen Existenz.
- Ein IT-Disaster-Recovery-Plan (DRP) legt fest, wie ein Unternehmen nach einem IT-Ausfall oder Datenverlust schnell wieder handlungsfähig wird
- Zehn Kernelemente muss jeder DRP enthalten: von der Risikoanalyse über Backup-Strategien bis zur Kommunikationskette
- RTO (Recovery Time Objective) und RPO (Recovery Point Objective) sind die zwei zentralen Metriken, auf die alles aufbaut
- Ein Plan ist nur so gut wie sein letzter Test – regelmäßige Übungen sind kein Luxus, sondern Pflicht
- Der Plan muss dokumentiert, aktuell und für alle Beteiligten zugänglich sein
Was ist ein IT-Disaster-Recovery-Plan?
Ein IT-Disaster-Recovery-Plan ist ein dokumentiertes Verfahren, das beschreibt, wie eine Organisation nach einem IT-Ausfall oder einer Katastrophe ihre kritischen Systeme und Daten wiederherstellt. Er ist Teil des Business Continuity Managements (BCM), aber fokussiert ausschließlich auf die IT-Infrastruktur.
Ohne DRP reagierst du im Notfall blind. Mit DRP weißt du: Wer macht was, in welcher Reihenfolge, mit welchen Ressourcen – und bis wann.
Die 10 Punkte, die jeder IT-Disaster-Recovery-Plan enthalten muss
1. Risikoanalyse und Business-Impact-Analyse (BIA)
Am Anfang steht die Frage: Was kann überhaupt schiefgehen? Eine strukturierte Risikoanalyse identifiziert alle potenziellen Bedrohungen – Ransomware, Hardwarefehler, Naturkatastrophen, menschliche Fehler, Stromausfälle.
Die Business-Impact-Analyse geht einen Schritt weiter und beantwortet: Was kostet uns dieser Ausfall pro Stunde? Welche Systeme sind geschäftskritisch? Die BIA ist die Grundlage für alle weiteren Priorisierungsentscheidungen im Plan.
2. Definitionen von RTO und RPO
Diese beiden Metriken sind das Herzstück jedes DRP:
- RTO (Recovery Time Objective): Wie lange darf ein System maximal ausfallen, bevor der Schaden untragbar wird? Beispiel: Das ERP-System muss innerhalb von 4 Stunden wieder laufen.
- RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Beispiel: Wir können maximal 1 Stunde Transaktionsdaten verlieren.
RTO und RPO definieren den Rahmen für alle technischen Entscheidungen: Wie häufig muss gesichert werden? Wie schnell muss die Wiederherstellung technisch möglich sein?
3. Inventar aller kritischen Systeme und Abhängigkeiten
Du kannst nichts wiederherstellen, was du nicht kennst. Der DRP muss ein vollständiges Inventar enthalten: Server, Datenbanken, Netzwerkkomponenten, Cloud-Dienste, externe Abhängigkeiten. Und vor allem: Welche Systeme hängen von welchen ab? Eine Datenbank, die vor einem Applikationsserver gestartet werden muss, ist ein Detail, das im Ernstfall über Stunden entscheidet.
4. Backup-Strategie nach der 3-2-1-Regel
Kein DRP ohne Backup-Konzept. Die 3-2-1-Regel ist der anerkannte Mindeststandard:
- 3 Kopien der Daten
- auf 2 verschiedenen Medientypen
- davon 1 Kopie offsite (oder in der Cloud)
Der Plan muss festhalten: Welche Daten werden wie oft gesichert? Wo liegen die Backups? Wie lange dauert eine Wiederherstellung? Wurden die Backups kürzlich getestet?
5. Wiederherstellungsverfahren pro System
Für jedes kritische System braucht es einen konkreten Wiederherstellungsplan: Schritt-für-Schritt-Anleitungen, keine abstrakte Beschreibung. Wer war noch nie in einer Krisensituation? Unter Stress liest niemand gerne ausschweifende Texte. Klare, nummerierte Schritte sind das einzige, was zählt.
Dieser Abschnitt sollte auch Fallback-Szenarien enthalten: Was tun, wenn der primäre Wiederherstellungsweg nicht funktioniert?
6. Kommunikationsplan und Eskalationskette
Wer informiert wen, wann und über welchen Kanal? Im Ernstfall ist die E-Mail-Infrastruktur möglicherweise ausgefallen. Der Kommunikationsplan muss alternative Kanäle benennen und klare Eskalationspfade festlegen: Von der ersten Meldung des Ausfalls bis zur Information der Geschäftsleitung und gegebenenfalls Kunden oder Behörden.
7. Verantwortlichkeiten und Rollen
Jede Aufgabe im DRP braucht einen Namen dahinter – nicht eine Abteilung, sondern eine Person. Und eine Vertretung. Im Ernstfall ist der Hauptverantwortliche möglicherweise im Urlaub oder nicht erreichbar.
Typische Rollen: DRP-Koordinator, System-Owner pro kritischem System, Kommunikationsverantwortlicher, externer Support-Kontakt. Alle Kontaktdaten müssen im Dokument stehen – auch die privaten Telefonnummern für Notfälle außerhalb der Arbeitszeit.
8. Notfall-Ressourcen und Alternativer Arbeitsort
Was benötigst du zur Wiederherstellung? Spare Hardware, Zugangsdaten zu Cloud-Konsolen, externe RAID-Controller, spezifische Software-Lizenzen? Das alles muss dokumentiert und im Notfall schnell verfügbar sein.
Wenn das Büro selbst betroffen ist (Brand, Überflutung), braucht es einen alternativen Arbeitsort oder die Möglichkeit zum Remote-Zugang. Cloud-basierte Failover-Systeme können hier den Unterschied machen.
9. Compliance- und Meldepflichten
Nicht jeder IT-Vorfall bleibt intern. Die DSGVO schreibt vor, Datenpannen innerhalb von 72 Stunden der zuständigen Datenschutzbehörde zu melden. Für Unternehmen in regulierten Branchen (Finanzen, Gesundheit, kritische Infrastruktur) gelten zusätzliche Meldepflichten. Der DRP muss festhalten, welche Meldepflichten gelten und wer dafür verantwortlich ist.
10. Testplan und Aktualisierungsrhythmus
Ein ungetesteter Plan ist kein Plan – es ist Hoffnung. Mindestens einmal jährlich sollte der DRP getestet werden: erst als Tabletop-Übung (durchspielen auf dem Papier), dann als technischer Test (tatsächliche Wiederherstellung aus Backup). Jeder Test zeigt Lücken auf. Jede Lücke muss ins Dokument zurückfließen.
Zusätzlich muss der Plan bei jeder größeren Infrastrukturänderung aktualisiert werden. Ein DRP, der die neu eingeführten Cloud-Dienste nicht erwähnt, ist im besten Fall unvollständig, im schlechtesten Fall gefährlich.
Häufige Fehler beim IT-Disaster-Recovery-Plan
- Der Plan existiert, wird aber nie getestet
- Kontaktdaten sind veraltet
- Backups werden nicht regelmäßig auf Wiederherstellbarkeit geprüft
- RTO und RPO wurden nie definiert – alles soll „so schnell wie möglich“ wiederhergestellt werden
- Der Plan liegt im eigenen System, das im Notfall ausgefallen ist
Fazit
Ein IT-Disaster-Recovery-Plan ist keine bürokratische Pflichtübung – er ist die Grundlage dafür, dass dein Unternehmen nach einem IT-Ausfall überhaupt handlungsfähig bleibt. Die zehn Punkte in diesem Artikel sind der Mindestrahmen. Wie ausführlich du jeden einzelnen ausfüllst, hängt von der Größe und Komplexität deiner IT-Umgebung ab.
Fang heute an. Ein rudimentärer, getesteter Plan ist besser als ein perfekter Plan, der noch in der Schublade liegt.
FAQ
Was ist der Unterschied zwischen Disaster Recovery Plan und Business Continuity Plan?
Ein DRP fokussiert auf die Wiederherstellung der IT-Infrastruktur nach einem Ausfall. Ein BCP (Business Continuity Plan) ist breiter gefasst und behandelt die Aufrechterhaltung aller Geschäftsprozesse – auch nicht-technischer Art. Der DRP ist in der Regel Teil des BCP.
Wie oft muss ein DR-Plan getestet werden?
Mindestens einmal jährlich, bei größeren Infrastrukturveränderungen auch häufiger. Ein vollständiger Test mit tatsächlicher Wiederherstellung aus Backup zeigt deutlich mehr als eine reine Dokumentationsprüfung.
Was bedeutet RTO und RPO?
RTO (Recovery Time Objective) ist die maximale Ausfallzeit, die ein System haben darf. RPO (Recovery Point Objective) ist der maximale Datenverlust in Zeit gemessen – also wie alt das älteste wiederherstellbare Backup sein darf.
Muss ich bei einem Datenverlust die Datenschutzbehörde informieren?
Unter der DSGVO ja – wenn personenbezogene Daten betroffen sind und ein Risiko für Betroffene besteht, muss die zuständige Datenschutzbehörde innerhalb von 72 Stunden informiert werden. Der DRP sollte diese Meldepflicht und den zuständigen Ansprechpartner explizit benennen.