Disaster Recovery: Für die Katastrophe gewappnet

Hochverfügbarkeit reicht manchmal nicht: Kritische Anwendungen müssen selbst dann noch weiterlaufen, wenn ganze Rechenzentren unbrauchbar werden. Doch wie realisiert der Admin Desaster Recovery sinnvoll? Eine Übersicht.

Artikel von Martin Loschwitz veröffentlicht am 9. März 2020, 12:02 Uhr

Was tun, wenn der Schlimmstfall eintritt? (Bild: Pixabay.com/Montage: Golem.de/CC0 1.0)

Wer ein IT-System heute neu konstruiert, kümmert sich dabei stets auch um das Thema Hochverfügbarkeit: Wenn einzelne Komponenten ausfallen, soll das Setup im besten Falle davon völlig unbeeindruckt einfach weiterlaufen. Allerdings gibt es Setups, bei denen das Absichern gegen den Ausfall einzelner Komponenten nicht genügt: Diese Umgebungen müssen selbst dann noch funktionieren, wenn ein ganzer Standort - also etwa ein ganzes Rechenzentrum - unbrauchbar werden.

Im Fachjargon ist von Disaster Recovery die Rede. Die zentrale Frage dabei: Wie lange dauert es, bis ein Setup nach dem Ausfall eines ganzen Standortes wieder online ist und zur Verfügung steht? Admins können verschiedene technische Konzepte nutzen, um Disaster Recovery für ihre Umgebungen zu implementieren.

Heiß oder kalt

Klar ist: Wer Redundanz über mehrere Standorte hinweg braucht, braucht freilich auch mehrere Standorte. Im Falle von Disaster-Recovery-Szenarien ist damit ganz explizit nicht gemeint, zwei Racks im selben Rechenzentrum zu haben - denn beim Planen von Offsite-Redundanz ist die Annahme gemeinhin, dass ein ganzer Standort wegen äußerer Umstände (Umweltkatastrophe, Unfall, Anschlag ...) ausfällt.

Was darüber hinaus sonst noch notwendig ist, hängt stark von den Bedingungen ab, die das Disaster-Recovery-Konzept erfüllen soll. Von zentraler Bedeutung ist die Frage, wie lange es dauern darf, bis ein Setup nach dem Ausfall eines Standortes an einem anderen Standort online geht. Hot-Standby-Lösungen gehen sehr schnell online, brauchen aber große Mengen an Infrastruktur und sind entsprechend teuer. Cold-Standby-Ansätze haben eine deutlich längere Wiederanlaufzeit, sind im Handling aber einfacher und verursachen in der Regel weniger Kosten. Wo liegen im Detail die (technischen) Unterschiede?