{"id":869811,"date":"2024-11-18T08:00:00","date_gmt":"2024-11-18T08:00:00","guid":{"rendered":"https:\/\/www.capgemini.com\/de-de\/?p=869811"},"modified":"2026-01-22T07:45:46","modified_gmt":"2026-01-22T07:45:46","slug":"wolken-brechen-disaster-recovery-public-cloud-2","status":"publish","type":"post","link":"https:\/\/www.capgemini.com\/de-de\/insights\/blog\/wolken-brechen-disaster-recovery-public-cloud\/","title":{"rendered":"Wenn die Wolken brechen: Disaster Recovery in der Public Cloud"},"content":{"rendered":"\n

Wenn die Wolken brechen: Disaster Recovery in der Public Cloud<\/h1><\/div><\/div><\/div><\/div>
\"\"<\/div>
Stanimir Dimitrov<\/h5>
18. Nov. 2024<\/h5><\/div><\/div>
<\/div><\/div><\/div><\/div><\/header>\n\n\n\n
\n

Wenn die Katastrophe eintritt<\/strong><\/h2>\n\n\n\n

Die meisten Unternehmen sind heute zumindest teilweise in die Public Cloud umgezogen. Zu den Vorteilen der Public Cloud z\u00e4hlen Skalierbarkeit, Flexibilit\u00e4t und erfolgskritische moderne digitale L\u00f6sungen. Ein weiterer Vorteil ist zudem die Verf\u00fcgbarkeit und Sicherheit von Daten, Applikationen und Gesch\u00e4ftskontinuit\u00e4t bei Katastrophen wie Infrastruktur-Sabotage (z.B. Internetausfall), Naturkatastrophen oder gar milit\u00e4rischen Konflikten. Ein Irrtum dabei ist jedoch, dass die Public Cloud sich automatisch um sogenannte \u201eDisaster Recovery\u201c k\u00fcmmert. Damit sind Strategien und Ma\u00dfnahmen gemeint, die im Katastrophenfall Datenverlust und Gesch\u00e4ftsunterbrechung vermeiden. Es stimmt zwar, dass die bekanntesten Public-Cloud-Anbieter (Azure, AWS und GCP) mehrere geografisch verteilte Rechenzentren betreiben, um Anforderungen an Datenschutz, Gesch\u00e4ftskontinuit\u00e4t und gesetzliche Vorschriften zu erm\u00f6glichen. Sie stellen zudem auch unterst\u00fctzende Services zur Verf\u00fcgung, die ein Disaster Recovery zwischen entfernten Regionen erm\u00f6glichen. Allerdings ist es Aufgabe der Unternehmen eine Disaster entsprechende Strategie zu konzipieren und diese Services zu konfigurieren und einzusetzen. Wie geht das? Dieser Artikel beleuchtet die wesentlichen Aspekte und Best Practices f\u00fcr eine effektive regionen\u00fcbergreifende Disaster-Recovery-Strategie in der Public Cloud.<\/p>\n\n\n\n

Was bedeutet Disaster Recovery?<\/strong><\/h2>\n\n\n\n

Disaster Recovery (DR) bezieht sich auf die Strategien und Ma\u00dfnahmen, die ein Unternehmen ergreift, um nach einem katastrophalen Ereignis den normalen Gesch\u00e4ftsbetrieb wiederherzustellen. Das passiert in einem abgelegenen sogenannten Disaster-Recovery-Standort, wo die Daten und Services repliziert werden, bis der prim\u00e4re IT-Standort wieder voll funktionsf\u00e4hig ist. Zudem umfasst DR die Sicherung und Wiederherstellung von Daten, Systemen und Infrastruktur, um Ausfallzeiten zu minimieren und den Gesch\u00e4ftsbetrieb schnell wieder aufzunehmen. Um das alles zu gew\u00e4hrleisten, ben\u00f6tigen Unternehmen eine Kombination von strategischem Plan und Technologiedesign.<\/p>\n\n\n\n

Was Unternehmen tun sollten<\/strong><\/h2>\n\n\n\n

Der erste Schritt ist, zu analysieren, welche Anwendungen gesch\u00e4ftskritisch sind. Darauf basierend werden die ben\u00f6tigten Business-Anforderungen und Infrastrukturtechnologien ermittelt. Diese sind dann ausschlaggebend f\u00fcr die IT-Architektur des DR-Standortes. Im Folgenden finden Sie die wichtigsten Aspekte, die dabei ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n\n\n\n

RPO (Recovery Point Objective) vs. RTO (Recovery Time Objective)<\/em>
Die Business-Anforderungen ergeben sich aus zwei Parametern, RTO und RPO. RPO bezieht sich auf die Menge an Datenverlusten innerhalb eines bestimmten Zeitraums, bevor ein maximal tolerierbarer Schaden entsteht, s. Abbildung 1. RTO definiert, wie schnell die IT-Systeme nach einem Ausfall laufen sollen. Diese zwei Parameter sind die Basis f\u00fcr die weiteren Schritte.<\/p>\n\n\n\n

\"\"
Abb. 1: Maximal tolerierbarer Datenverlust und maximal tolerierbare Ausfallzeit definieren weitere Schritte. Quelle: \u00a9Capgemini 2024<\/figcaption><\/figure>\n\n\n\n

Disaster-Recovery-Standort<\/em><\/p>\n\n\n\n

Die Lage des DR-Standortes wiederum ist von dem Business Case und gesetzlichen Vorschriften (z.B. Datenschutz-Grundverordnung) abh\u00e4ngig. Bei der Auswahl ist zu beachten, dass die Public-Cloud-Services SLAs (Service Level Agreements) nicht in allen Regionen identisch sind, wo ein Public-Cloud-Anbieter Rechenzentren hat. Vor allem die neuesten Cloud Services sind nicht \u00fcberall in gleicher Qualit\u00e4t angeboten. Auch eine Multi-Cloud-Strategie des Unternehmens kann die Entscheidung beeinflussen. Die gew\u00e4hlte Region muss in diesem Fall Rechenzentren von allen Anbietern haben, die Teil der Multi-Cloud-Strategie des Unternehmens sind, s. Abbildung 2.<\/p>\n\n\n\n

\"\"
Abb. 2: Azure (blau), AWS (schwarz) und Google Cloud (gr\u00fcn) haben Rechenzentren in vielen Regionen. Quelle: https:\/\/cloudregionsmap.z6.web.core.windows.net\/<\/strong><\/a><\/figcaption><\/figure>\n\n\n\n

Zudem existieren f\u00fcr den Aufbau eines DR-Standortes drei grundlegende Ans\u00e4tze: kalt, warm und hei\u00df. Diese drei Begriffe beziehen sich auf die Einfachheit, mit der eine IT-Umgebung im Falle eines Disasters wiederhergestellt werden kann, s. Abbildung 3.<\/p>\n\n\n\n

\"\"
Abb. 3: F\u00fcr den Aufbau eines DR-Standortes existieren drei grundlegende Ans\u00e4tze: kalt, warm und hei\u00df. Quelle: \u00a9Capgemini 2024<\/figcaption><\/figure>\n\n\n\n

Disaster-Recovery-Plan<\/em><\/p>\n\n\n\n

Der Disaster-Recovery-Plan ist ein formelles Dokument, das die zielgerichtete Wiederherstellung (z.B. Wiederherstellungsprozesse, Kommunikationsprozesse, Testprotokolle, etc.) der aus Business-Sicht ben\u00f6tigten Services in einer weit entfernten Region unterst\u00fctzt.  Der Plan wird in der DR-Region gespeichert und in regelm\u00e4\u00dfigen Abst\u00e4nden, mindestens einmal im Jahr, getestet. Somit validiert und aktualisiert das verantwortliche Team den DR-Plan.<\/p>\n\n\n\n

Replikationsans\u00e4tze<\/em><\/p>\n\n\n\n

Es gibt verschiedene Ans\u00e4tze, um IT-Systeme am DR-Standort zu replizieren. Welche Technologien zum Einsatz kommen, h\u00e4ngt von der Art der Ressourcen (Virtuelle Maschine, Container, Platform-as-a-Service (PaaS) Datenbank, etc.) ab. Cloud-native Replikationstechniken sind gegen\u00fcber traditionellen Methoden zu bevorzugen, weil sie mehrere Vorteile bieten \u2013 z. B. vereinfachtes Management und Kosteneffizienz.<\/p>\n\n\n\n

Manche Public-Cloud-Anbieter wie Azure bieten das Konzept von gepaarten Regionen. Zwei Regionen sind auf Grundlage der N\u00e4he und anderer relevanter Faktoren als Paar gekoppelt. Spezifische cloud-native Replikationstechniken sind dann nur zwischen gepaarten Regionen m\u00f6glich.<\/p>\n\n\n\n

Replikationen ben\u00f6tigen ein kontinuierliches Monitoring, um Probleme zu erkennen. Viele Monitoring-Services der Public-Cloud-Anbieter haben daf\u00fcr eingebaute KI-Algorithmen zur Anomalieerkennung (z.B. Identifikation vom Standard abweichender Replikationsmuster).<\/p>\n\n\n\n

In bestimmten F\u00e4llen kann eine Anwendungs-Replikation entweder nicht n\u00f6tig sein oder zu hohe Kosten verursachen. Dann bietet sich ein normales Re-Deployment \u2013 d. h. das komplett neue Aufsetzen von Anwendungen \u2013 als Alternative an.<\/p>\n\n\n\n

Kapazit\u00e4tsreservierung<\/em><\/p>\n\n\n\n

Alle Public-Cloud-Anbieter werben mit flexibler Skalierung und nahezu unbegrenzter Kapazit\u00e4t. Wenn es um gro\u00dfe Datenmengen oder Anzahl von Ressourcen geht (z.B. virtuelle Maschinen, PaaS Services, etc.) sieht es in der Realit\u00e4t oft anders aus. Nicht immer haben ihre Rechenzentren so viele freie Ressourcen. Deswegen empfehlen die Public-Cloud-Anbieter, Kapazit\u00e4t zu reservieren. In diesem Fall fallen reservierungsbedingte Kosten an, unabh\u00e4ngig davon, ob die reservierte Kapazit\u00e4t benutzt wird oder nicht.<\/p>\n\n\n\n

Disaster-Recovery-Team<\/em><\/p>\n\n\n\n

Was sind die perfekte IT-Architektur, Technologienauswahl und Prozesse ohne die richtigen Expert*innen wert? Unternehmen m\u00fcssen ein dediziertes Team f\u00fcr den Disaster-Recovery-Fall trainieren und vorbereiten, um im Falle eines Disasters die n\u00f6tigen Schritte zu \u00fcberwachen und zu betreuen. Die Teammitglieder sollen idealerweise in der Region wohnen, in der sich der DR-Standort befindet, damit sie verf\u00fcgbar sind und im Falle eines Disasters vereinfachten Zugang zu den DR-Systemen haben.<\/p>\n\n\n\n

F\u00fcr alle F\u00e4lle gewappnet<\/strong><\/h2>\n\n\n\n

Die g\u00e4ngigen Public Clouds (Azure, AWS und GCP) bieten gegen\u00fcber herk\u00f6mmlichen privaten Rechenzentren viele Vorteile wie Skalierbarkeit und Flexibilit\u00e4t. Dennoch ist es immer noch die Aufgabe jedes Unternehmens eine effektive Disaster-Recovery-Strategie zu entwickeln und zu implementieren. Diese ist entscheidend, um finanzielle Bereitstellungskosten zu minimieren, dynamisch auf Ver\u00e4nderungen zu reagieren und im Disaster-Recovery-Fall Daten und Anwendungen schnell wiederherzustellen.<\/p>\n\n\n\n

M\u00f6chten Sie gerne eine auf Ihre Bed\u00fcrfnisse zugeschnittene Disaster-Recovery-Strategie entwickeln, die die Besonderheiten der Public Cloud in Betracht zieht? Dann kontaktieren Sie mich gerne direkt.<\/p>\n<\/div><\/div><\/div><\/div><\/div><\/section>\n\n\n\n

<\/p>\n\n\n\n

Blog-Updates per Mail?<\/h3>

Abonnieren Sie unseren Newsletter und erhalten Sie alle zwei Monate eine Auswahl der besten Blogartikel.<\/p><\/div>

Zur Anmeldung <\/a><\/div>