Die nahezu kontinuierliche Verfügbarkeit von IT-Diensten ist heute eine Grundvoraussetzung für den Unternehmenserfolg. Umso wichtiger wird eine durchdachte als unerlässliches Element im Business Continuity Management. Grundlage jeder Wiederanlaufplanung sind dabei zwei Kennzahlen: Das Recovery Time Objective (RTO) definiert die geforderte Wiederanlaufzeit. Das Recovery Point Objective (RPO) legt fest, wie viel Datenverlust im Ernstfall akzeptabel ist. Beide bestimmen, welche technischen und organisatorischen Maßnahmen ein Unternehmen treffen muss. Bis vor wenigen Jahren bezog sich die Wiederanlaufplanung vor allem auf eigenbetriebene, lokale Rechenzentren. Mit der Verlagerung von Unternehmens-IT in die Cloud verändern sich die Voraussetzungen grundlegend.
Ein weit verbreiteter Irrglaube in diesem Zusammenhang ist, dass mit der Migration in die Cloud auch die Verantwortung für das Disaster Recovery inklusive Wiederanlaufplanung vollends an den Cloud Provider abgegeben wird. Das Gegenteil ist der Fall: Auch bei der Verlagerung der IT in die Cloud bleibt die Verantwortung zur Wiederanlaufplanung vollumfänglich beim verlagernden Unternehmen.
Shared Responsibility Model: Eigenverantwortung je nach Service-Modell
Wie weit diese Eigenverantwortung reicht, hängt vom gewählten Service-Modell ab. Das Shared Responsibility Model regelt, welche Schichten der Provider verantwortet und welche beim Unternehmen liegen. Bei Infrastructure as a Service (IaaS) etwa trägt das Unternehmen die volle Verantwortung für Betriebssystem, Applikationen und Daten. Bei Platform as a Service (PaaS) übernimmt der Provider zusätzlich Teile der Plattform- und Laufzeitumgebung. Die Eigenverantwortung variiert jedoch je nach genutztem Dienst erheblich. Bei Software as a Service (SaaS) hingegen bezieht das Unternehmen ein vollständiges Produkt meistens ohne Server-Administrationsmöglichkeit. Eigene technische Recovery-Maßnahmen sind kaum umsetzbar. Deshalb sollte die Wiederanlaufmöglichkeit bereits vor Vertragsabschluss mit dem Anbieter geklärt und vertraglich verankert werden. Orientierung bietet der BSI C5-Kriterienkatalog.
Klassischer Wiederanlauf On-Premises: Physische und logische Kontrolle
Die klassische Wiederanlaufplanung im On-Premises-Umfeld zeichnet sich durch die vollständige physische und logische Kontrolle des Unternehmens über die gesamte IT-Infrastruktur aus. Fällt das primäre Rechenzentrum durch einen Störfall aus, wird der Betrieb je nach gewählter Continuity-Strategie beispielsweise in einem physisch getrennten Ausweichrechenzentrum (Redundanzprinzip), über Ersatzinfrastruktur (Cold Standby) oder über definierte Wiederherstellungsverfahren wiederaufgenommen. Die große Gemeinsamkeit zu modernen Cloud-Ansätzen liegt hierbei in der Notwendigkeit einer präzisen Vorbereitung: Ohne eine fundierte Dokumentation und technische Resilienz ist ein rechtzeitiger Wiederanlauf kaum sicherzustellen. In diesem klassischen Szenario sind die dokumentierten Wiederanlaufpläne stark von der physischen Realität der Hardware geprägt. Die entsprechenden Wiederanlaufpläne beschreiben in der Regel detailliert manuelle oder teilautomatisierte Prozesse, u. a.:
- Welche Infrastrukturkomponenten, etwa Storage, Netzwerkswitche, Firewalls, Virtualisierungshosts oder physische Server, müssen zuerst bereitgestellt oder gestartet werden?
- Wie wird das Backup von physischen Bandlaufwerken oder Disk-Systemen schrittweise in die Standby-Umgebung eingespielt?
- Wie wird überprüft, ob die eingespielten Daten konsistent und vollständig sind?
- Wer gibt die Freigabe, dass das wiederangelaufene System durch den Fachbereich produktiv genutzt werden kann?
Das Unternehmen trägt in diesem Konzept die alleinige operative Verantwortung für sämtliche Schichten – von der Stromversorgung über die Hardware bis hin zur Applikation. Redundante Hardware muss kontinuierlich vorgehalten, klimatisiert und gewartet werden. Da Testläufe dieser Infrastruktur oft tief in den regulären Netzwerkbetrieb eingreifen, erfordern sie in der Regel fest eingeplante, größere Wartungsfenster. Hinzu kommt, dass Notfalltests die Wiederanlaufplanung häufig nur simuliert prüfen. Einen realen Ausfall nachzustellen, scheuen viele Unternehmen, weil das Risiko für den laufenden IT-Betrieb zu hoch erscheint.
Wiederanlauf in der Cloud: Logische Architekturen, neue Verantwortlichkeiten
Bei der Verlagerung von Workloads in die Cloud wandelt sich die Natur der IT-Infrastruktur von physischen Geräten hin zu softwaredefinierten, API-gesteuerten Ressourcen. Diese Abstraktion der physischen Ebene verändert nicht die grundlegenden Fragestellungen, wohl aber die konkreten Inhalte und technischen Maßnahmen im Wiederanlaufplan. Statt sich zusätzlich mit Stromversorgung und physischen System-Boot-Reihenfolgen zu beschäftigen, verlagert sich der Fokus der Wiederanlaufpläne stärker auf logische, organisatorische und providerbezogene Abhängigkeiten und auf eine entscheidende Erkenntnis: Die Cloud stellt zwar technische Bausteine für Resilienz und Wiederanlauf bereit, ist aber nicht automatisch „DR-ready“.
Georedundanz, automatisches Failover und Datensicherung müssen aktiv konfiguriert sowie regelmäßig und risikoorientiert getestet werden. Das Prinzip der Bereitschaftsmodelle – die Verteilung von Ressourcen über physisch getrennte Standorte – ist sowohl aus On-Premises- als auch Cloud-Umgebungen bekannt. Der wesentliche Unterschied liegt in der Umsetzung: Während klassische Rechenzentren dafür erhebliche Investitionen in Hardware und Infrastruktur an einem zweiten Standort erfordern, bietet die Cloud durch ihr globales Netz aus Regionen und „Availability Zones“ (AZs) eine flexibel konfigurierbare Grundlage.
Dabei ist klar zu unterscheiden: Multi-AZ, also der Betrieb über mehrere Availability Zones innerhalb einer Region, schützt vor dem Ausfall einzelner Rechenzentren innerhalb derselben Region, ist jedoch nicht standardmäßig für alle Dienste aktiv. Auch datenbankspezifische Besonderheiten müssen berücksichtigt werden. Je nach Cloud-Dienst unterscheiden sich die Resilienzmechanismen erheblich: Manche Datenbankdienste replizieren Daten automatisch über mehrere Availability Zones, während andere erst durch explizite Multi-AZ-Konfiguration eine automatische Failover-Funktion bereitstellen. Ein vollständiges Cross-Region-Failover geht darüber hinaus und erfordert zusätzliche Mechanismen, um Anwendungen, Datenbanken, DNS-Einträge und Benutzeranfragen automatisch oder kontrolliert auf eine geografisch entfernte Region umzuleiten.
Auch die Lastverteilung spielt im Cloud-Wiederanlauf eine zentrale Rolle. Regionale „Application-Load-Balancing“-Dienste können eingehende Anfragen auf mehrere Zielsysteme, Availability Zones oder Anwendungsinstanzen verteilen und damit die Ausfallsicherheit innerhalb einer Region erhöhen. Für Disaster-Recovery-Szenarien reicht ein regionaler Load Balancer jedoch nicht aus, wenn eine komplette Region betroffen ist. In solchen Fällen müssen globale Routing-Mechanismen, DNS-Failover oder Traffic-Management-Dienste eingeplant werden, um den Datenverkehr im Fehlerfall auf eine alternative Region umzuleiten.
Für die IT-Verantwortlichen des verlagernden Unternehmens ergeben sich daraus konkrete Arbeitsschritte und Aufgaben, die detailliert in den Wiederanlaufplänen dokumentiert werden müssen. Dazu gehören unter anderem die Konfiguration von Multi-AZ- und Cross-Region-Architekturen, die Absicherung und Wiederherstellung von Datenbanken, die Definition von Failover-Prozessen, die Dokumentation von Load-Balancing- und DNS-Mechanismen sowie regelmäßige Tests der Wiederanlaufverfahren. Nur wenn diese technischen und organisatorischen Abhängigkeiten vollständig verstanden, dokumentiert und überprüft werden, kann die Cloud im Ernstfall tatsächlich als belastbare Grundlage für den Wiederanlauf dienen.
Wiederanlaufplanung unter veränderten Rahmenbedingungen
Die Gegenüberstellung beider Konzepte zeigt deutlich, dass das übergeordnete Ziel der Wiederanlaufplanung – die zeitnahe Sicherstellung des Geschäftsbetriebs – bei On-Premises- und Cloud-Lösungen identisch ist. Auch der Bedarf an ausführlicher Dokumentation und Planung ist in beiden Modellen unumgänglich. Dennoch existieren fundamentale Unterschiede in der technischen Umsetzung: Die Cloud bietet durch ihre softwaredefinierte Architektur eine wesentlich stärkere Automatisierung und eine weitaus schnellere technische Bereitstellung von IT-Ressourcen im Ernstfall.
Gleichzeitig verlangt die Cloud-Nutzung klare Verantwortlichkeiten. Unternehmen müssen erkennen, dass sie die Verantwortung für den Wiederanlauf ihrer Daten und Anwendungen nicht an den Provider delegieren können. Dies erfordert von IT-Verantwortlichen einen gänzlich anderen technischen Blickwinkel, der sich von physischer Hardware abwendet und logische Architekturen, Skripte sowie Service-Abhängigkeiten in den Fokus rückt. Hyperscaler bieten grundsätzlich gute Service Level Agreements (SLAs), die hohe Verfügbarkeiten garantieren, ja sogar Georedundanz ermöglichen und Unternehmen so eine flexible, hochmoderne Basis für ihr Business Continuity Management ermöglichen. Letztlich gilt aber weiterhin: Eine belastbare, eigene und gut dokumentierte Wiederanlaufplanung bleibt technologieübergreifend die wichtigste Aufgabe für jede IT-Abteilung.