Disaster Recovery erklärt: Strategien, Planung und Umsetzung für Unternehmen

Unternehmen sind heute in nahezu allen Bereichen auf funktionierende IT-Systeme angewiesen. Produktionsanlagen werden digital gesteuert, Mitarbeitende kommunizieren über cloudbasierte Anwendungen und Kundendaten liegen in zentralen Datenbanken. Fällt diese IT-Infrastruktur aus, können wichtige Geschäftsprozesse innerhalb weniger Minuten zum Stillstand kommen. Aufträge lassen sich nicht bearbeiten, Kunden können keine Dienstleistungen nutzen und Mitarbeitende verlieren den Zugriff auf benötigte Informationen.

Die Ursachen eines solchen Ausfalls können sehr unterschiedlich sein. Neben defekter Hardware, Softwarefehlern und Stromausfällen gehören Cyberangriffe inzwischen zu den wichtigsten Bedrohungen. Insbesondere Ransomware kann Server, Anwendungen und Datensicherungen gleichzeitig beeinträchtigen. Aber auch menschliche Fehler, fehlerhafte Updates, Brände, Überschwemmungen oder der Ausfall eines externen Cloud- und IT-Dienstleisters können erhebliche Betriebsunterbrechungen verursachen.

Disaster Recovery soll sicherstellen, dass ein Unternehmen in diesen Situationen nicht improvisieren muss. Durch vorbereitete Prozesse, geeignete Technologien und klar geregelte Verantwortlichkeiten können wichtige IT-Systeme kontrolliert wiederhergestellt werden. Entscheidend ist dabei nicht allein, ob Daten gesichert wurden. Unternehmen müssen außerdem wissen, welche Systeme zuerst benötigt werden, wie lange deren Ausfall toleriert werden kann und welche technischen sowie organisatorischen Schritte für den Wiederanlauf erforderlich sind.

Dieser Beitrag erklärt verständlich, was Disaster Recovery bedeutet, wie sich eine geeignete Disaster-Recovery-Strategie entwickeln lässt und welche Inhalte ein belastbarer Disaster-Recovery-Plan benötigt. Sie erfahren außerdem, was die Kennzahlen RTO und RPO bedeuten, welche Wiederherstellungsmodelle zur Verfügung stehen und wie Unternehmen ihre Notfallplanung durch regelmäßige Tests überprüfen können.

Warum Disaster Recovery für Unternehmen unverzichtbar ist

Ein IT-Ausfall betrifft längst nicht mehr ausschließlich die interne IT-Abteilung. Wenn zentrale Systeme nicht verfügbar sind, kann sich die Störung unmittelbar auf nahezu alle Unternehmensbereiche auswirken. Der Vertrieb hat möglicherweise keinen Zugriff mehr auf Kundendaten, die Buchhaltung kann keine Rechnungen verarbeiten und die Produktion erhält keine aktuellen Auftragsinformationen. Gleichzeitig können Onlineshops, Kundenportale oder Kommunikationsplattformen ausfallen.

Je länger eine solche Unterbrechung andauert, desto größer werden die finanziellen und organisatorischen Folgen. Neben entgangenen Umsätzen können zusätzliche Kosten für externe Spezialisten, Überstunden, Ersatzsysteme und die technische Wiederherstellung entstehen. Hinzu kommen mögliche Vertragsstrafen, regulatorische Konsequenzen und langfristige Reputationsschäden.

Besonders problematisch ist, dass sich viele Unternehmen auf vorhandene Datensicherungen verlassen, ohne den vollständigen Wiederherstellungsprozess regelmäßig zu testen. Ein Backup zeigt zunächst nur, dass Daten kopiert wurden. Es beweist jedoch nicht automatisch, dass sich vollständige Anwendungen, Server und Geschäftsprozesse innerhalb eines akzeptablen Zeitraums wieder in Betrieb nehmen lassen.

Eine funktionierende Disaster-Recovery-Strategie hilft Unternehmen deshalb, verschiedene Risiken gezielt zu begrenzen. Sie schafft unter anderem die Voraussetzungen dafür, dass:

• geschäftskritische Anwendungen schneller wieder verfügbar sind,
• Datenverluste auf ein festgelegtes Maß begrenzt werden,
• Verantwortliche im Ernstfall ohne unnötige Verzögerungen handeln können,
• technische und organisatorische Abhängigkeiten berücksichtigt werden,
• Kunden, Mitarbeitende und Geschäftspartner rechtzeitig informiert werden,
• regulatorische und vertragliche Anforderungen eingehalten werden können.

Disaster Recovery ist daher nicht nur ein technisches Sicherheitskonzept. Es ist ein wichtiger Bestandteil der unternehmerischen Risikovorsorge und trägt dazu bei, die Handlungsfähigkeit auch während einer schwerwiegenden Störung aufrechtzuerhalten.

Was ist Disaster Recovery? Definition einfach erklärt

Disaster Recovery, häufig mit DR abgekürzt, bezeichnet die Gesamtheit aller technischen und organisatorischen Maßnahmen, mit denen ein Unternehmen seine IT-Systeme, Anwendungen und Daten nach einem schwerwiegenden Störfall wiederherstellt. Der Begriff kann im Deutschen mit IT-Notfallwiederherstellung übersetzt werden.

Das Ziel besteht darin, die Auswirkungen eines Ausfalls zu begrenzen und den Geschäftsbetrieb innerhalb zuvor festgelegter Zeiträume wiederaufzunehmen. Dafür werden bereits vor einem möglichen Vorfall Wiederherstellungsziele definiert, geeignete technische Lösungen eingerichtet und konkrete Abläufe dokumentiert. Ein Unternehmen entscheidet beispielsweise, welche Anwendung zuerst wiederhergestellt werden muss, welches Ersatzsystem genutzt wird und wie viele Daten im schlimmsten Fall verloren gehen dürfen.Disaster Recovery beginnt somit nicht erst, wenn ein Server ausfällt oder ein Cyberangriff erkannt wird. Eine wirksame IT-Notfallwiederherstellung setzt eine umfassende Vorbereitung voraus. Dazu gehören die Analyse möglicher Risiken, die Priorisierung kritischer Systeme, die Einrichtung geeigneter Backup- und Replikationslösungen sowie regelmäßige Wiederherstellungstests.

Welche Ziele verfolgt die IT-Notfallwiederherstellung?

Das wichtigste Ziel besteht darin, geschäftskritische IT-Services nach einem Ausfall kontrolliert und möglichst schnell wieder bereitzustellen. Dabei muss jedoch nicht jedes System sofort wieder funktionieren. Ein Unternehmen sollte seine Anwendungen entsprechend ihrer Bedeutung für den Geschäftsbetrieb priorisieren.

Während ein ERP-System, eine Produktionssteuerung oder ein zentrales Kundenportal möglicherweise innerhalb weniger Stunden verfügbar sein muss, kann die Wiederherstellung eines internen Archivsystems länger warten. Durch diese Priorisierung lassen sich vorhandene Ressourcen dort einsetzen, wo ein längerer Ausfall den größten Schaden verursachen würde.

Zu den wesentlichen Zielen von Disaster Recovery gehören:

• die Dauer der Betriebsunterbrechung zu begrenzen,
• den Verlust wichtiger Unternehmensdaten zu minimieren,
• kritische Geschäftsprozesse schnell wieder aufzunehmen,
• eine festgelegte Reihenfolge bei der Wiederherstellung einzuhalten,
• die Integrität wiederhergestellter Systeme und Daten zu überprüfen,
• Verantwortlichkeiten und Entscheidungswege eindeutig zu regeln,
• die Rückkehr in einen stabilen Normalbetrieb zu ermöglichen.

Eine schnelle Wiederherstellung allein reicht jedoch nicht aus. Die zurückgespielten Daten müssen vollständig, konsistent und frei von Schadsoftware sein. Das ist insbesondere nach einem Cyberangriff wichtig, da eine ungeprüfte Wiederherstellung kompromittierter Systeme dazu führen kann, dass sich der Angriff erneut ausbreitet.

Welche Systeme und Ressourcen umfasst Disaster Recovery?

Disaster Recovery kann sich auf die gesamte IT-Landschaft eines Unternehmens beziehen. Dazu gehören nicht nur Server und Datenbanken, sondern auch Netzwerke, Endgeräte, Cloud-Dienste, Identitätsplattformen und Kommunikationssysteme. Welche Komponenten in den Disaster-Recovery-Plan aufgenommen werden, hängt von der jeweiligen Infrastruktur und den geschäftlichen Abhängigkeiten ab.

Typischerweise umfasst die IT-Notfallwiederherstellung folgende Bereiche:

• physische und virtuelle Server,
• Datenbanken und Speichersysteme,
• geschäftskritische Anwendungen,
• Netzwerkkomponenten und Internetverbindungen,
• Cloud- und SaaS-Dienste,
• Benutzerkonten und Identitätsmanagement,
• Backup- und Replikationssysteme,
• Telefonie und interne Kommunikationsplattformen,
• Produktions- und Steuerungssysteme,
• Arbeitsplätze und benötigte Endgeräte.

Besondere Aufmerksamkeit erfordern die Abhängigkeiten zwischen diesen Komponenten. Eine Anwendung kann technisch wiederhergestellt sein und dennoch nicht funktionieren, wenn die erforderliche Datenbank, Netzwerkverbindung oder Benutzerverwaltung weiterhin ausgefallen ist. Deshalb sollte Disaster Recovery nicht nur einzelne Systeme betrachten, sondern vollständige Serviceketten abbilden.

Welche Ereignisse können einen Disaster-Recovery-Fall auslösen?

Ein Disaster-Recovery-Fall kann durch jedes Ereignis ausgelöst werden, das wichtige IT-Systeme oder Daten über einen nicht mehr tolerierbaren Zeitraum beeinträchtigt. Dabei muss es sich nicht zwingend um eine großflächige Naturkatastrophe handeln. Bereits ein fehlerhaftes Update oder eine versehentlich gelöschte Datenbank kann erhebliche Auswirkungen auf den Geschäftsbetrieb haben.

Typische Auslöser sind:

• Ransomware und andere Cyberangriffe,
• Hardware- oder Speicherausfälle,
• fehlerhafte Softwareupdates und Fehlkonfigurationen,
• versehentlich gelöschte oder beschädigte Daten,
• Strom- und Netzwerkausfälle,
• Brände, Überschwemmungen und andere Naturereignisse,
• Ausfälle von Rechenzentren oder Cloud-Regionen,
• Störungen bei externen IT- und SaaS-Dienstleistern,
• Sabotage und vorsätzliche Handlungen,
• menschliche Fehler im laufenden IT-Betrieb.

Ob ein Vorfall tatsächlich zur Aktivierung des Disaster-Recovery-Plans führt, sollte anhand klarer Kriterien entschieden werden. Nicht jede kurze Störung erfordert einen vollständigen Failover auf eine Ersatzumgebung. Der Plan muss deshalb festlegen, ab welcher erwarteten Ausfalldauer, Schadenshöhe oder Systemkritikalität die vorgesehenen Wiederherstellungsverfahren aktiviert werden.

Disaster Recovery, Backup und Business Continuity im Vergleich

Die Begriffe Disaster Recovery, Backup und Business Continuity werden häufig gleichgesetzt, beschreiben jedoch unterschiedliche Maßnahmen. Eine Datensicherung kann zwar ein wichtiger Bestandteil der Wiederherstellung sein, bildet allein aber noch keine vollständige Disaster-Recovery-Strategie. Ebenso geht Business Continuity deutlich über die Wiederherstellung der IT hinaus.

Für eine belastbare Notfallvorsorge müssen diese Bereiche aufeinander abgestimmt werden. Das Backup schützt ausgewählte Daten, Disaster Recovery stellt die benötigte IT-Infrastruktur wieder her und Business Continuity sorgt dafür, dass die wichtigsten Geschäftsprozesse während oder nach einer Störung fortgeführt werden können.

Was unterscheidet ein Backup von Disaster Recovery?

Ein Backup ist eine zusätzliche Kopie von Daten, die bei Verlust, Beschädigung oder versehentlicher Löschung verwendet werden kann. Je nach Backup-Strategie werden beispielsweise Dateien, Datenbanken, virtuelle Maschinen oder vollständige Systemzustände gesichert. Die Kopien können lokal, an einem externen Standort oder in einer Cloud-Umgebung gespeichert werden.

Disaster Recovery verfolgt dagegen einen umfassenderen Ansatz. Es beantwortet nicht nur die Frage, ob Daten vorhanden sind, sondern auch, wie die davon abhängigen Systeme wieder funktionsfähig gemacht werden. Dafür müssen unter anderem Server, Anwendungen, Netzwerke, Benutzerkonten und Schnittstellen in der richtigen Reihenfolge wiederhergestellt werden.

Der Unterschied lässt sich an einem einfachen Beispiel verdeutlichen: Ein Unternehmen besitzt ein aktuelles Backup seiner Kundendatenbank. Nach einem Serverausfall sind die Daten daher nicht vollständig verloren. Trotzdem können Mitarbeitende noch nicht damit arbeiten, solange kein geeigneter Ersatzserver bereitsteht, die Datenbanksoftware nicht installiert ist oder die Verbindung zum CRM-System fehlt. Erst ein vorbereiteter Wiederherstellungsprozess führt alle benötigten Komponenten wieder zusammen.

Ein Backup beantwortet vor allem die Frage: Welche Daten können wiederhergestellt werden? Disaster Recovery beantwortet dagegen weitere entscheidende Fragen:

• Welche Systeme werden für den Geschäftsbetrieb benötigt?
• In welcher Reihenfolge erfolgt die Wiederherstellung?
• Wer darf den Wiederanlauf veranlassen?
• Welche Ersatzinfrastruktur steht zur Verfügung?
• Wie lange darf die Wiederherstellung dauern?
• Wie wird geprüft, ob Anwendungen und Daten korrekt funktionieren?
• Wie erfolgt die Rückkehr zum regulären Betrieb?

Auch ein technisch erfolgreiches Backup ist nur dann zuverlässig, wenn die Wiederherstellung regelmäßig getestet wird. Beschädigte Sicherungsdateien, fehlende Verschlüsselungsschlüssel oder nicht dokumentierte Zugangsdaten können dazu führen, dass die Daten im Ernstfall nicht rechtzeitig verfügbar sind.

Wie unterscheiden sich Disaster Recovery und Business Continuity Management?

Business Continuity Management, kurz BCM, verfolgt das Ziel, die zeitkritischen Geschäftsprozesse eines Unternehmens auch während einer Krise aufrechtzuerhalten oder innerhalb festgelegter Zeiträume wieder aufzunehmen. Dabei werden nicht nur IT-Systeme betrachtet. BCM berücksichtigt ebenfalls Personal, Gebäude, Lieferanten, Kommunikationswege, Produktionsmittel und alternative Arbeitsverfahren.

Disaster Recovery konzentriert sich innerhalb dieses Gesamtkonzepts vor allem auf die Wiederherstellung der IT. Dazu gehören Daten, Anwendungen, Server, Netzwerke und weitere technische Ressourcen, von denen die Geschäftsprozesse abhängig sind.

Ein Beispiel zeigt die Abgrenzung: Kann ein Unternehmen sein Bürogebäude nach einem Brand vorübergehend nicht nutzen, regelt das Business Continuity Management, welche Mitarbeitenden von zu Hause arbeiten, welche Ersatzarbeitsplätze bereitstehen und wie Kunden sowie Geschäftspartner informiert werden. Disaster Recovery stellt ergänzend sicher, dass diese Mitarbeitenden auf die notwendigen Anwendungen und Daten zugreifen können.

Beide Bereiche müssen deshalb eng miteinander verbunden sein. Ein Disaster-Recovery-Plan, der ausschließlich technische Systeme berücksichtigt, kann an den tatsächlichen Anforderungen des Unternehmens vorbeigehen. Umgekehrt kann ein Business-Continuity-Plan nicht funktionieren, wenn die dafür erforderlichen IT-Services nicht rechtzeitig wieder verfügbar sind.

Was unterscheidet klassische Disaster Recovery von Cyber Recovery?

Klassische Disaster Recovery wurde ursprünglich vor allem für technische Ausfälle, Standortschäden und Naturereignisse entwickelt. In diesen Situationen wird häufig davon ausgegangen, dass die gesicherten Daten grundsätzlich vertrauenswürdig sind und auf einer funktionierenden Ersatzinfrastruktur wiederhergestellt werden können.

Nach einem Cyberangriff ist diese Voraussetzung nicht automatisch erfüllt. Angreifer können über einen längeren Zeitraum unbemerkt im Netzwerk aktiv gewesen sein, Benutzerkonten übernommen und Schadsoftware in Systeme eingeschleust haben. Unter Umständen sind auch Backups verschlüsselt, manipuliert oder mit kompromittierten Systemzuständen versehen.

Cyber Recovery ergänzt die klassische Notfallwiederherstellung deshalb um zusätzliche Sicherheitsmaßnahmen. Dazu gehören insbesondere:

• die forensische Untersuchung des Vorfalls,
• die Trennung betroffener Systeme vom übrigen Netzwerk,
• die Prüfung von Backups auf Schadsoftware und Manipulationen,
• die Wiederherstellung in einer isolierten Umgebung,
• der Austausch kompromittierter Zugangsdaten,
• die Beseitigung der ursprünglichen Sicherheitslücke,
• die kontrollierte Freigabe wiederhergestellter Systeme.

Während klassische Disaster Recovery vor allem auf eine schnelle Verfügbarkeit abzielt, muss Cyber Recovery zusätzlich sicherstellen, dass die wiederhergestellte Umgebung vertrauenswürdig ist. Ein besonders schnelles Failover bietet keinen Schutz, wenn Schadsoftware oder kompromittierte Konten dabei unmittelbar in die Ersatzumgebung übernommen werden.

RTO und RPO als zentrale Disaster-Recovery-Kennzahlen

Ein Disaster-Recovery-Plan benötigt messbare Ziele. Aussagen wie „Das System soll möglichst schnell wieder funktionieren“ sind im Ernstfall zu ungenau. Sie ermöglichen weder eine verlässliche technische Planung noch eine objektive Bewertung, ob die Wiederherstellung erfolgreich war.

Zu den wichtigsten Kennzahlen gehören das Recovery Time Objective und das Recovery Point Objective. Beide Werte werden für einzelne Anwendungen oder IT-Services festgelegt. Dadurch kann ein Unternehmen seine Wiederherstellungsmaßnahmen an der tatsächlichen Bedeutung der Systeme ausrichten.

Was bedeutet das Recovery Time Objective?

Das Recovery Time Objective, kurz RTO, beschreibt die maximal angestrebte Zeitspanne, innerhalb derer ein ausgefallener IT-Service wieder verfügbar sein soll. Die Zeit beginnt üblicherweise mit dem Eintritt beziehungsweise der Erkennung der Störung und endet, sobald das System wieder in einem definierten funktionsfähigen Zustand genutzt werden kann.

Ein RTO von vier Stunden bedeutet beispielsweise, dass die Wiederherstellung eines betroffenen Systems innerhalb von höchstens vier Stunden erfolgen soll. Daraus ergibt sich, welche technischen Lösungen, personellen Kapazitäten und vorbereiteten Abläufe benötigt werden.

Je kürzer das RTO ausfällt, desto höher sind in der Regel die Anforderungen. Eine Wiederherstellung innerhalb weniger Minuten kann redundante Systeme, automatisierte Replikation und ein vorbereitetes Failover erfordern. Ist eine Ausfallzeit von einem oder mehreren Tagen akzeptabel, kann möglicherweise eine Wiederherstellung aus einem klassischen Backup ausreichen.

Das RTO sollte nicht allein von der IT-Abteilung festgelegt werden. Die verantwortlichen Fachbereiche müssen einschätzen, wie lange der jeweilige Geschäftsprozess tatsächlich ohne das System arbeiten kann und welche Schäden mit zunehmender Ausfalldauer entstehen.

Was bedeutet das Recovery Point Objective?

Das Recovery Point Objective, kurz RPO, legt fest, wie groß der tolerierbare Datenverlust gemessen in Zeit maximal sein darf. Der Wert bestimmt, auf welchen Datenstand ein Unternehmen nach einer Störung mindestens zurückkehren können muss.

Ein RPO von 30 Minuten bedeutet, dass im ungünstigsten Fall höchstens die Daten der letzten 30 Minuten fehlen dürfen. Um dieses Ziel erreichen zu können, müssen Daten entsprechend häufig gesichert oder fortlaufend auf ein anderes System repliziert werden.

Auch beim RPO steigen die technischen und finanziellen Anforderungen, je näher der Wert an null liegt. Tägliche Backups können für ein wenig genutztes Archiv ausreichend sein. Für einen Onlineshop, ein Warenwirtschaftssystem oder eine Produktionsdatenbank wären 24 Stunden Datenverlust dagegen möglicherweise nicht akzeptabel.

Bei der Festlegung des RPO sollten Unternehmen unter anderem berücksichtigen:

• Wie viele Transaktionen entstehen innerhalb eines bestimmten Zeitraums?
• Lassen sich verlorene Daten nachträglich rekonstruieren?
• Welche finanziellen Folgen hätte der Datenverlust?
• Sind personenbezogene oder regulatorisch relevante Daten betroffen?
• Wie häufig können Backups technisch durchgeführt werden?
• Welche Belastung entsteht durch eine kontinuierliche Replikation?

Wie werden RTO und RPO realistisch festgelegt?

RTO und RPO sollten aus den Anforderungen der Geschäftsprozesse abgeleitet werden. Werden die Werte ohne eine Business Impact Analysis festgelegt, entstehen häufig unrealistische Zielvorgaben. Ein extrem kurzes RTO klingt zwar sicher, kann aber erhebliche Investitionen erfordern. Zu großzügige Werte können wiederum dazu führen, dass wichtige Geschäftsprozesse zu lange stillstehen oder zu viele Daten verloren gehen.

Ein Unternehmen sollte daher für jeden wichtigen IT-Service untersuchen:

1. Welche Geschäftsprozesse hängen von dem System ab?
2. Ab wann verursacht der Ausfall einen erheblichen Schaden?
3. Wie viele Daten können verloren gehen, ohne den Betrieb nachhaltig zu beeinträchtigen?
4. Welche Wiederherstellungslösung ist technisch erforderlich?
5. Stehen Kosten und Risikoreduzierung in einem angemessenen Verhältnis?

Angenommen, ein mittelständisches Unternehmen legt für sein ERP-System ein RTO von vier Stunden und ein RPO von 30 Minuten fest. Nach einem Ausfall muss das System innerhalb von vier Stunden wieder nutzbar sein. Gleichzeitig darf der wiederhergestellte Datenbestand höchstens 30 Minuten älter sein als der Zeitpunkt des Ausfalls.

Für die interne Marketingablage könnten dagegen ein RTO von 48 Stunden und ein RPO von 24 Stunden genügen. Die unterschiedlichen Zielwerte verhindern, dass sämtliche Systeme mit derselben kostenintensiven Technologie abgesichert werden. Finanzielle und technische Ressourcen fließen zuerst in die Anwendungen, deren Ausfall den größten Schaden verursachen würde.

Business Impact Analysis als Grundlage für Disaster Recovery

Die Business Impact Analysis, kurz BIA, untersucht, welche Auswirkungen der Ausfall einzelner Geschäftsprozesse auf ein Unternehmen hätte. Sie bildet die Verbindung zwischen den betrieblichen Anforderungen und der technischen Disaster-Recovery-Planung.

Ohne eine BIA besteht die Gefahr, dass Systeme nach technischer Sichtweise priorisiert werden, obwohl andere Anwendungen für den Geschäftsbetrieb dringender benötigt werden. Die Analyse betrachtet deshalb nicht nur einzelne Server, sondern die vollständigen Geschäftsprozesse und die dafür erforderlichen Ressourcen.

Welche Geschäftsprozesse und IT-Systeme sind besonders kritisch?

Ein Geschäftsprozess gilt als besonders kritisch, wenn sein Ausfall bereits innerhalb kurzer Zeit erhebliche finanzielle, rechtliche oder operative Folgen verursacht. Dazu können abhängig vom Unternehmen die Auftragsbearbeitung, Produktion, Logistik, Abrechnung, Kundenkommunikation oder medizinische Versorgung gehören.

Zunächst sollten die wichtigsten Geschäftsprozesse erfasst und gemeinsam mit den Fachbereichen bewertet werden. Anschließend wird dokumentiert, welche Anwendungen, Daten, Mitarbeitenden, Dienstleister und Infrastrukturen für die Durchführung benötigt werden.

Relevante Bewertungskriterien sind beispielsweise:

• mögliche Umsatz- und Produktionsverluste,
• Auswirkungen auf Kunden und Geschäftspartner,
• rechtliche oder vertragliche Verpflichtungen,
• Gefahren für Menschen, Anlagen oder Umwelt,
• Reputationsschäden,
• mögliche manuelle Ersatzverfahren,
• zunehmende Auswirkungen bei längerer Ausfallzeit.

Wie werden Anwendungen nach ihrer Kritikalität priorisiert?

Nicht jede Anwendung muss unmittelbar nach einem Vorfall wiederhergestellt werden. Eine Priorisierung verhindert, dass sich IT-Teams im Ernstfall gleichzeitig mit zahlreichen Systemen beschäftigen und dabei geschäftskritische Services verzögern.

Eine mögliche Einteilung sieht folgendermaßen aus:

• Stufe 1 – geschäftskritisch: Der Ausfall führt innerhalb kurzer Zeit zu schwerwiegenden Folgen. Eine schnelle Wiederherstellung ist erforderlich.
• Stufe 2 – wichtig: Der Prozess kann für einen begrenzten Zeitraum eingeschränkt oder manuell fortgeführt werden.
• Stufe 3 – unterstützend: Ein längerer Ausfall ist möglich, ohne dass das Kerngeschäft unmittelbar gefährdet wird.
• Stufe 4 – nachrangig: Die Wiederherstellung kann erfolgen, nachdem die wichtigeren Systeme stabil verfügbar sind.

Die Kritikalitätsstufe sollte nicht pauschal für eine Anwendung vergeben werden. Dasselbe System kann in verschiedenen Unternehmen eine unterschiedliche Bedeutung besitzen. Ein Kundenportal ist für einen reinen Onlineanbieter möglicherweise existenziell, während es in einem anderen Geschäftsmodell für einige Tage ersetzt werden kann.

Warum müssen technische Abhängigkeiten dokumentiert werden?

Anwendungen funktionieren selten vollständig eigenständig. Ein ERP-System kann beispielsweise eine Datenbank, einen Verzeichnisdienst, Netzwerkverbindungen, Zertifikate, Schnittstellen und externe Cloud-Dienste benötigen. Wird nur die sichtbare Anwendung wiederhergestellt, bleiben diese Abhängigkeiten möglicherweise unberücksichtigt.

Die Wiederherstellungsreihenfolge muss deshalb der technischen Servicekette folgen. Häufig werden zunächst Netzwerk, Speicher, Identitätsverwaltung und grundlegende Plattformdienste benötigt. Erst danach können Datenbanken und Fachanwendungen zuverlässig gestartet werden.

Besonders kritisch sind unerkannte Abhängigkeiten zu externen Dienstleistern. Ist etwa eine wichtige Schnittstelle zu einem Zahlungs-, Logistik- oder Cloud-Anbieter nicht verfügbar, kann der Geschäftsprozess trotz erfolgreicher interner Wiederherstellung weiterhin stillstehen.

Wie lassen sich die Auswirkungen eines IT-Ausfalls bewerten?

Die Auswirkungen sollten für verschiedene Zeiträume betrachtet werden. Ein Ausfall von 30 Minuten kann kaum spürbar sein, während dieselbe Störung nach acht Stunden zu Lieferverzögerungen und nach mehreren Tagen zu erheblichen Vertrags- oder Kundenverlusten führt.

Dabei können qualitative und quantitative Kriterien miteinander kombiniert werden. Zu den quantifizierbaren Schäden gehören entgangene Umsätze, Produktionsstillstand, Überstunden und externe Wiederherstellungskosten. Schwerer messbare Auswirkungen wie Vertrauensverlust, negative Berichterstattung oder Belastungen der Mitarbeitenden sollten dennoch dokumentiert werden.

Das Ergebnis der BIA liefert eine nachvollziehbare Grundlage für RTO, RPO und Wiederherstellungsprioritäten. So entscheidet nicht allein das technische Bauchgefühl darüber, welche Systeme zuerst abgesichert werden, sondern der konkrete Nutzen für die Handlungsfähigkeit des Unternehmens.

Disaster-Recovery-Strategie und Disaster-Recovery-Plan unterscheiden

Eine wirksame IT-Notfallwiederherstellung benötigt sowohl eine übergeordnete Strategie als auch einen konkreten Plan. Die Disaster-Recovery-Strategie definiert die Ziele und Rahmenbedingungen. Der Disaster-Recovery-Plan beschreibt dagegen, wie diese Vorgaben im Ernstfall praktisch umgesetzt werden.

Welche Ziele definiert die Disaster-Recovery-Strategie?

Die Strategie legt fest, welche Geschäftsprozesse und IT-Systeme geschützt werden müssen. Sie berücksichtigt die Ergebnisse der Business Impact Analysis sowie die festgelegten RTO- und RPO-Werte. Außerdem bestimmt sie, welche technischen Wiederherstellungsmodelle zum Schutzbedarf und Budget des Unternehmens passen.

Zu den zentralen Entscheidungen gehören:

• Priorisierung kritischer Anwendungen,
• Auswahl geeigneter Backup- und Replikationsverfahren,
• Nutzung eigener oder cloudbasierter Ersatzsysteme,
• Festlegung von RTO und RPO,
• benötigte personelle und finanzielle Ressourcen,
• Anforderungen an Dienstleister und Ausweichstandorte.

Die Strategie beantwortet somit vor allem, was erreicht werden soll und warum.

Welche Maßnahmen enthält ein Disaster-Recovery-Plan?

Der Disaster-Recovery-Plan übersetzt die Strategie in konkrete Anweisungen. Er dokumentiert, wie ein Vorfall erkannt und bewertet wird, wer die Wiederherstellung aktiviert und welche Systeme in welcher Reihenfolge wiederhergestellt werden.

Dazu gehören technische Runbooks, Kontaktlisten, Kommunikationswege, Zugangsinformationen und Kriterien für Failover und Failback. Der Plan sollte so verständlich formuliert sein, dass die verantwortlichen Personen auch unter Zeitdruck damit arbeiten können.

Wer trägt die Verantwortung für Disaster Recovery?

Die Gesamtverantwortung liegt bei der Unternehmensleitung, da längere IT-Ausfälle den gesamten Geschäftsbetrieb gefährden können. Die operative Umsetzung verteilt sich jedoch auf mehrere Bereiche. IT-Verantwortliche kümmern sich um die technische Wiederherstellung, während Fachbereiche die Funktionsfähigkeit ihrer Anwendungen bestätigen.

Zusätzlich können Informationssicherheit, Datenschutz, Recht, Kommunikation und externe Dienstleister beteiligt sein. Für jede Aufgabe sollte deshalb eine verantwortliche Person sowie eine Vertretung festgelegt werden. Unklare Zuständigkeiten führen im Ernstfall zu Verzögerungen und widersprüchlichen Entscheidungen.

Disaster-Recovery-Plan erstellen – Schritt-für-Schritt-Anleitung

Ein Disaster-Recovery-Plan sollte auf den tatsächlichen Geschäftsrisiken basieren und nicht aus einer allgemeinen Vorlage unverändert übernommen werden. Infrastruktur, Anwendungen, Dienstleister und Wiederherstellungsziele unterscheiden sich von Unternehmen zu Unternehmen.

Risiken und mögliche Ausfallszenarien analysieren

Zunächst werden Ereignisse identifiziert, die kritische Systeme beeinträchtigen könnten. Dazu gehören Cyberangriffe, Hardwaredefekte, Fehlkonfigurationen, Stromausfälle, Brände und Störungen externer Anbieter. Für jedes Szenario sollten Eintrittswahrscheinlichkeit, mögliche Folgen und vorhandene Schutzmaßnahmen bewertet werden.

Kritische Systeme, Daten und Abhängigkeiten erfassen

Anschließend wird ein vollständiges Inventar der benötigten Hardware, Software, Datenbanken, Cloud-Dienste und Schnittstellen erstellt. Besonders wichtig sind die Abhängigkeiten zwischen den Systemen. Eine Fachanwendung kann beispielsweise erst funktionieren, wenn Netzwerk, Identitätsverwaltung und Datenbank wieder verfügbar sind.

RTO und RPO für wichtige Anwendungen festlegen

Für jedes relevante System werden die maximal tolerierbare Ausfallzeit und der akzeptable Datenverlust definiert. Geschäftskritische Anwendungen erhalten in der Regel kürzere Zielwerte als unterstützende Systeme. Dadurch entsteht eine nachvollziehbare Wiederherstellungsreihenfolge.

Wiederherstellungsstrategie und Backup-Verfahren auswählen

Aus den Anforderungen ergibt sich die technische Lösung. Je nach Schutzbedarf kommen klassische Backups, Snapshots, Datenreplikation, Ersatzsysteme oder eine vollständige Cloud-Recovery-Umgebung infrage. Die Strategie muss nicht nur die Daten, sondern auch Anwendungen, Konfigurationen und erforderliche Zugänge berücksichtigen.

Rollen, Kommunikationswege und Eskalationen dokumentieren

Der Plan sollte klar festlegen, wer einen Disaster-Recovery-Fall ausrufen darf und welche Teams anschließend informiert werden. Kontaktlisten müssen auch offline verfügbar sein. Ebenso wichtig sind vorbereitete Kommunikationswege zu Kunden, Dienstleistern, Behörden und weiteren Stakeholdern.

Technische Runbooks für den Ernstfall erstellen

Runbooks enthalten konkrete technische Arbeitsanweisungen. Sie beschreiben beispielsweise, wie Backups ausgewählt, Ersatzsysteme gestartet, Datenbanken eingebunden und Anwendungen getestet werden. Jeder Schritt sollte eindeutig, überprüfbar und in der richtigen Reihenfolge dokumentiert sein.

Disaster-Recovery-Plan testen und regelmäßig aktualisieren

Erst ein erfolgreicher Test zeigt, ob der Plan praktisch funktioniert. Veränderungen an Anwendungen, Infrastruktur oder Zuständigkeiten müssen zeitnah eingearbeitet werden. Mindestens nach größeren IT-Projekten und Sicherheitsvorfällen sollte eine erneute Überprüfung stattfinden.

Welche Inhalte gehören in einen Disaster-Recovery-Plan?

Ein guter Disaster-Recovery-Plan muss vollständig genug sein, um Orientierung zu geben, gleichzeitig aber übersichtlich bleiben. Umfangreiche Hintergrundinformationen können in Anhänge ausgelagert werden, während die wichtigsten Entscheidungen und Arbeitsschritte schnell auffindbar sein sollten.

Verantwortlichkeiten und Entscheidungsbefugnisse im Notfall

Der Plan benennt das Disaster-Recovery-Team, die jeweiligen Aufgaben und vorhandene Vertretungen. Außerdem muss klar sein, wer den Notfall ausruft, zusätzliche Ressourcen freigibt und über die Rückkehr zum Normalbetrieb entscheidet.

Systeminventar und dokumentierte Anwendungsabhängigkeiten

Das Inventar enthält alle kritischen Systeme, Datenbestände, Standorte, Dienstleister und Schnittstellen. Abhängigkeiten sollten so dokumentiert werden, dass daraus eine technische Wiederherstellungsreihenfolge hervorgeht.

Alarmierungs-, Kommunikations- und Eskalationsplan

Dieser Teil regelt, wer bei welchem Vorfall informiert wird und welche sicheren Kommunikationskanäle genutzt werden. Dabei sollte berücksichtigt werden, dass E-Mail, Telefonie oder das Unternehmensnetz selbst vom Ausfall betroffen sein können.

Wiederherstellungsanweisungen, Runbooks und benötigte Ressourcen

Für jedes kritische System werden die erforderlichen Schritte, Zugänge, Backup-Quellen und Prüfverfahren beschrieben. Benötigte Lizenzen, Ersatzgeräte, Verschlüsselungsschlüssel und externe Ansprechpartner dürfen dabei nicht fehlen.

Kriterien für Failover, Failback und Normalbetrieb

Der Plan definiert, wann auf eine Ersatzumgebung umgeschaltet wird und welche Voraussetzungen für die Rückkehr zum Primärsystem gelten. Vor der Freigabe müssen die wiederhergestellten Daten und Anwendungen technisch sowie durch die zuständigen Fachbereiche geprüft werden.

Eine kompakte Checkliste am Anfang des Dokuments kann helfen, die wichtigsten Schritte im Ernstfall schneller zu erfassen. Der vollständige Plan sollte zudem geschützt, versioniert und sowohl digital als auch unabhängig von der primären IT-Umgebung erreichbar sein.

Technische Disaster-Recovery-Strategien im Vergleich

Welche technische Disaster-Recovery-Strategie geeignet ist, hängt vor allem von der Kritikalität der Systeme, den festgelegten RTO- und RPO-Werten sowie dem verfügbaren Budget ab. Besonders kurze Wiederherstellungszeiten erfordern in der Regel höhere Investitionen und eine komplexere Infrastruktur.

Wiederherstellung aus Backups und Snapshots

Die Wiederherstellung aus einem Backup ist eine vergleichsweise kostengünstige Lösung. Nach einem Ausfall werden Daten, Anwendungen oder vollständige virtuelle Maschinen auf vorhandene beziehungsweise neu bereitgestellte Systeme übertragen. Wie lange dieser Vorgang dauert, hängt unter anderem von Datenmenge, Speicherort, Netzwerkleistung und verfügbaren Ersatzsystemen ab.

Snapshots speichern den Zustand eines Systems zu einem bestimmten Zeitpunkt. Sie ermöglichen häufig eine schnellere Wiederherstellung, dürfen aber nicht als alleiniger Schutz betrachtet werden. Befindet sich der Snapshot auf derselben Infrastruktur wie das Produktivsystem, kann er durch denselben technischen Ausfall oder Cyberangriff betroffen sein.

Cold Site, Warm Site und Hot Site im Vergleich

Bei einer Cold Site steht lediglich eine grundlegende Ausweichumgebung zur Verfügung. Systeme und Daten müssen im Notfall erst eingerichtet oder eingespielt werden. Diese Lösung verursacht relativ geringe laufende Kosten, führt jedoch zu längeren Wiederherstellungszeiten.

Eine Warm Site enthält bereits vorbereitete Infrastruktur und teilweise replizierte Systeme. Dadurch lässt sich der Betrieb schneller wiederaufnehmen. Eine Hot Site ist nahezu vollständig betriebsbereit und wird fortlaufend mit aktuellen Daten versorgt. Sie bietet kurze RTO- und RPO-Werte, ist jedoch entsprechend kostenintensiv.

Pilot-Light- und Active/Passive-Architekturen

Beim Pilot-Light-Modell bleiben nur grundlegende Komponenten einer Ersatzumgebung dauerhaft aktiv. Weitere Ressourcen werden erst im Notfall hochgefahren. Das reduziert die laufenden Kosten, setzt aber automatisierte und getestete Bereitstellungsprozesse voraus.

Bei einer Active/Passive-Architektur arbeitet das primäre System im Normalbetrieb, während eine passive Umgebung für das Failover bereitsteht. Je nach Ausgestaltung kann die Umschaltung automatisch oder manuell erfolgen.

Active/Active-Betrieb für besonders hohe Verfügbarkeit

In einer Active/Active-Umgebung bearbeiten mehrere Systeme oder Standorte gleichzeitig produktive Anfragen. Fällt ein System aus, übernimmt die verbleibende Umgebung dessen Aufgaben. Dadurch können Ausfallzeiten stark reduziert werden.

Diese Architektur stellt allerdings hohe Anforderungen an Datenkonsistenz, Lastverteilung und Überwachung. Sie eignet sich daher vor allem für Anwendungen, bei denen bereits kurze Unterbrechungen erhebliche Schäden verursachen würden.

Cloud Disaster Recovery und DRaaS für Unternehmen

Cloudbasierte Disaster-Recovery-Lösungen ermöglichen es Unternehmen, Ersatzsysteme flexibel bereitzustellen, ohne ein vollständiges zweites Rechenzentrum unterhalten zu müssen. Die Cloud beseitigt jedoch nicht automatisch alle Ausfallrisiken. Regionen, Konten, Konfigurationen und Zugriffsrechte müssen gezielt in die Notfallplanung einbezogen werden.

Wie funktioniert Disaster Recovery in der Cloud?

Bei Cloud Disaster Recovery werden Daten, Anwendungen oder vollständige Systemumgebungen an einen geografisch getrennten Cloud-Standort repliziert. Im Ernstfall können dort virtuelle Server, Datenbanken und weitere Ressourcen aktiviert werden.

Die Kosten lassen sich häufig reduzieren, indem die Ersatzumgebung im Normalbetrieb nur mit geringer Leistung oder vollständig abgeschaltet vorgehalten wird. Damit die Aktivierung zuverlässig funktioniert, sollten Konfigurationen automatisiert bereitgestellt und regelmäßig getestet werden.

Welche Vorteile bietet Disaster Recovery as a Service?

Bei Disaster Recovery as a Service, kurz DRaaS, unterstützt ein externer Anbieter die Replikation, Orchestrierung und Wiederherstellung der IT-Systeme. Das kann vor allem mittelständische Unternehmen entlasten, die keine eigene Ausweichinfrastruktur betreiben möchten.

Typische Vorteile sind:

• geringere Investitionen in eigene Ersatzhardware,
• skalierbare Rechen- und Speicherkapazitäten,
• Unterstützung bei Failover und Wiederherstellung,
• zentral gesteuerte und teilweise automatisierte Abläufe,
• vertraglich vereinbarte Serviceleistungen.

Die Verantwortung kann jedoch nicht vollständig abgegeben werden. Das Unternehmen muss kontrollieren, ob der Anbieter die vereinbarten RTO- und RPO-Werte tatsächlich erfüllen kann.

On-Premises, Hybrid Cloud und Multicloud im Vergleich

Eine lokale DR-Lösung bietet dem Unternehmen eine hohe Kontrolle, erfordert aber eigene Hardware, Personal und einen ausreichend getrennten Ausweichstandort. Bei einer Hybrid-Cloud-Lösung verbleibt die Produktivumgebung teilweise im eigenen Rechenzentrum, während die Cloud als Wiederherstellungsumgebung dient.

Multicloud-Strategien verteilen Anwendungen oder Sicherungen auf mehrere Anbieter. Dadurch kann die Abhängigkeit von einer einzelnen Plattform reduziert werden. Gleichzeitig steigen jedoch Komplexität, Kosten und Anforderungen an die technische Kompetenz.

Worauf sollten Unternehmen bei einem DRaaS-Anbieter achten?

Vor Vertragsabschluss sollten insbesondere folgende Punkte geprüft werden:

• garantierte RTO- und RPO-Werte,
• Standorte der Rechenzentren und Daten,
• verfügbare Kapazitäten bei großflächigen Störungen,
• Schutz vor Ransomware und unbefugtem Zugriff,
• Verschlüsselung und Mandantentrennung,
• Unterstützung bei regelmäßigen Tests,
• Verantwortlichkeiten während eines Notfalls,
• Möglichkeiten zur Datenrückgabe und zum Anbieterwechsel.

Entscheidend ist zudem, ob die vereinbarten Leistungen nur die Infrastruktur oder auch Anwendungen, Datenbanken und technische Abhängigkeiten umfassen.

Failover, Failback und Switchover einfach erklärt

Failover, Failback und Switchover bezeichnen unterschiedliche Formen der Umschaltung zwischen primären und alternativen Systemen. Die Verfahren sollten detailliert geplant werden, da unkoordinierte Wechsel zu Datenverlusten, Inkonsistenzen oder zusätzlichen Ausfällen führen können.

Wie funktioniert ein Failover auf Ersatzsysteme?

Bei einem Failover werden Anwendungen oder Workloads nach einer Störung auf eine vorbereitete Ersatzumgebung übertragen. Die Umschaltung kann automatisch erfolgen oder von einem verantwortlichen Team ausgelöst werden.

Vor dem Failover muss geprüft werden, ob die primäre Umgebung tatsächlich nicht mehr nutzbar ist und ob die Ersatzsysteme einen vertrauenswürdigen Datenstand besitzen. Nach einem Cyberangriff ist besondere Vorsicht erforderlich, damit kompromittierte Daten oder Zugänge nicht übernommen werden.

Was passiert beim Failback zum Primärsystem?

Das Failback bezeichnet die Rückkehr von der Ersatzumgebung zum reparierten Primärsystem. Dabei müssen alle während des Notbetriebs entstandenen Daten sicher synchronisiert werden. Anschließend wird geprüft, ob Anwendungen, Schnittstellen und Benutzerzugriffe vollständig funktionieren.

Die Rückkehr sollte nicht vorschnell erfolgen. Solange das Primärsystem instabil ist oder die Ursache des Vorfalls nicht behoben wurde, kann ein Failback einen erneuten Ausfall verursachen.

Wann wird ein geplantes Switchover eingesetzt?

Ein Switchover ist eine kontrollierte Umschaltung auf ein alternatives System, obwohl kein akuter Notfall vorliegt. Es wird beispielsweise bei Wartungsarbeiten, Migrationen oder Disaster-Recovery-Tests eingesetzt.

Da beide Umgebungen grundsätzlich funktionieren, kann der Wechsel vorbereitet und überwacht durchgeführt werden. Ein erfolgreiches Switchover liefert zugleich wichtige Erkenntnisse darüber, ob die Ersatzumgebung unter realistischen Bedingungen einsatzfähig ist.

Disaster Recovery nach Ransomware und Cyberangriffen

Die Wiederherstellung nach einem Cyberangriff stellt besondere Anforderungen. Während bei einem Hardwaredefekt meist davon ausgegangen werden kann, dass vorhandene Daten unverändert sind, können Angreifer Systeme und Sicherungen gezielt manipulieren. Eine schnelle Wiederherstellung ist daher nur dann sinnvoll, wenn die verwendeten Daten und Systeme vertrauenswürdig sind.

Warum klassische Backups bei Ransomware nicht ausreichen können

Moderne Ransomware-Angriffe richten sich häufig auch gegen Backup-Systeme. Angreifer versuchen, Sicherungen zu verschlüsseln, zu löschen oder den Zugriff darauf zu verhindern. Teilweise bleiben sie über einen längeren Zeitraum unentdeckt, sodass auch ältere Backups bereits kompromittierte Dateien oder Benutzerkonten enthalten können.

Ein Backup allein schützt daher nicht zuverlässig vor sämtlichen Folgen eines Cyberangriffs. Unternehmen benötigen zusätzlich getrennte Sicherungssysteme, eingeschränkte Zugriffsrechte und dokumentierte Verfahren für eine sichere Wiederherstellung.

Wie schützen unveränderbare und isolierte Backups?

Unveränderbare Backups können innerhalb eines festgelegten Zeitraums weder überschrieben noch gelöscht werden. Dadurch wird verhindert, dass Angreifer mit übernommenen Administratorrechten sämtliche Sicherungen beseitigen.

Zusätzlichen Schutz bieten isolierte oder offline gespeicherte Kopien. Diese sind nicht dauerhaft mit der Produktivumgebung verbunden und daher schwerer erreichbar. Als Orientierung kann die 3-2-1-Regel dienen: drei Datenkopien auf zwei unterschiedlichen Medien, von denen sich mindestens eine an einem getrennten Standort befindet. Für einen verbesserten Schutz können Unternehmen dieses Prinzip um eine unveränderbare oder offline gespeicherte Kopie und regelmäßige Wiederherstellungstests ergänzen.

Warum müssen Daten vor der Wiederherstellung geprüft werden?

Vor der Rücksicherung sollte festgestellt werden, wann der Angriff begonnen hat und welche Systeme betroffen sind. Wird ein kompromittierter Datenstand verwendet, können Schadsoftware, manipulierte Konfigurationen oder unbefugte Zugänge erneut in die Umgebung gelangen.

Backups sollten deshalb technisch geprüft und zunächst in einer isolierten Umgebung wiederhergestellt werden. Neben Schadsoftware müssen auch Datenintegrität, Benutzerkonten, Zugriffsrechte und Systemkonfigurationen kontrolliert werden.

Wie funktioniert die Wiederherstellung kompromittierter Systeme?

Bei einer schwerwiegenden Kompromittierung ist ein sauberer Neuaufbau häufig sicherer als die direkte Weiterverwendung betroffener Systeme. Betriebssysteme und Anwendungen werden aus vertrauenswürdigen Quellen neu installiert, Sicherheitslücken geschlossen und Zugangsdaten ersetzt.

Die Wiederherstellung erfolgt anschließend schrittweise:

1. Angriff eindämmen und betroffene Systeme isolieren.
2. Ausmaß und Ursache des Vorfalls untersuchen.
3. Vertrauenswürdigen Wiederherstellungspunkt bestimmen.
4. Saubere Basisinfrastruktur aufbauen.
5. Daten und Anwendungen kontrolliert wiederherstellen.
6. Systeme prüfen und durch Fachbereiche freigeben.
7. Überwachung nach dem Wiederanlauf verstärken.

So wird verhindert, dass der Wunsch nach einer kurzen Ausfallzeit zu einer verfrühten und unsicheren Rückkehr in den Normalbetrieb führt.

Disaster-Recovery-Tests richtig planen und durchführen

Ein Disaster-Recovery-Plan ist erst dann belastbar, wenn seine Abläufe praktisch überprüft wurden. Tests zeigen, ob Sicherungen tatsächlich nutzbar sind, Verantwortliche ihre Aufgaben kennen und die festgelegten RTO- und RPO-Werte erreicht werden.

Tabletop-Übungen und theoretische Durchläufe durchführen

Bei einer Tabletop-Übung bearbeiten die beteiligten Personen gemeinsam ein angenommenes Ausfallszenario. Sie besprechen, wer den Vorfall bewertet, welche Eskalationswege gelten und in welcher Reihenfolge die Wiederherstellung erfolgen würde.

Diese Übungen sind vergleichsweise einfach durchzuführen und eignen sich gut, um organisatorische Schwächen aufzudecken. Technische Probleme werden dabei allerdings nur begrenzt sichtbar.

Technische Wiederherstellungs- und Failover-Tests umsetzen

Ein technischer Test prüft, ob Daten, Anwendungen oder vollständige Systeme auf einer Ersatzumgebung wiederhergestellt werden können. Je nach Risiko kann zunächst eine einzelne Anwendung getestet werden. Später sind umfangreichere Failover-Tests möglich.

Dabei sollte unter anderem kontrolliert werden:

• Sind die vorgesehenen Backups vollständig und lesbar?
• Funktionieren Anwendungen und Schnittstellen?
• Können sich berechtigte Benutzer anmelden?
• Werden die festgelegten RTO- und RPO-Werte eingehalten?
• Sind technische Anweisungen verständlich und aktuell?
• Reicht die Leistung der Ersatzumgebung aus?

Wie häufig sollte ein Disaster-Recovery-Plan getestet werden?

Die Testhäufigkeit hängt von der Kritikalität und Veränderungsgeschwindigkeit der Systeme ab. Mindestens einmal jährlich sollte eine umfassende Überprüfung erfolgen. Für besonders wichtige Anwendungen können häufigere technische Tests sinnvoll sein.

Zusätzliche Tests empfehlen sich nach größeren Migrationen, Architekturänderungen, Anbieterwechseln oder Sicherheitsvorfällen. Auch neue Abhängigkeiten und geänderte Zuständigkeiten müssen berücksichtigt werden.

Testergebnisse dokumentieren und Verbesserungen umsetzen

Nach jedem Test werden die gemessenen Wiederherstellungszeiten, aufgetretenen Fehler und Abweichungen vom Plan dokumentiert. Daraus entsteht eine Liste konkreter Verbesserungsmaßnahmen mit Verantwortlichen und Fristen.

Erst wenn erkannte Schwachstellen behoben und erneut geprüft wurden, ist der Testzyklus abgeschlossen. Disaster Recovery wird damit zu einem kontinuierlichen Verbesserungsprozess und nicht zu einem einmalig erstellten Dokument.

Gesetzliche Anforderungen an Disaster Recovery und IT-Notfallplanung

Anforderungen an Verfügbarkeit, Wiederherstellbarkeit und Notfallvorsorge können sich aus Datenschutzrecht, branchenspezifischen Vorschriften, Verträgen und anerkannten Sicherheitsstandards ergeben. Welche Pflichten konkret gelten, hängt unter anderem von Branche, Unternehmensgröße, verarbeiteten Daten und regulatorischer Einordnung ab.

Welche Anforderungen ergeben sich aus der DSGVO?

Die Datenschutz-Grundverordnung verlangt geeignete technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten. Dazu gehört auch die Fähigkeit, Verfügbarkeit und Zugang zu personenbezogenen Daten nach einem physischen oder technischen Zwischenfall zeitnah wiederherzustellen.

Die Maßnahmen müssen dem jeweiligen Risiko angemessen sein. Zudem sollen Unternehmen Verfahren zur regelmäßigen Überprüfung und Bewertung ihrer Schutzmaßnahmen vorsehen. Ein dokumentierter und getesteter Disaster-Recovery-Prozess kann dabei helfen, diese Anforderungen nachweisbar umzusetzen.

Die DSGVO schreibt jedoch keinen identischen Disaster-Recovery-Plan für alle Unternehmen vor. Umfang und technische Ausgestaltung müssen anhand der konkreten Risiken bestimmt werden.

Welche Bedeutung haben NIS2 und der BSI-Standard 200-4?

Die NIS2-Vorgaben stärken die Anforderungen an das Risikomanagement und die Aufrechterhaltung des Betriebs bei Sicherheitsvorfällen. Betroffene Organisationen müssen unter anderem Maßnahmen zu Backup-Management, Wiederherstellung nach Notfällen und Krisenmanagement berücksichtigen. Für die konkrete Umsetzung ist die jeweils geltende nationale Rechtslage maßgeblich.

Der BSI-Standard 200-4 stellt eine methodische Grundlage für den Aufbau eines Business Continuity Management Systems bereit. Er unterstützt Unternehmen dabei, zeitkritische Geschäftsprozesse zu identifizieren, Vorsorgemaßnahmen zu entwickeln und die Bewältigung von Notfällen zu organisieren. Die IT-Wiederherstellung wird dabei an den Anforderungen der Geschäftsprozesse ausgerichtet.

Wie unterstützen ISO 22301 und ISO 27001 die Notfallplanung?

Die ISO 22301 beschreibt Anforderungen an ein Business Continuity Management System. Sie betrachtet die Vorbereitung auf Betriebsunterbrechungen, die Reaktion darauf und die kontinuierliche Verbesserung der organisatorischen Widerstandsfähigkeit.

Die ISO/IEC 27001 konzentriert sich auf ein systematisches Informationssicherheitsmanagement. Disaster Recovery kann innerhalb dieses Rahmens dazu beitragen, die Verfügbarkeit von Informationen und IT-Systemen zu sichern.

Auch ohne angestrebte Zertifizierung können sich Unternehmen an beiden Standards orientieren. Wichtig ist, dass Notfallmaßnahmen dokumentiert, risikobasiert ausgewählt, regelmäßig getestet und bei Veränderungen angepasst werden. Verbindliche rechtliche Bewertungen sollten bei Bedarf mit spezialisierten Fachleuten vorgenommen werden.

Kosten von Disaster Recovery realistisch bewerten

Die Kosten einer Disaster-Recovery-Lösung hängen stark von den gewünschten Wiederherstellungszeiten ab. Je schneller Systeme wieder verfügbar sein und je weniger Daten verloren gehen dürfen, desto höher sind meist die technischen und organisatorischen Anforderungen. Unternehmen sollten daher nicht pauschal die kürzesten RTO- und RPO-Werte anstreben, sondern Kosten und tatsächliches Geschäftsrisiko miteinander vergleichen.

Welche Kosten verursacht eine Disaster-Recovery-Lösung?

Zu den möglichen Kosten gehören Backup-Speicher, Replikationssoftware, Netzwerkverbindungen, Lizenzen und eine lokale oder cloudbasierte Ersatzumgebung. Zusätzlich entstehen Aufwände für Planung, Dokumentation, Wartung und regelmäßige Tests.

Eine vollständige Kostenbetrachtung sollte insbesondere folgende Positionen berücksichtigen:

• Hard- und Software für Backups und Replikation,
• Cloud-Speicher und reservierte Rechenkapazitäten,
• zweiter Standort oder externe Ausweichumgebung,
• Betreuung durch interne IT-Fachkräfte,
• Leistungen externer IT- und DRaaS-Anbieter,
• Schulungen und Disaster-Recovery-Tests,
• regelmäßige Aktualisierung der Dokumentation.

Nicht jede Anwendung benötigt jedoch dieselbe Absicherung. Durch eine Einteilung in Kritikalitätsstufen können Unternehmen kostenintensive Lösungen gezielt für besonders wichtige Systeme einsetzen.

Wie lassen sich die Kosten eines IT-Ausfalls berechnen?

Den Investitionen sollten die möglichen Schäden einer Betriebsunterbrechung gegenübergestellt werden. Dazu gehören entgangene Umsätze, Produktionsstillstand, unproduktive Arbeitszeit, Vertragsstrafen und externe Wiederherstellungskosten.

Schwerer zu beziffern sind Reputationsschäden, Kundenverluste und mögliche regulatorische Folgen. Trotzdem sollten sie in die Risikobewertung einfließen. Ein Ausfall kann zunächst geringe Kosten verursachen, nach mehreren Stunden oder Tagen aber kritische Grenzen überschreiten.

Wie beeinflussen RTO und RPO die Gesamtkosten?

Ein RTO von wenigen Minuten erfordert häufig vorbereitete Ersatzsysteme und automatisierte Failover-Prozesse. Ein RPO nahe null setzt eine nahezu kontinuierliche Datenreplikation voraus. Beide Anforderungen erhöhen die laufenden Kosten und die technische Komplexität.

Kann ein weniger wichtiges System dagegen für 24 Stunden ausfallen und mit dem Datenstand des Vortags wiederhergestellt werden, genügt möglicherweise eine deutlich günstigere Backup-Lösung. Realistische Zielwerte vermeiden sowohl unzureichenden Schutz als auch unnötige Investitionen.

Wann lohnt sich DRaaS für mittelständische Unternehmen?

DRaaS kann sinnvoll sein, wenn ein Unternehmen keine eigene Ausweichinfrastruktur aufbauen oder dauerhaft betreiben möchte. Die Kosten werden dabei teilweise von hohen Anfangsinvestitionen auf laufende Servicegebühren verlagert.

Vor einer Entscheidung sollten Unternehmen prüfen, welche Leistungen tatsächlich enthalten sind. Ein günstiges Angebot bringt wenig, wenn Anwendungen im Ernstfall nur teilweise wiederhergestellt werden, Tests zusätzlich kosten oder zugesagte Kapazitäten bei einer größeren Störung nicht verfügbar sind.

Praxisbeispiel für Disaster Recovery im Mittelstand

Ein mittelständisches Produktionsunternehmen nutzt ein zentrales ERP-System für Bestellungen, Lagerbestände, Fertigungsaufträge und Rechnungen. Eine Business Impact Analysis hat gezeigt, dass ein längerer ERP-Ausfall nach vier Stunden erhebliche Auswirkungen auf Produktion und Lieferfähigkeit verursacht. Daher wurden ein RTO von vier Stunden und ein RPO von 30 Minuten festgelegt.

Ransomware legt ein geschäftskritisches ERP-System lahm

An einem Arbeitstag bemerkt die IT ungewöhnliche Anmeldeaktivitäten. Kurz darauf sind mehrere Server nicht mehr erreichbar und Dateien wurden verschlüsselt. Das IT-Team trennt betroffene Systeme vom Netzwerk und stoppt zunächst die automatische Replikation, damit die Schadsoftware nicht in die Ersatzumgebung gelangt.

Nach einer ersten Bewertung wird der Vorfall als Disaster-Recovery-Fall eingestuft. Das Krisenteam wird alarmiert und der vorbereitete Wiederherstellungsplan aktiviert.

Aktivierung des Disaster-Recovery-Plans im Unternehmen

Die IT prüft gemeinsam mit externen Sicherheitsexperten, welche Systeme betroffen sind und welcher Sicherungsstand als vertrauenswürdig gilt. Gleichzeitig informiert die Geschäftsleitung die relevanten Fachbereiche. Für dringende Aufträge werden vorbereitete manuelle Ersatzprozesse genutzt.

Die Wiederherstellung erfolgt in einer festgelegten Reihenfolge:

1. Saubere Netzwerk- und Identitätsdienste bereitstellen.
2. Neue Server aus vertrauenswürdigen Vorlagen aufbauen.
3. ERP-Datenbank aus einem geprüften Backup wiederherstellen.
4. Anwendung und erforderliche Schnittstellen starten.
5. Datenintegrität, Zugriffsrechte und Geschäftsprozesse prüfen.

Wiederherstellung nach definierten RTO- und RPO-Vorgaben

Nach dreieinhalb Stunden steht das ERP-System in einer isolierten Ersatzumgebung zur Verfügung. Die Fachabteilungen prüfen Bestellungen, Lagerbestände und offene Produktionsaufträge. Da der verwendete Datenstand 20 Minuten vor der Unterbrechung erstellt wurde, bleibt auch das RPO von 30 Minuten eingehalten.

Die fehlenden Transaktionen werden anhand vorhandener Unterlagen und Systemprotokolle nachgetragen. Anschließend wird die Anwendung kontrolliert für die Nutzer freigegeben.

Rückkehr zum Normalbetrieb und Lessons Learned

Nach Abschluss der forensischen Untersuchung wird die bereinigte Primärumgebung neu aufgebaut. Erst nachdem die Sicherheitslücke geschlossen, Zugangsdaten ersetzt und alle Systeme geprüft wurden, erfolgt das Failback.

In der Nachbereitung stellt das Unternehmen fest, dass eine interne Kontaktliste veraltet war und eine Schnittstelle im Runbook fehlte. Beide Punkte werden korrigiert und in einem weiteren Test überprüft. Das Beispiel zeigt: Ein Disaster-Recovery-Plan verhindert nicht den Angriff, verkürzt aber die Betriebsunterbrechung und reduziert folgenschwere Fehlentscheidungen.

Häufige Fehler bei der Disaster-Recovery-Planung

Selbst umfangreiche Notfallkonzepte können im Ernstfall scheitern, wenn wichtige Annahmen nicht überprüft wurden. Besonders häufig entstehen Probleme durch fehlende Tests, unklare Verantwortlichkeiten und eine zu starke Konzentration auf einzelne technische Komponenten.

Ein Backup wird mit Disaster Recovery gleichgesetzt

Vorhandene Datensicherungen bedeuten nicht automatisch, dass Anwendungen rechtzeitig wieder funktionieren. Ohne Ersatzsysteme, dokumentierte Abhängigkeiten und getestete Abläufe kann sich die Wiederherstellung erheblich verzögern.

Unternehmen sollten deshalb nicht nur die erfolgreiche Erstellung eines Backups kontrollieren, sondern den vollständigen Wiederanlauf wichtiger Geschäftsprozesse testen.

Systemabhängigkeiten bleiben bei der Planung unberücksichtigt

Eine wiederhergestellte Anwendung kann weiterhin unbrauchbar sein, wenn Datenbanken, Netzwerkverbindungen, Identitätsdienste oder externe Schnittstellen fehlen. Solche Abhängigkeiten müssen dokumentiert und in der Wiederherstellungsreihenfolge berücksichtigt werden.

Backups und Wiederherstellungsverfahren werden nicht getestet

Fehlerhafte Sicherungen fallen häufig erst bei der benötigten Rücksicherung auf. Regelmäßige Tests prüfen, ob Daten lesbar sind, Zugangsinformationen vorliegen und die vorgesehenen Zeiten eingehalten werden können.

Rollen und Entscheidungsbefugnisse bleiben unklar

Wenn niemand entscheiden darf, ob ein Failover aktiviert oder ein externer Dienstleister beauftragt wird, gehen wertvolle Stunden verloren. Für kritische Aufgaben müssen verantwortliche Personen und Vertretungen eindeutig benannt sein.

Der Disaster-Recovery-Plan wird nicht regelmäßig aktualisiert

IT-Umgebungen verändern sich durch neue Anwendungen, Cloud-Migrationen, Updates und Anbieterwechsel. Ein veralteter Plan kann auf nicht mehr vorhandene Systeme, ungültige Kontaktdaten oder ungeeignete Wiederherstellungsschritte verweisen.

Der Plan sollte daher mindestens regelmäßig sowie nach wesentlichen Veränderungen überprüft werden. Jede erkannte Abweichung benötigt eine konkrete Maßnahme, einen Verantwortlichen und einen Termin zur Umsetzung.

Disaster-Recovery-Checkliste für Unternehmen

Eine kompakte Checkliste hilft Unternehmen dabei, den aktuellen Stand ihrer Disaster-Recovery-Vorbereitung zu bewerten. Sie ersetzt keine ausführliche Risikoanalyse, kann jedoch grundlegende Schwachstellen sichtbar machen.

Organisatorische Vorbereitung auf IT-Notfälle prüfen

Folgende Fragen sollten eindeutig beantwortet werden können:

• Sind geschäftskritische Prozesse und IT-Systeme bekannt?
• Wurden RTO und RPO gemeinsam mit den Fachbereichen festgelegt?
• Gibt es einen freigegebenen Disaster-Recovery-Plan?
• Sind Verantwortliche und Vertretungen benannt?
• Ist geregelt, wer einen Disaster-Recovery-Fall ausrufen darf?
• Existieren alternative Kommunikationswege?
• Sind externe IT-Dienstleister in die Planung eingebunden?

Unklare Zuständigkeiten sollten vor einem Ernstfall beseitigt werden. Entscheidend ist nicht nur, dass verantwortliche Personen benannt sind, sondern auch, dass sie ihre Aufgaben und Entscheidungsbefugnisse kennen.

Technische Wiederherstellungsfähigkeit kontrollieren

Die technische Prüfung sollte über die Kontrolle erfolgreicher Backup-Protokolle hinausgehen. Unternehmen sollten nachvollziehbar belegen können, dass sich vollständige Systeme unter realistischen Bedingungen wiederherstellen lassen.

Dazu gehören folgende Punkte:

• Kritische Daten und Systeme werden regelmäßig gesichert.
• Mindestens eine Sicherung ist getrennt oder unveränderbar gespeichert.
• Backups sind gegen unbefugte Zugriffe geschützt.
• Anwendungs- und Systemabhängigkeiten sind dokumentiert.
• Eine geeignete Ersatzinfrastruktur steht zur Verfügung.
• Wiederherstellungsanweisungen wurden praktisch getestet.
• Verschlüsselungsschlüssel, Lizenzen und Zugangsdaten sind erreichbar.
• Die tatsächlichen Wiederherstellungszeiten sind bekannt.

Kommunikation, Dokumentation und Tests absichern

Der Disaster-Recovery-Plan sollte auch verfügbar sein, wenn das Unternehmensnetz, die E-Mail-Kommunikation oder die zentrale Dokumentenablage ausfällt. Eine geschützte Offline-Kopie kann deshalb sinnvoll sein.

Darüber hinaus sollten Unternehmen prüfen, ob der Plan versioniert, aktuell und für die verantwortlichen Personen zugänglich ist. Regelmäßige Übungen müssen dokumentiert und erkannte Schwachstellen nachverfolgt werden. Eine Checkliste gilt erst dann als erfüllt, wenn die Maßnahmen nicht nur beschrieben, sondern tatsächlich umgesetzt und getestet wurden.

Fazit – Disaster Recovery muss vor dem Ernstfall funktionieren

Disaster Recovery schafft die technischen und organisatorischen Voraussetzungen, um wichtige IT-Systeme nach einem Cyberangriff, technischen Defekt oder anderen schwerwiegenden Störfall kontrolliert wiederherzustellen. Ein vorhandenes Backup bildet dabei nur einen Teil der Lösung. Ebenso wichtig sind priorisierte Systeme, realistische Wiederherstellungsziele, dokumentierte Abhängigkeiten und eindeutig geregelte Verantwortlichkeiten.

Die Business Impact Analysis zeigt, welche Prozesse besonders zeitkritisch sind. Darauf aufbauend legen Unternehmen passende RTO- und RPO-Werte fest und wählen eine geeignete Wiederherstellungsstrategie. Während für weniger wichtige Systeme klassische Backups ausreichen können, benötigen geschäftskritische Anwendungen möglicherweise Replikation, vorbereitete Ersatzsysteme oder eine cloudbasierte DRaaS-Lösung.

Besondere Vorsicht ist nach Ransomware und anderen Cyberangriffen erforderlich. Die schnellste Wiederherstellung ist nicht automatisch die sicherste. Bevor Systeme erneut in Betrieb gehen, müssen Backups, Benutzerkonten und Konfigurationen auf mögliche Kompromittierungen geprüft werden.

Ob ein Disaster-Recovery-Plan tatsächlich belastbar ist, lässt sich nur durch regelmäßige Tests feststellen. Dabei sollten Unternehmen nicht nur technische Prozesse kontrollieren, sondern auch Kommunikation, Entscheidungen und Zusammenarbeit der beteiligten Bereiche einbeziehen. Erkenntnisse aus Übungen und realen Vorfällen müssen anschließend in die Planung zurückfließen.

Disaster Recovery ist daher kein einmaliges IT-Projekt. Es handelt sich um einen kontinuierlichen Prozess, der mit der Infrastruktur und den Anforderungen des Unternehmens weiterentwickelt werden muss.

Häufig gestellte Fragen zu Disaster Recovery

Disaster Recovery umfasst zahlreiche technische und organisatorische Aspekte. Die folgenden Antworten fassen die wichtigsten Fragen zur IT-Notfallwiederherstellung kompakt zusammen.

Was bedeutet Disaster Recovery einfach erklärt?

Disaster Recovery bezeichnet alle Maßnahmen, mit denen ein Unternehmen seine IT-Systeme, Anwendungen und Daten nach einem schwerwiegenden Ausfall wiederherstellt. Das Ziel besteht darin, Betriebsunterbrechungen und Datenverluste auf ein zuvor festgelegtes Maß zu begrenzen.

Was ist ein Disaster-Recovery-Plan?

Ein Disaster-Recovery-Plan ist eine dokumentierte Anleitung für die Wiederherstellung der IT nach einem Notfall. Er enthält unter anderem Verantwortlichkeiten, Kontaktdaten, Wiederherstellungsziele, Systemprioritäten, technische Runbooks und Kommunikationswege.

Was ist der Unterschied zwischen Backup und Disaster Recovery?

Ein Backup ist eine zusätzliche Kopie von Daten. Disaster Recovery umfasst dagegen den vollständigen Wiederanlauf der benötigten IT-Infrastruktur. Dazu gehören neben den Daten auch Anwendungen, Server, Netzwerke, Zugänge und dokumentierte Wiederherstellungsprozesse.

Was bedeuten RTO und RPO?

Das Recovery Time Objective beschreibt, innerhalb welcher Zeit ein ausgefallenes System wieder verfügbar sein soll. Das Recovery Point Objective legt fest, wie viele Daten gemessen in Zeit höchstens verloren gehen dürfen.

Wie häufig sollte Disaster Recovery getestet werden?

Eine umfassende Überprüfung sollte in der Regel mindestens einmal jährlich erfolgen. Geschäftskritische Systeme können häufigere Tests erfordern. Weitere Prüfungen sind nach größeren technischen Veränderungen, Anbieterwechseln oder Sicherheitsvorfällen sinnvoll.

Ist Disaster Recovery auch für kleinere Unternehmen notwendig?

Auch kleinere Unternehmen sind von IT-Systemen, Cloud-Diensten und digitalen Daten abhängig. Umfang und Kosten der Maßnahmen können an den tatsächlichen Schutzbedarf angepasst werden. Entscheidend ist, dass kritische Daten gesichert und die wichtigsten Geschäftsprozesse innerhalb eines akzeptablen Zeitraums wiederhergestellt werden können.

Was ist Disaster Recovery as a Service?

Disaster Recovery as a Service ist eine Dienstleistung, bei der ein externer Anbieter cloudbasierte Infrastruktur und Funktionen für die Wiederherstellung bereitstellt. Je nach Vertrag kann der Anbieter auch Replikation, Failover, Tests und technische Unterstützung übernehmen.

Disaster-Recovery-Fähigkeit professionell überprüfen lassen

Ein Disaster-Recovery-Plan bietet nur dann verlässlichen Schutz, wenn er zur tatsächlichen IT-Umgebung passt und unter realistischen Bedingungen funktioniert. Ungetestete Backups, fehlende Systemabhängigkeiten oder unklare Zuständigkeiten können die Wiederherstellung im Ernstfall erheblich verzögern.

Möchten Sie wissen, ob Ihre geschäftskritischen Systeme nach einem Cyberangriff oder technischen Ausfall innerhalb der erforderlichen Zeit wieder verfügbar wären? Lassen Sie Ihre bestehende Disaster-Recovery-Strategie, Ihre Backup-Prozesse und Ihre Wiederherstellungsziele professionell überprüfen. Gemeinsam können Schwachstellen identifiziert und konkrete Maßnahmen für einen belastbaren Disaster-Recovery-Plan entwickelt werden.