Standort- und Cloud-Recovery: Bereitschaft, Umschaltung, Rückkehr

„Wir haben ein zweites Rechenzentrum“ ist keine Aussage über Wiederherstellbarkeit. Dieses Modul macht drei daraus: wie lange es dauert, dort produktiv zu sein, wie viel dort gleichzeitig laufen kann und welcher Datenstand ankommt. Dazu die beiden Fehler, die am teuersten sind — eine Gültigkeitsdauer, die erst im Ernstfall gesenkt wird und deshalb einen Tag lang gar nichts bewirkt, und zwei Standorte, die gleichzeitig Schreibzugriffe annehmen und einen Schaden erzeugen, den keine Sicherung heilt.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Ein zweiter Standort ist keine Adresse, sondern eine Zusage

„Wir haben ein zweites Rechenzentrum“ ist keine Aussage über Wiederherstellbarkeit. Die Aussage entsteht erst aus drei Angaben: wie lange es dauert, dort produktiv zu sein, wie viel dort gleichzeitig laufen kann, und welcher Datenstand dort ankommt.

Fehlt eine dieser drei, ist der zweite Standort ein Kostenposten mit beruhigender Wirkung. Besonders die zweite Angabe wird regelmäßig übersehen, weil sie im Normalbetrieb nie geprüft wird: Solange dort nur Repliken liegen, fällt niemandem auf, dass die Rechenleistung für den Ernstfall nicht reicht.

Warum dieses Modul nach der Lageführung kommtDie Umschaltung auf einen zweiten Standort ist keine technische Einzelmaßnahme, sondern eine Entscheidung mit Wellen, Toren und einer Rückkehr. Sie setzt voraus, dass jemand ausrufen darf, dass die Reihenfolge feststeht und dass es einen Weg zurück gibt — alles Gegenstand der vorigen Module.

Umschaltbereitschaft — Die belegte Fähigkeit, den Betrieb innerhalb einer zugesagten Zeit auf den zweiten Ort zu verlagern — mit ausreichender Kapazität für den vereinbarten Umfang und einem benannten Datenstand. Alle drei Angaben zusammen, einzeln ist keine davon eine Zusage.

Fünf Ausprägungen mit sehr verschiedenen Zusagen

NIST SP 800-34 unterscheidet Ausweichstandorte nach ihrem Ausstattungsgrad. Die Einteilung ist alt und trägt trotzdem, weil sie nicht nach Technik sortiert, sondern nach dem, was im Ernstfall noch zu tun bleibt.

Kalt: Nur Grundinfrastruktur — Strom, Klima, Platz. Keine Technik, keine Anbindung. Am günstigsten, mit der längsten Wiederanlaufzeit: Alles muss beschafft, aufgebaut, geprüft und mit Daten geladen werden.
Warm: Rechen- und Kommunikationstechnik vorhanden, aber ohne Software und Daten. Braucht laut Dokumentation Lesegeräte, die zur eigenen Sicherungsstrategie passen — und reicht oft nur für die kritischen Prozesse, nicht für alle.
Heiß: Voll ausgestattet, aktuelle Software installiert, ausreichender Speicher, die jüngste Sicherung bereits geladen — es bleibt die Aktualisierung seit der letzten Sicherung. Braucht zusätzlich einen Weg, die Nutzer schnell umzuleiten.
Mobil: Transportable, eigens ausgestattete Einheiten. Laut Dokumentation oft binnen 24 Stunden lieferbar — Aufbau und Einrichtung kommen darauf.
Gespiegelt: Vollständig redundante Einrichtung mit automatischer Spiegelung in Echtzeit, in allen technischen Belangen identisch. Die teuerste Wahl, dafür nahezu vollständige Verfügbarkeit.

Der praktische Nutzen dieser Liste liegt in der Ehrlichkeit, zu der sie zwingt. Die meisten Betriebe halten für einen warmen Standort eine Zusage bereit, die einen heißen beschreibt. Der Unterschied besteht in genau zwei Punkten — geladene Software und geladene Daten — und beide kosten im Ernstfall Stunden bis Tage.

Die Cloud verschiebt die Einteilung, hebt sie nicht aufBei einem Anbieter lässt sich Kapazität in Minuten anfordern, was einen kalten Standort scheinbar überflüssig macht. Zwei Fragen bleiben trotzdem dieselben: Ist die Kapazität in der Zielregion im Ernstfall verfügbar — ein regionaler Ausfall trifft viele Kunden gleichzeitig — und wie lange dauert es, Daten, Konfiguration und Identität dort betriebsbereit zu machen? Wer beides nicht vorbereitet hat, betreibt keinen heißen Standort, sondern einen kalten mit kurzer Beschaffungszeit.

Was am Ausweichstandort meistens fehlt

Der Ausweichstandort wird nach der Größe dimensioniert, die man sieht: dem Speicherplatz. Was er unter Last leisten muss, fällt erst auf, wenn die Last da ist — also im Ernstfall. Dass NIST die Leistung auf Ersatzausrüstung als eigenen Prüfbereich für Wiederanlauftests führt, hat genau diesen Grund.

Rechenleistung und Arbeitsspeicher für den Vollbetrieb, nicht für die Replikation. Repliken brauchen kaum etwas; Anwendungen brauchen alles.
Anbindung nach außen in der Bandbreite des Hauptstandorts — Nutzer, Schnittstellenpartner, Anbieterdienste greifen nach der Umschaltung dort zu.
Gleichzeitigkeit. Kapazität für die Hälfte der Systeme ist eine gute Nachricht, wenn sie geplant ist, und eine schlechte, wenn sie im Ernstfall entdeckt wird.
Betriebsfähigkeit. Wer betreibt dort? Überwachung, Sicherung und Rufbereitschaft müssen für den Ausweichbetrieb ebenfalls funktionieren, oft mit anderen Werkzeugen.

Die Prüfung, die diesen Punkt entscheidetSie besteht nicht darin, den Standort zu besichtigen, sondern darin, dort unter realistischer Last zu messen — und zwar bei laufender Produktion am Hauptstandort, damit die geteilten Ressourcen mit berücksichtigt sind. Das ist aufwendig, und genau deshalb wird stattdessen die Speichergröße verglichen. Die ehrliche Zwischenlösung ist eine Rechnung: Prozessorkerne, Arbeitsspeicher und Durchsatz je Dienst aufsummieren und der verfügbaren Kapazität gegenüberstellen. Sie ersetzt keine Messung und findet die groben Fälle.

Was die Replikation nicht mitbringt

Repliziert werden Daten. Alles, was einen Dienst darüber hinaus erreichbar und benutzbar macht, ist Konfiguration der Umgebung — und die ist am Ausweichstandort eine andere.

Netz und Adressen: Andere Adressbereiche, andere Wegewahl, andere Namensauflösung. Alles, was Adressen fest verdrahtet hat, funktioniert dort nicht.
Filterregeln: Freigaben, die am Hauptstandort über Jahre gewachsen sind, existieren am Ausweichstandort in der Regel nicht — und ihre Liste kennt niemand vollständig.
Identität und Berechtigungen: Anmeldung, Verzeichnisdienst, Dienstkonten. Sie müssen dort funktionieren, bevor irgendein Dienst startet.
Zertifikate und Lizenzen: Beide mit eigener Bindung an Namen oder Hardware — und mit eigenen Ausstellungswegen, die im Ernstfall erreichbar sein müssen.
Der Plan selbst: Runbooks, Kontaktlisten, Zugangsdaten. Liegen sie nur am Hauptstandort, sind sie genau dann weg, wenn der Ausweichstandort gebraucht wird.

Die zweite Zeile ist die unangenehmste, weil sie sich nicht durch Nachdenken lösen lässt. Gewachsene Filterregeln sind ein Bestand, den man nur durch Übertragung oder Übung findet. Wer den Ausweichstandort nie unter echtem Verkehr betrieben hat, wird im Ernstfall Stunden mit Freigaben verbringen, die niemand vorher als fehlend erkennen konnte.

Schreibhoheit: genau eine Seite

Schreibhoheit — Die Eigenschaft genau einer Seite, Änderungen entgegennehmen zu dürfen. Sie ist nicht teilbar: Nehmen beide Seiten Schreibzugriffe an, entstehen zwei Datenstände, die sich nicht mehr automatisch zusammenführen lassen.

Das ist die wichtigste Einzelregel dieses Moduls, und ihre Verletzung erzeugt den einen Schaden, den keine Sicherung heilt. Ein Restore stellt einen Zeitpunkt wieder her; zwei divergierte Stände lassen sich nicht auf einen Zeitpunkt zurückführen, ohne die Arbeit einer Seite zu verwerfen.

Die Übergabe muss ein Vorgang sein, kein Zustand, der sich ergibt: Erst nimmt die alte Seite keine Schreibzugriffe mehr an, dann übernimmt die neue.
Der Zweifelsfall gehört entschieden, nicht ausgesessen. Wenn unklar ist, ob die alte Seite noch schreibt, ist die Antwort, sie sicher stillzulegen — nicht, die neue vorsichtshalber freizugeben.
Eine dritte Instanz hilft, wenn beide Seiten sich nicht sehen: ein Zeuge an einem dritten Ort, der die Mehrheit entscheidet.
Der Preis ist Verfügbarkeit. Eine Konstruktion, die im Zweifel niemanden schreiben lässt, steht lieber still, als zu divergieren — und dieser Kompromiss gehört ausgesprochen.

Woran man den Fehler erkennt, wenn er schon passiert istDivergenz meldet sich nicht als Fehler, sondern als Widerspruch: Ein Vorgang existiert auf der einen Seite und nicht auf der anderen, Zähler laufen auseinander, eine Auswertung liefert je nach Einstiegspunkt andere Zahlen. Wer diesen Zustand vermutet, hört sofort auf beiden Seiten mit dem Schreiben auf — das ist teuer und billiger als jede weitere Minute, in der die Stände weiter auseinanderlaufen. Danach ist es eine fachliche Aufgabe: Welche Seite gilt, und was von der anderen wird von Hand übertragen.

Die Umschaltung und ihre Zwischenspeicher

Die technische Umschaltung läuft meist über die Namensauflösung: Der Name zeigt künftig auf die andere Adresse. Wie schnell das bei den Clients ankommt, entscheidet nicht die eigene Änderung, sondern die Gültigkeitsdauer, die vorher ausgeliefert wurde.

Die Gültigkeitsdauer, die man eine Woche vorher senkt

Szenario

Für die Umschaltung auf den Ausweichstandort soll die Gültigkeitsdauer der Einträge von 86.400 Sekunden auf 300 gesenkt werden, damit Clients schnell folgen. Der Plan sieht vor, die Senkung unmittelbar vor der Umschaltung vorzunehmen.

Anforderungen

Nach der Umschaltung sollen Clients binnen Minuten auf die neue Adresse zeigen.
Der Plan soll auch unter Zeitdruck funktionieren.

Schritte

Erkennen, dass Auflöser den alten Wert bereits zwischengespeichert haben — mit der alten Gültigkeitsdauer von einem Tag.
Daraus folgern: Die gesenkte Gültigkeitsdauer erreicht einen Auflöser erst, wenn der alte Eintrag abgelaufen ist. Bis zu 24 Stunden lang gilt weiterhin der alte Wert.
Die Senkung deshalb mindestens eine alte Gültigkeitsdauer im Voraus vornehmen — bei einem Tag also am Vortag, mit Sicherheitsabstand besser eine Woche.
RFC 2181 zur Kenntnis nehmen: Die Gültigkeitsdauer gibt eine maximale, keine verbindliche Haltedauer an, und Implementierungen dürfen eine eigene Obergrenze setzen und größere Werte als diese Obergrenze behandeln.
Daraus die ehrliche Zusage ableiten: Eine Untergrenze für die Umschaltdauer ist planbar, eine Obergrenze über alle Clients hinweg nicht — deshalb braucht der Plan zusätzlich einen Weg, der ohne die Namensauflösung auskommt.

Merksatz: Die Senkung der Gültigkeitsdauer wirkt erst, nachdem die alte abgelaufen ist. Sie gehört damit in die Vorbereitung, nicht in den Ablauf — und wer sie erst im Ernstfall vornimmt, hat für die Dauer der alten Gültigkeit gar nichts erreicht.

Was außer dem Namen noch umgeschaltet werden muss

Selbst eine perfekt vorbereitete Namensumschaltung erreicht nicht alles. Vier Klassen von Verbindungen folgen ihr nicht oder nur verzögert, und jede davon erzeugt im Ernstfall eigene Fehlerbilder.

Fest eingetragene Adressen. In Konfigurationsdateien, Geräten, Skripten und bei Partnern. Sie folgen nie und müssen einzeln geändert werden.
Bestehende, langlebige Verbindungen. Sie halten an der alten Adresse fest, bis sie abbrechen — ein Neustart der Gegenseite ist oft schneller als das Warten.
Freigabelisten bei Partnern. Wenn die neue Adresse dort nicht eingetragen ist, hilft die Umschaltung nichts. Diese Änderung braucht Vorlauf bei einem Dritten.
Zwischenspeicher in Anwendungen. Manche Laufzeitumgebungen halten aufgelöste Adressen unabhängig von der Gültigkeitsdauer bis zum Neustart.

Die Konsequenz für den PlanDie Umschaltung ist keine einzelne Handlung, sondern eine Liste. Sie gehört vorher zusammengetragen — je Dienst, mit den Partnern, die etwas ändern müssen, und den Systemen, die einen Neustart brauchen. Der Aufwand dafür fällt einmal an; im Ernstfall wird diese Liste zur Reihenfolge, und ohne sie entsteht sie unter Zeitdruck aus Anrufen.

Die dritte Zeile verdient besondere Aufmerksamkeit, weil sie außerhalb der eigenen Reichweite liegt. Eine Freigabeliste bei einem Partner zu ändern, dauert im Alltag Tage und im Ernstfall so lange, wie dessen Bereitschaft braucht. Deshalb gehört die Ausweichadresse dort vorher eingetragen — im Rahmen der normalen Zusammenarbeit, lange bevor sie gebraucht wird. Das ist eine der wenigen Vorbereitungen dieses Tracks, die vollständig aus Kommunikation besteht und im Ernstfall Stunden spart.

Umschaltung üben, ohne umzuschalten

Ein vollständiger Umschalttest im Produktivbetrieb ist teuer und riskant; deshalb bieten die meisten Verfahren einen Testmodus an, der die Zielumgebung in einem abgetrennten Netz hochfährt, ohne die Schreibhoheit zu verschieben. Was er beweist, ist erheblich — und was er nicht beweist, muss man wissen.

Kurzcheck

Ein Testumschalten in ein abgetrenntes Netz war erfolgreich: Alle Systeme starteten in der geplanten Reihenfolge, die Anwendungen liefen. Welche Aussage ist damit nicht belegt?

Dass die Umschaltung der Clients und der Partner funktioniert.
Dass der replizierte Datenstand am Zielort lesbar ist.
Dass die Startreihenfolge der Systeme stimmt.

Treffer. Richtig. Ein abgetrenntes Netz prüft den Anlauf der Systeme und lässt genau die Außenwirkung aus — Namensauflösung, fest eingetragene Adressen, Freigabelisten bei Partnern. Das ist der Teil, der im Ernstfall die meiste Zeit kostet.

Daraus folgt kein Verzicht auf den Test, sondern seine ehrliche Einordnung im Bericht: Er belegt Anlauf und Reihenfolge und lässt die Außenwirkung offen. Diese Lücke schließt nur ein angekündigtes Zeitfenster mit echter Umschaltung — selten, teuer und die einzige Prüfung, die die zugesagte Umschaltdauer tatsächlich misst.

Die Rückkehr ist ein eigener Change

Der Ausweichbetrieb ist ein Zwischenzustand, und der Weg zurück wird regelmäßig als „das Gleiche rückwärts“ geplant. Er ist es nicht, aus einem einzigen, entscheidenden Grund: Die Datenhoheit hat gewechselt. Am Ausweichstandort sind seit der Umschaltung Daten entstanden, die es am Hauptstandort nie gab.

Beim Umschalten: Der Zielstand ist ein bekannter Replikationsstand; die Lücke ist die Replikationsverzögerung.
Bei der Rückkehr: Der Zielstand ist veraltet und muss zuerst vom Ausweichstandort aufgeholt werden — in umgekehrter Richtung, oft über eine Leitung, die dafür nicht ausgelegt war.
Der zusätzliche Prüfschritt: Vor dem Zurückschalten muss die Kapazität des Hauptstandorts erneut bestätigt werden — er war beschädigt, und was dort inzwischen instand gesetzt wurde, ist eine Annahme, bis es geprüft ist.

Warum die Rückkehr trotzdem geplant gehörtWeil sie sonst unterbleibt. Ein Ausweichbetrieb, der „vorläufig“ weiterläuft, wird nach einigen Wochen zum Normalbetrieb an einem Standort, der dafür nicht ausgelegt ist — mit der Sicherungsarchitektur, den Zusagen und der Kapazitätsplanung des Ausweichfalls. Der Rückweg gehört deshalb mit Termin und Bedingungen in dieselbe Entscheidung wie die Umschaltung.

Praktisch heißt das, den Rückweg wie eine zweite Umschaltung zu behandeln: mit eigener Bereitschaftsprüfung, eigener Übergabe der Schreibhoheit, eigenem Zeitfenster und eigener Abnahme. Die Versuchung, ihn als Aufräumarbeit zu behandeln, ist groß — der Druck ist weg, alle sind erschöpft, und es läuft ja. Genau in dieser Stimmung entstehen die Fehler, die während der eigentlichen Lage vermieden wurden.

Die Bereitschaftsprüfung

Ob ein Ausweichstandort im Ernstfall trägt, lässt sich vorab mit fünf Fragen einschätzen. Sie ersetzen keine Übung und finden die Fälle, in denen eine Übung sich nicht lohnt, weil die Antwort schon auf dem Papier fehlt.

Welche Ausprägung ist es tatsächlich — und welche beschreibt unsere Zusage?→Reichen Rechenleistung, Speicher und Anbindung für den geplanten Umfang gleichzeitig?→Was von Netz, Filterregeln, Identität, Zertifikaten und Lizenzen fehlt dort?→Wie wird die Schreibhoheit übergeben, und wer entscheidet im Zweifelsfall?→Wie kommen Clients und Partner auf die neue Adresse — und wie kommen wir zurück?

Die fünfte Frage enthält den Rückweg, weil er sonst nie gestellt wird

Was die fünf Fragen nicht ersetzenSie prüfen den Entwurf, nicht die Wirklichkeit. Die einzige Antwort auf die Frage, ob der Ausweichstandort trägt, ist ein Betrieb dort — sei es als angekündigtes Zeitfenster mit echter Umschaltung, sei es als dauerhafter Teilbetrieb einzelner Dienste. Der zweite Weg wird selten erwogen und ist oft der bessere: Ein Dienst, der ohnehin am Ausweichstandort läuft, hält dessen Netz, Freigaben und Betriebsfähigkeit dauerhaft im geprüften Zustand — und kostet dafür weniger als eine jährliche Vollübung.

Abgrenzung

Hier geht es um die Umschaltung eines Betriebs auf einen zweiten Ort und die Rückkehr. Die Führung der Lage steht im vorigen Modul, die Wiederherstellung einzelner Workloads davor.

NachbartracksSynchrone und asynchrone Replikation im Detail behandelt storage-file-services, Cluster und Quorum windows-server-administration und virtualization-private-cloud, Netzarchitektur über Standorte hinweg network-services und cloud-infra. Hier interessiert nur, welche Eigenschaft eines zweiten Standorts eine zugesagte Zahl einhält oder verfehlt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität3 Primärquellen · zuletzt geprüft: 2026-09-04