# ZUV 13 Was ist bei der Planung der Notfallwiederherstellung zu beachten?
Backups und redundante Workload-Komponenten sind der Ausgangspunkt Ihrer Strategie für die Notfallwiederherstellung. [RTO und RPO sind Ihre Ziele](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) für die Wiederherstellung Ihrer Workload. Legen Sie diese Ziele entsprechend den geschäftlichen Anforderungen fest. Implementieren Sie eine Strategie, um diese Ziele zu erreichen. Berücksichtigen Sie dabei Standorte und Funktionen von Workload-Ressourcen und -Daten. Die Wahrscheinlichkeit von Disruptionen und die Kosten von Wiederherstellungen sind ebenfalls wichtige Faktoren bei der Ermittlung des Unternehmenswerts, den Notfallwiederherstellungen von Workloads bieten.
**Topics**
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Verwalten der Konfigurationsabweichungen am Standort oder in der Region der Notfallwiederherstellung:](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05: Automatisieren der Wiederherstellung](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:
Für die Workload gelten ein Recovery Time Objective (RTO, Wiederherstellungsdauer) und ein Recovery Point Objective (RPO, Wiederherstellungszeitpunkt).
*Die Wiederherstellungsdauer* ist die maximal akzeptable Verzögerung zwischen der Unterbrechung und der Wiederherstellung des Service. Damit wird festgelegt, was als akzeptables Zeitfenster gilt, wenn der Service nicht verfügbar ist.
*Der Wiederherstellungszeitpunkt* ist die maximal zulässige Zeitspanne seit dem letzten Wiederherstellungspunkt. Damit wird festgelegt, was als akzeptabler Datenverlust zwischen dem letzten Wiederherstellungspunkt und der Service-Unterbrechung gilt.
RTO- und RPO-Werte sind wichtige Überlegungen bei der Auswahl einer geeigneten Notfallwiederherstellungsstrategie (Disaster Recovery, DR) für Ihre Workload. Diese Ziele werden vom Unternehmen festgelegt und dann von den technischen Teams zur Auswahl und Umsetzung einer DR-Strategie verwendet.
**Gewünschtes Ergebnis:**
Jeder Workload sind ein RTO und ein RPO zugewiesen, die auf der Grundlage der geschäftlichen Auswirkungen definiert werden. Die Workload wird einer vordefinierten Stufe zugewiesen, die die Serviceverfügbarkeit und den akzeptablen Datenverlust mit einem entsprechenden RTO und RPO definiert. Wenn eine solche Einstufung nicht möglich ist, kann die Zuweisung individuell pro Workload erfolgen, mit der Absicht, zu einem späteren Zeitpunkt Stufen zu erstellen. RTO und RPO werden als eine der Hauptüberlegungen für die Auswahl einer Notfallwiederherstellungsstrategie für die Workload verwendet. Weitere Überlegungen bei der Auswahl einer DR-Strategie sind Kostenbeschränkungen, Abhängigkeiten von der Workload und betriebliche Anforderungen.
Bei der RTO sind die Auswirkungen anhand der Dauer eines Ausfalls zu verstehen. Ist sie linear oder gibt es nichtlineare Auswirkungen? (Beispiel: Nach vier Stunden wird eine Fertigungsstraße bis zum Beginn der nächsten Schicht stillgelegt.)
Eine Matrix der Notfallwiederherstellung wie die folgende kann Ihnen helfen zu verstehen, wie die Kritikalität der Workload mit den Wiederherstellungszielen zusammenhängt. (Beachten Sie, dass die tatsächlichen Werte für die X- und Y-Achsen an die Bedürfnisse Ihres Unternehmens angepasst werden sollten.)
![\[Diagramm, das die Matrix der Notfallwiederherstellung zeigt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Gängige Antimuster:**
+ Keine definierten Wiederherstellungsziele.
+ Auswählen beliebiger Wiederherstellungsziele.
+ Auswählen von Wiederherstellungszielen, die zu lasch sind und die Geschäftsziele nicht erfüllen.
+ Kein Verständnis des Auswirkung von Ausfallzeiten und Datenverlust.
+ Auswahl unrealistischer Wiederherstellungsziele, wie z. B. Null-Zeit bis zur Wiederherstellung und Null-Datenverlust, die für Ihre Workload-Konfiguration möglicherweise nicht erreicht werden können.
+ Auswählen von Wiederherstellungszielen, die strikter sind als die tatsächlichen Geschäftsziele. Dies erzwingt Implementierungen für die Notfallwiederherstellung, die kostspieliger und komplizierter sind als die Anforderungen der Workload.
+ Auswahl von Wiederherstellungszielen, die mit denen einer abhängigen Workloads unvereinbar sind.
+ Ihre Wiederherstellungsziele berücksichtigen nicht die Einhaltung gesetzlicher Vorschriften.
+ RTO und RPO sind für eine Workload definiert, aber nie getestet.
**Vorteile der Einführung dieser bewährten Methode:** Die Wiederherstellungsziele für Dauer und Datenverlust sind als Orientierungshilfe für die Implementierung der Notfallwiederherstellung erforderlich.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Bei der gegebenen Workload müssen Sie die Auswirkungen von Ausfallzeiten und Datenverlusten auf Ihr Unternehmen verstehen. Die Auswirkungen werden in der Regel mit zunehmender Ausfallzeit oder Datenverlust größer, aber die Form dieses Anstiegs kann je nach Art der Workload unterschiedlich sein. So können Sie z. B. Ausfallzeiten bis zu einer Stunde ohne größere Beeinträchtigung tolerieren, danach steigen die Auswirkungen jedoch schnell an. Die Auswirkungen auf das Unternehmen zeigen sich in vielen Formen, darunter monetäre Kosten (z. B. entgangene Einnahmen), Kundenvertrauen (und Auswirkungen auf den Ruf), betriebliche Probleme (z. B. fehlende Gehaltsabrechnungen oder verringerte Produktivität) und gesetzliche Risiken. Führen Sie die folgenden Schritte aus, um diese Auswirkungen zu verstehen und RTO und RPO für Ihre Workload festzulegen.
**Implementierungsschritte**
1. Bestimmen Sie die Interessengruppen Ihres Unternehmens für diese Workload und arbeiten Sie mit ihnen zusammen, um diese Schritte umzusetzen. Die Wiederherstellungsziele für eine Workload sind eine geschäftliche Entscheidung. Die technischen Teams arbeiten dann mit den Business-Stakeholdern zusammen, um anhand dieser Ziele eine DR-Strategie auszuwählen.
**Anmerkung**
Für die Schritte 2 und 3 können Sie Folgendes verwenden: [Implementierungsarbeitsblatt](#implementation-worksheet).
1. Sammeln Sie die notwendigen Informationen, um eine Entscheidung zu treffen, indem Sie die folgenden Fragen beantworten.
1. Gibt es in Ihrem Unternehmen Kategorien oder Stufen der Kritikalität für die Auswirkungen von Workloads?
1. Falls zutreffend, ordnen Sie diese Workload einer Kategorie zu.
1. Falls nicht zutreffend, richten Sie diese Kategorien ein. Legen Sie fünf oder weniger Kategorien fest und verfeinern Sie die Spanne der angestrebten Wiederherstellungszeit für jede Kategorie. Zu den Beispielkategorien gehören: kritisch, hoch, mittel, niedrig. Um zu verstehen, wie sich Workloads den Kategorien zuordnen lassen, sollten Sie prüfen, ob die Workload unternehmenskritisch, geschäftswichtig oder nicht geschäftsrelevant ist.
1. Legen Sie RTO und RPO für die Workload je nach Kategorie fest. Wählen Sie immer eine Kategorie, die strikter ist (niedrigere RTO- und RPO-Werte) als die bei der Eingabe dieses Schritts berechneten Rohwerte. Wenn dies zu einer unangemessen großen Veränderung des Wertes führt, sollten Sie eine neue Kategorie anlegen.
1. Weisen Sie auf der Grundlage dieser Antworten der Workload RTO- und RPO-Werte zu. Dies kann direkt geschehen oder durch Zuweisung der Workload zu einer vordefinierten Serviceebene.
1. Dokumentieren Sie den Notfallwiederherstellungsplan (Disaster Recovery Plan, DRP) für diese Workload, der Teil der Unternehmensstrategie ist. [Betriebskontinuitätsplan (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)an einem Ort, der für das Workload-Team und die Stakeholder zugänglich ist
1. Halten Sie die RTO- und RPO-Werte sowie die zur Ermittlung dieser Werte verwendeten Informationen fest. Geben Sie eine Strategie zur Bewertung der Auswirkungen der Workload auf das Unternehmen an.
1. Erfassen Sie neben RTO und RPO auch andere Metriken, die Sie für Notfallwiederherstellungsziele verfolgen oder zu verfolgen planen
1. Sie fügen diesem Plan Details zu Ihrer DR-Strategie und Ihrem Runbook hinzu, wenn Sie diese erstellen.
1. Indem Sie die Kritikalität der Workload in einer Matrix wie der in Abbildung 15 nachschlagen, können Sie damit beginnen, vordefinierte Serviceebenen für Ihr Unternehmen festzulegen.
1. Nachdem Sie eine DR-Strategie (oder einen Machbarkeitsnachweis für eine DR-Strategie) gemäß implementiert haben,[REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)testen Sie diese Strategie, um die tatsächliche RTC (Recovery Time Capability) und RPC (Recovery Point Capability) der Workload zu bestimmen. Wenn diese nicht den angestrebten Wiederherstellungszielen entsprechen, arbeiten Sie entweder mit Ihren Stakeholdern zusammen, um diese Ziele anzupassen, oder nehmen Sie Änderungen an der DR-Strategie vor, um die Zielvorgaben zu erreichen.
**Primäre Fragen**
1. Wie lange kann die Workload maximal ausfallen, bevor es zu schwerwiegenden Auswirkungen auf das Unternehmen kommt?
1. Bestimmen Sie die monetären Kosten (direkte finanzielle Auswirkungen) für das Unternehmen pro Minute, wenn die Workload unterbrochen wird.
1. Bedenken Sie, dass die Auswirkungen nicht immer linear sind. Die Auswirkungen können zunächst begrenzt sein und dann ab einem kritischen Zeitpunkt rasch zunehmen.
1. Wie groß ist die maximale Datenmenge, die verloren gehen kann, bevor es zu schwerwiegenden Auswirkungen auf das Unternehmen kommt?
1. Berücksichtigen Sie diesen Wert für Ihren wichtigsten Datenspeicher. Identifizieren Sie die jeweilige Kritikalität für andere Datenspeicher.
1. Können Workload-Daten bei Verlust wiederhergestellt werden? Wenn dies aus betrieblicher Sicht einfacher ist als Backup und Wiederherstellung, dann wählen Sie das RPO auf der Grundlage der Kritikalität der Ursprungsdaten, die zur Wiederherstellung der Workload-Daten verwendet werden.
1. Wie lauten die Wiederherstellungsziele und Verfügbarkeitserwartungen von Workloads, von denen dieser abhängt (Downstream), oder von Workloads, die von diesem abhängen (Upstream)?
1. Wählen Sie Wiederherstellungsziele, die es dieser Workload ermöglichen, die Anforderungen der vorgelagerten Abhängigkeiten zu erfüllen
1. Wählen Sie Wiederherstellungsziele, die angesichts der Wiederherstellungsmöglichkeiten der nachgelagerten Abhängigkeiten erreichbar sind. Unkritische nachgelagerte Abhängigkeiten (die Sie „umgehen“ können) können ausgeschlossen werden. Oder arbeiten Sie mit kritischen, nachgelagerten Abhängigkeiten zusammen, um deren Wiederherstellungsmöglichkeiten zu verbessern.
**Weitere Fragen**
Überlegen Sie sich, wie diese Fragen auf diese Workload zutreffen könnten:
1. Haben Sie unterschiedliche RTO und RPO je nach Art des Ausfalls (Region vs. Region)? AZ, etc.)?
1. Gibt es einen bestimmten Zeitpunkt (Saisonabhängigkeit, Verkaufsveranstaltungen, Produkteinführungen), zu dem sich Ihr RTO/RPO ändern kann? Wenn ja, was ist die unterschiedliche Messung und die zeitliche Begrenzung?
1. Wie viele Kunden sind von einer Unterbrechung der Workload betroffen?
1. Welche Auswirkungen hat es auf den Ruf, wenn die Workload unterbrochen wird?
1. Welche anderen betrieblichen Auswirkungen können auftreten, wenn die Workload unterbrochen wird? Zum Beispiel Auswirkungen auf die Produktivität der Mitarbeiter, wenn die E-Mail-Systeme nicht verfügbar sind oder wenn die Lohnbuchhaltungssysteme keine Transaktionen übermitteln können.
1. Wie stimmen RTO und RPO der Workload mit der DR-Strategie der Geschäftsbereiche und des Unternehmens überein?
1. Gibt es interne vertragliche Verpflichtungen für die Erbringung einer Dienstleistung? Gibt es Strafen für die Nichteinhaltung dieser Vorgaben?
1. Welche rechtlichen oder Compliance-Bedingungen gelten für die Daten?
## Implementierungsarbeitsblatt
Sie können dieses Arbeitsblatt für die Implementierungsschritte 2 und 3 verwenden. Sie können dieses Arbeitsblatt an Ihre speziellen Bedürfnisse anpassen, indem Sie beispielsweise zusätzliche Fragen hinzufügen.
![\[Arbeitsblatt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Grad des Aufwands für den Implementierungsplan: **Niedrig
## Ressourcen
**Ähnliche bewährte Methoden:**
+ [REL09-BP04 Verifizieren der Sicherungsintegrität und -verfahren durch regelmäßiges Wiederherstellen der Daten](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:](rel_planning_for_recovery_dr_tested.md)
**Zugehörige Dokumente:**
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Verwalten von Ausfallsicherheit mit AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Relevante Videos**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
+ [Notfallwiederherstellung von Workloads auf AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02: Verwenden von definierten Wiederherstellungsstrategien, um die Wiederherstellungsziele zu erreichen
Definieren Sie eine Notfallwiederherstellungsstrategie (Disaster Recovery, DR), die den Wiederherstellungszielen Ihrer Workloads entspricht. Wählen Sie eine Strategie aus, z. B. Backup und Wiederherstellung, Standby (aktiv/passiv) oder Aktiv/Aktiv.
Eine DR-Strategie beruht auf der Fähigkeit, Ihre Workload an einem Wiederherstellungsstandort bereitzustellen, wenn Ihr primärer Standort nicht mehr in der Lage ist, den Workload auszuführen. Die häufigsten Wiederherstellungsziele sind RTO und RPO, wie besprochen in [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md).
Eine DR-Strategie, die mehrere Availability Zones (AZs) innerhalb eines einzigen AWS-Region umfasst, kann Katastrophenereignisse wie Brände, Überschwemmungen und größere Stromausfälle abfedern. Wenn es erforderlich ist, einen Schutz gegen ein unwahrscheinliches Ereignis zu implementieren, das verhindert, dass Ihre Workload in einer bestimmten AWS-Region ausgeführt werden kann, können Sie eine DR-Strategie verwenden, die mehrere Regionen nutzt.
Wenn Sie eine DR-Strategie für mehrere Regionen entwickeln, sollten Sie eine der folgenden Strategien wählen. Sie werden nach zunehmenden Kosten und zunehmender Komplexität und abnehmender RTO und RPO aufgelistet. *Wiederherstellungsregion* bezieht sich auf einen AWS-Region anders als der primäre, der für Ihre Workload verwendet wird.
![\[Diagramm der DR-Strategien\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Sicherung und Wiederherstellung** (RPO in Stunden, RTO in 24 Stunden oder weniger): Sichern Sie Ihre Daten und Anwendungen in der Wiederherstellungsregion. Die Verwendung automatisierter oder kontinuierlicher Backups ermöglicht eine zeitpunktgenaue Wiederherstellung, wodurch das RPO in einigen Fällen auf bis zu 5 Minuten gesenkt werden kann. Im Falle eines Notfalls stellen Sie Ihre Infrastruktur bereit (wobei Sie Infrastruktur als Code verwenden, um die RTO zu verkürzen), stellen Ihren Code bereit und stellen die gesicherten Daten wieder her, um eine Wiederherstellung nach einem Notfall in der Wiederherstellungsregion zu erfahren.
+ **Pilot Light** (RPO in Minuten, RTO in zehn Minuten): Bereitstellung einer Kopie Ihrer Kern-Workload-Infrastruktur in der Wiederherstellungsregion. Replizieren Sie Ihre Daten in die Wiederherstellungsregion und erstellen Sie dort Sicherungskopien der Daten. Ressourcen, die zur Unterstützung der Datenreplikation und -sicherung erforderlich sind, wie Datenbanken und Objektspeicher, sind immer eingeschaltet. Andere Elemente wie Anwendungsserver oder Serverless Compute werden nicht bereitgestellt, sondern können bei Bedarf mit der erforderlichen Konfiguration und dem Anwendungscode erstellt werden.
+ **Warm Standby** (RPO in Sekunden, RTO in Minuten): Behalten Sie eine verkleinerte, aber voll funktionsfähige Version Ihres Workloads in der Wiederherstellungsregion bei. Geschäftskritische Systeme sind vollständig dupliziert und ständig aktiv, aber mit herunterskalierter Infrastruktur. Die Daten werden repliziert und sind in der Wiederherstellungsregion live. Wenn eine Wiederherstellung erforderlich ist, wird das System zur Bewältigung der Produktionslast schnell hochskaliert. Je höher die Skalierung des Warm Standby, desto geringer ist die Abhängigkeit von RTO und Kontrollebene. Wenn voll skaliert, wird dies als **Hot Standby bezeichnet**.
+ **Multi-Region (Multi-Site) aktiv-aktiv** (RPO nahe Null, RTO potenziell Null): Ihre Workload wird auf mehreren AWS-Regionen bereitgestellt und bedient aktiv Datenverkehr von diesen. Bei dieser Strategie müssen Sie die Daten zwischen den Regionen synchronisieren. Mögliche Konflikte, die durch Schreibvorgänge auf denselben Datensatz in zwei verschiedenen regionalen Repliken verursacht werden, müssen vermieden oder behandelt werden, was sehr komplex sein kann. Die Datenreplikation ist nützlich für die Datensynchronisation und schützt Sie vor einigen Arten von Notfällen, aber sie schützt Sie nicht vor Datenbeschädigung oder -zerstörung, es sei denn, Ihre Lösung umfasst auch Optionen für eine zeitpunktgenaue Wiederherstellung.
**Anmerkung**
Der Unterschied zwischen Pilot Light und Warm Standby ist oft nicht sofort klar. Beide beinhalten eine Umgebung in Ihrer Wiederherstellungsregion mit Kopien der Assets Ihrer Primärregion. Der Unterschied besteht darin, dass Pilot Light keine Anfragen bearbeiten kann, ohne dass zuvor zusätzliche Maßnahmen ergriffen werden, während Warm Standby den Datenverkehr (mit reduzierter Kapazität) sofort bearbeiten kann. Bei Pilot Light müssen Sie die Server einschalten, möglicherweise zusätzliche (nicht zum Kerngeschäft gehörende) Infrastruktur bereitstellen und die Leistung hochskalieren, während Sie bei Warm Standby nur die Leistung hochskalieren müssen (alles ist bereits bereitgestellt und läuft). Wählen Sie je nach RTO- und RPO-Anforderungen zwischen diesen Varianten.
**Gewünschtes Ergebnis:**
Für jede Workload gibt es eine definierte und implementierte DR-Strategie, die es dieser Workload ermöglicht, die DR-Ziele zu erreichen. DR-Strategien zwischen Workloads nutzen wiederverwendbare Muster (wie die zuvor beschriebenen Strategien),
**Gängige Antimuster:**
+ Implementierung von inkonsistenten Wiederherstellungsprozeduren für Workloads mit ähnlichen DR-Zielen.
+ Die DR-Strategie muss im Notfall Ad-hoc umgesetzt werden.
+ Kein Plan verfügbar für DR.
+ Abhängigkeit von Vorgängen auf der Steuerungsebene während der Wiederherstellung.
**Vorteile der Einführung dieser bewährten Methode:**
+ Durch die Nutzung definierter Wiederherstellungsstrategien können Sie verbreitet verwendete Tools und Testverfahren verwenden.
+ Die Verwendung definierter Wiederherstellungsstrategien ermöglicht einen effizienteren Wissensaustausch zwischen den Teams und eine einfachere Implementierung von DR für die eigenen Workloads.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
+ Ohne eine geplante, implementierte und getestete DR-Strategie ist es unwahrscheinlich, dass Sie Ihre Wiederherstellungsziele im Falle eines Notfalls erreichen.
## Implementierungsleitfaden
Zu jedem dieser Schritte finden Sie unten weitere Informationen.
1. Bestimmen Sie eine DR-Strategie, die die Wiederherstellungsanforderungen für diese Workload erfüllt.
1. Überprüfen Sie die Muster, wie die ausgewählte DR-Strategie umgesetzt werden kann.
1. Beurteilen Sie die Ressourcen Ihrer Workloads und deren Konfiguration in der Wiederherstellungsregion vor dem Failover (während des normalen Betriebs).
1. Legen Sie fest, wie Sie Ihre Wiederherstellungsregion bei Bedarf (während eines Notfallereignisses) für einen Failover bereit machen wollen, und setzen Sie diese um.
1. Legen Sie fest und implementieren Sie, wie Sie den Datenverkehr bei Bedarf (im Notfall) zum Failover umleiten werden.
1. Entwerfen Sie einen Plan, wie Ihre Workload zurückgehen wird.
**Implementierungsschritte**
1. **Bestimmen Sie eine DR-Strategie, die die Wiederherstellungsanforderungen für diese Workload erfüllt.**
Die Wahl einer DR-Strategie ist eine Abwägung zwischen der Reduzierung von Ausfallzeiten und Datenverlusten (RTO und RPO) und den Kosten und der Komplexität der Implementierung der Strategie. Sie sollten vermeiden, eine Strategie zu verfolgen, die strikter ist als nötig, da dies unnötige Kosten verursacht.
Im folgenden Diagramm hat das Unternehmen beispielsweise seine maximal zulässige RTO sowie die Grenze der Ausgaben für seine Strategie zur Wiederherstellung von Diensten festgelegt. In Anbetracht der Ziele des Unternehmens erfüllen die DR-Strategien Pilot Light oder Warm Standby sowohl die RTO- als auch die Kostenkriterien.
![\[Grafik zur Auswahl einer DR-Strategie auf der Grundlage von RTO und Kosten\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Weitere Information finden Sie unter [Betriebskontinuitätsplan (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Überprüfen Sie die Muster, wie die ausgewählte DR-Strategie umgesetzt werden kann.**
In diesem Schritt geht es darum, zu verstehen, wie Sie die gewählte Strategie umsetzen wollen. Die Strategien werden durch die Verwendung von AWS-Regionen als primäre und Wiederherstellungsstandort erläutert. Sie können jedoch auch Verfügbarkeitszonen innerhalb einer einzigen Region als DR-Strategie verwenden, die Elemente mehrerer dieser Strategien nutzt.
In den darauf folgenden Schritten werden Sie die Strategie auf Ihre spezifische Workload anwenden.
**Sicherung und Wiederherstellung**
*Sicherung und Wiederherstellung* ist die am einfachsten zu implementierende Strategie, erfordert aber mehr Zeit und Aufwand für die Wiederherstellung der Workload, was zu höheren RTO- und RPO-Werten führt. Es ist eine gute Vorgehensweise, immer Sicherungskopien Ihrer Daten zu erstellen und diese auf einen anderen Standort (z. B. einen anderen AWS-Region) zu kopieren.
![\[Diagramm einer Sicherungs- und Wiederherstellungsarchitektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Notfallwiederherstellungsarchitektur (DR) auf AWS, Teil II: Sicherung und Wiederherstellung mit Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot Light**
Mit dem *Pilot Light-Verfahren* replizieren Sie Ihre Daten von Ihrer primären Region auf Ihre Wiederherstellungsregion. Die Kernressourcen, die für die Workload-Infrastruktur verwendet werden, werden in der Wiederherstellungsregion bereitgestellt, jedoch werden noch zusätzliche Ressourcen und Abhängigkeiten benötigt, um diesen Stack funktionsfähig zu machen. In Abbildung 20 werden zum Beispiel keine Compute Instances bereitgestellt.
![\[Diagramm der Architektur eines Pilot Light\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Notfallwiederherstellungsarchitektur (DR) auf AWS, Teil III: Pilot Light und Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warm Standby**
Das *Warm Standby* Verfahren stellt sicher, dass eine verkleinerte, aber voll funktionsfähige Kopie Ihrer Produktionsumgebung in einer anderen Region vorhanden ist. Dieser Ansatz erweitert das Konzept des Pilot Light und verkürzt die Zeit bis zur Wiederherstellung, da die Workload in einer anderen Region ständig präsent ist. Wenn die Wiederherstellungsregion mit voller Kapazität eingesetzt wird, spricht man von einem *Hot Standby*.
![\[Diagramm mit Abbildung 21: Warm Standby-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
Der Einsatz von Warm Standby oder Pilot Light erfordert ein Hochskalieren der Ressourcen in der Wiederherstellungsregion. Um sicherzustellen, dass die Kapazität bei Bedarf zur Verfügung steht, sollten Sie die Verwendung für [Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) für EC2-Instances erwägen. Wenn Sie AWS Lambda verwenden, [können Sie mit Hilfe der Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) Ausführungsumgebungen sicherstellen, die darauf vorbereitet sind, sofort auf die Aufrufe Ihrer Funktion zu reagieren.
Weitere Details zu dieser Strategie finden Sie unter [Notfallwiederherstellungsarchitektur (DR) auf AWS, Teil III: Pilot Light und Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multi-Site Aktiv/Aktiv**
Sie können Ihre Workload gleichzeitig in mehreren Regionen als Teil einer *Multi-Site Aktiv/Aktiv-Strategie* ausführen. Multi-Site Aktiv/Aktiv bedient den Datenverkehr aus allen Regionen, in denen es eingesetzt wird. Kunden können diese Strategie aus anderen Gründen als DR wählen. Sie kann zur Erhöhung der Verfügbarkeit oder bei der Bereitstellung einer Workload für eine globale Zielgruppe verwendet werden (um den Endpunkt näher an die Benutzer zu bringen und/oder um Stacks bereitzustellen, die für die Zielgruppe in dieser Region lokalisiert sind). Bei einer DR-Strategie wird, wenn die Workload in einer der AWS-Regionen, in denen sie bereitgestellt wird, nicht unterstützt werden kann, diese Region evakuiert und die verbleibende(n) Region(en) wird (werden) zur Aufrechterhaltung der Verfügbarkeit verwendet. Multi-Site Aktiv/Aktiv ist die betrieblich komplexeste der DR-Strategien und sollte nur dann gewählt werden, wenn die Geschäftsanforderungen dies erfordern.
![\[Diagramm mit einer Multi-Site Aktiv/Aktiv Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Weitere Details zu dieser Strategie finden Sie unter [Architektur für die Notfallwiederherstellung (Disaster Recovery, DR) auf AWS, Teil IV: Multi-Site Aktiv-Aktiv](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Zusätzliche Praktiken zum Schutz von Daten**
Bei allen Strategien müssen Sie sich auch gegen einen Datennotfall wappnen. Kontinuierliche Datenreplikation schützt Sie vor einigen Arten von Notfällen, aber sie schützt Sie möglicherweise nicht vor Datenbeschädigung oder -zerstörung, es sei denn, Ihre Strategie umfasst auch die Versionsverwaltung gespeicherter Daten oder Optionen für eine zeitpunktgenaue Wiederherstellung. Sie müssen auch die replizierten Daten in der Wiederherstellungssite sichern, um zusätzlich zu den Replikaten zeitpunktgenaue Sicherungen zu erstellen.
**Verwendung von mehreren Availability Zones (AZs) innerhalb einer einzigen AWS-Region**
Wenn Sie mehrere AZs in einer einzigen Region verwenden, nutzt Ihre DR-Implementierung mehrere Elemente der oben genannten Strategien. Zunächst müssen Sie eine Hochverfügbarkeitsarchitektur (High Availability / HA) mit mehreren AZs erstellen, wie in Abbildung 23 dargestellt. Diese Architektur nutzt einen Multi-Site Aktiv/Akitv-Ansatz als [Amazon EC2-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) und [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) stellen Ressourcen in mehreren AZs bereit, die Anfragen bearbeiten. Die Architektur demonstriert auch Hot Standby, wo, wenn die primäre [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) Instance ausfällt (oder die AZ selbst ausfällt), die Standby-Instance dann zur primären Instance hochgestuft wird.
![\[Diagramm mit Abbildung 23: Multi-AZ-Architektur\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Zusätzlich zu dieser HA-Architektur müssen Sie Backups aller Daten hinzufügen, die für die Ausführung Ihrer Workloads erforderlich sind. Dies ist besonders wichtig für Daten, die sich auf eine einzige Zone beschränken, wie z. B. [Amazon EBS-Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) oder [Amazon Redshift-Cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Wenn ein AZ ausfällt, müssen Sie diese Daten auf einem anderen AZ wiederherstellen. Wenn möglich, sollten Sie auch Datensicherungen auf einen anderen AWS-Region kopieren, um eine zusätzliche Sicherheit zu gewährleisten.
Ein weniger gebräuchlicher alternativer Ansatz für eine einzelne Region, Multi-AZ DR, wird in diesem Blogbeitrag vorgestellt, [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 1: Stack für eine einzelne Region](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Hier besteht die Strategie darin, so viel Isolation wie möglich zwischen den AZs aufrechtzuerhalten, ähnlich wie bei den Regionen. Bei dieser alternativen Strategie können Sie sich für einen aktiv/aktiven oder aktiv/passiven Ansatz entscheiden.
Hinweis: Für einige Workloads gibt es gesetzliche Anforderungen an die Datenaufbewahrung. Wenn dies auf Ihre Workload in einer Region zutrifft, in der es derzeit nur eine AWS-Region gibt, dann ist die Multi-Region für Ihre geschäftlichen Anforderungen nicht geeignet. Multi-AZ-Strategien bieten einen guten Schutz gegen die meisten Notfälle.
1. **Beurteilen Sie die Ressourcen Ihrer Workloads und deren Konfiguration in der Wiederherstellungsregion vor dem Failover (während des normalen Betriebs).**
Für Infrastruktur und AWS-Ressourcen verwenden Sie Infrastruktur als Code oder Tools [AWS CloudFormation](https://aws.amazon.com/cloudformation) von Drittanbietern wie Hashicorp Terraform. Für die Bereitstellung auf mehrere Konten und Regionen mit einem einzigen Vorgang können Sie [AWS CloudFormation-StackSets verwenden](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Bei Multi-Site-Aktiv/Aktiv- und Hot Standby-Strategien verfügt die in Ihrer Wiederherstellungsregion bereitgestellte Infrastruktur über dieselben Ressourcen wie Ihre Primärregion. Bei den Strategien Pilot Light und Warm Standby sind zusätzliche Maßnahmen erforderlich, um die Infrastruktur produktionsreif zu machen. Mit der Hilfe von CloudFormation [Parametern](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) und [bedingter Logik](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)können Sie mit einer einzigen Vorlage steuern, ob ein bereitgestellter Stack aktiv oder in Bereitschaft ist. Ein Beispiel für eine solche CloudFormation-Vorlage ist in diesem [Blogbeitrag enthalten.](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Alle DR-Strategien setzen voraus, dass die Datenquellen innerhalb der AWS-Region gesichert werden und diese Sicherungen dann in die Wiederherstellungsregion kopiert werden. [AWS Backup](https://aws.amazon.com/backup/) bietet eine zentrale Ansicht, in der Sie Backups für diese Ressourcen konfigurieren, planen und überwachen können. Bei Pilot Light, Warm Standby und Multi-Site Aktiv/Aktiv sollten Sie auch Daten aus der primären Region auf Datenressourcen in der Wiederherstellungsregion replizieren, z. B. [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) DB-Instances oder [Amazon DynamoDB](https://aws.amazon.com/dynamodb) -Tabellen. Diese Datenressourcen sind daher aktiv und bereit, Anfragen in der Wiederherstellungsregion zu bedienen.
Weitere Informationen darüber, wie AWS-Dienste regionenübergreifend funktionieren, finden Sie in dieser Blogserie über das [Erstellen einer regionenübergreifenden Anwendung mit AWS-Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Legen Sie fest, wie Sie Ihre Wiederherstellungsregion bei Bedarf (während eines Notfallereignisses) für einen Failover bereit machen wollen, und setzen Sie diese um.**
Bei Multi-Site Aktiv/Aktiv bedeutet Failover, dass eine Region evakuiert wird und die verbleibenden aktiven Regionen genutzt werden. Im Allgemeinen sind diese Regionen bereit, Datenverkehr aufzunehmen. Bei den Strategien „Pilot Light“ und „Warm Standby“ müssen Ihre Wiederherstellungsmaßnahmen die fehlenden Ressourcen bereitstellen, z. B. die EC2-Instances in Abbildung 20, sowie alle anderen fehlenden Ressourcen.
Bei allen oben genannten Strategien müssen Sie möglicherweise schreibgeschützte Instances von Datenbanken zur primären Lese-/Schreibinstance machen.
Bei der Sicherung und Wiederherstellung werden durch die Wiederherstellung von Daten aus der Sicherung Ressourcen für diese Daten wie EBS-Volumes, RDS-DB-Instances und DynamoDB-Tabellen erstellt. Außerdem müssen Sie die Infrastruktur wiederherstellen und Code bereitstellen. Sie können AWS Backup Daten in der Wiederherstellungsregion wiederherstellen. Transparenz [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md) für weitere Informationen. Der Wiederaufbau der Infrastruktur umfasst die Erstellung von Ressourcen wie EC2-Instances zusätzlich zu den [Amazon Virtual Private Cloud (Amazon VPC),](https://aws.amazon.com/vpc)Subnetzen und benötigten Sicherheitsgruppen. Sie können einen Großteil des Wiederherstellungsprozesses automatisieren. Um zu erfahren wie das gemacht wird, [sehen Sie sich diesen Blogbeitrag an.](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Legen Sie fest und implementieren Sie, wie Sie den Datenverkehr bei Bedarf (im Notfall) zum Failover umleiten werden.**
Dieser Failover-Vorgang kann entweder automatisch oder manuell eingeleitet werden. Ein automatisch eingeleitetes Failover auf der Grundlage von Zustandsprüfungen oder Alarmen ist mit Vorsicht zu genießen, da ein unnötiges Failover (Fehlalarm) Kosten wie Nichtverfügbarkeit und Datenverlust verursacht. Daher wird häufig eine manuell initiiertes Failover verwendet. In diesem Fall sollten Sie die Schritte für das Failover dennoch automatisieren, so dass die manuelle Auslösung wie ein Knopfdruck wirkt.
Bei der Inanspruchnahme von AWS-Services gibt es mehrere Optionen für die Verwaltung des Datenverkehrs zu berücksichtigen. Eine Option ist die Verwendung von [Amazon Route 53](https://aws.amazon.com/route53). Mit Amazon Route 53 können Sie mehrere IP-Endpunkte in einem oder mehreren AWS-Regionen mit einem Route 53-Domainnamen verknüpfen. Um ein manuell initiiertes Failover zu implementieren, können Sie den [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/)verwenden, der eine hochverfügbare API für die Datenebene bietet, um den Datenverkehr in die Wiederherstellungsregion umzuleiten. Verwenden Sie bei der Implementierung von Failover Vorgänge auf der Datenebene und vermeiden Sie solche auf der Steuerungsebene, wie in beschriebe in [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md).
Mehr Information darüber sowie andere Optionen finden [Sie in diesem Abschnitt des Disaster Recovery Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Entwerfen Sie einen Plan, wie Ihre Workload zurückgehen wird.**
Failback bedeutet, dass Sie den Workload-Betrieb in der primären Region wieder aufnehmen, nachdem ein Notfallereignis abgeklungen ist. Die Bereitstellung von Infrastruktur und Code für die primäre Region erfolgt im Allgemeinen in denselben Schritten wie ursprünglich, wobei Infrastruktur als Code und Code-Bereitstellungspipelines verwendet werden. Die Herausforderung beim Failback ist die Wiederherstellung von Datenspeichern und die Sicherstellung ihrer Konsistenz mit der in Betrieb befindlichen Wiederherstellungsregion.
Im ausgefallenen Zustand sind die Datenbanken in der Wiederherstellungsregion aktiv und verfügen über die aktuellen Daten. Ziel ist es dann, eine erneute Synchronisierung von der Wiederherstellungsregion mit der primären Region vorzunehmen, um sicherzustellen, dass diese auf dem neuesten Stand ist.
Einige AWS-Services werden das automatisch tun. Bei der Verwendung [Amazon DynamoDB globaler Tabellen,](https://aws.amazon.com/dynamodb/global-tables/)setzt DynamoDB die Übertragung aller anstehenden Schreibvorgänge fort, auch wenn die Tabelle in der primären Region nicht mehr verfügbar ist, sobald sie wieder online ist. Bei der Verwendung von [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) und [verwaltetem geplanten Failover](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)wird die bestehende Replikationstopologie der Aurora globalen Datenbank wird beibehalten. Daher wird die ehemalige Lese-/Schreibinstance in der primären Region zu einem Replikat und erhält Aktualisierungen von der Wiederherstellungsregion.
In Fällen, in denen dies nicht automatisch geschieht, müssen Sie die Datenbank in der primären Region als Replikat der Datenbank in der Wiederherstellungsregion neu einrichten. In vielen Fällen bedeutet dies, dass die alte primäre Datenbank gelöscht und neue Replikate erstellt werden müssen. Eine Anleitung, wie Sie dies mit Amazon Aurora Global Database unter der Annahme eines ungeplanten Failover tun können, *finden Sie beispielsweise* in dieser Übung: [Fail-Back einer globalen Datenbank](https://awsauroralabsmy.com/global/failback/).
Wenn Sie nach einem Failover in Ihrer Wiederherstellungsregion weiterarbeiten können, sollten Sie diese zur neuen Primärregion machen. Sie würden trotzdem alle oben genannten Schritte durchführen, um die ehemalige Primärregion in eine Wiederherstellungsregion zu verwandeln. Einige Unternehmen führen eine planmäßige Rotation durch und tauschen ihre Primär- und Wiederherstellungsregionen in regelmäßigen Abständen aus (z. B. alle drei Monate).
Alle für Failover und Failback erforderlichen Schritte sollten in einem Playbook festgehalten werden, das allen Teammitgliedern zur Verfügung steht und regelmäßig überprüft wird.
**Grad des Aufwands für den Implementierungsplan:**Hoch
## Ressourcen
**Ähnliche bewährte Methoden:**
+ [REL09-BP01 Ermitteln und Sichern aller zu sichernden Daten oder Reproduzieren der Daten aus Quellen](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten:](rel_planning_for_recovery_objective_defined_recovery.md)
**Zugehörige Dokumente:**
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Optionen für die Notfallwiederherstellung in der Cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Entwickeln Sie eine Multi-Region-Serverless-Backend-Lösung, die aktiv/aktiv ist.](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-Region-Serverless-Backend – neu aufgelegt](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: Regionsübergreifendes Replizieren von Lesereplikaten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: Konfigurieren von DNS-Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: Regionsübergreifende Replikation](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Was ist AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Was ist Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Get Started – AWS (Erste Schritte)](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Relevante Videos:**
+ [Notfallwiederherstellung von Workloads auf AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
+ [Erste Schritte mit AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Ähnliche Beispiele:**
+ [AWS Well-Architected Labs – Disaster Recovery (Notfallwiederherstellung)](https://wellarchitectedlabs.com/reliability/disaster-recovery/) – Eine Reihe von Workshops zur Veranschaulichung der DR-Strategien
# REL13-BP03 Testen der Implementierung der Notfallwiederherstellung zur Validierung:
Testen Sie regelmäßig den Failover zu Ihrem Wiederherstellungsstandort, um den ordnungsgemäßen Betrieb und die Einhaltung von RTO und RPO sicherzustellen.
Vom Erstellen selten durchgeführter Wiederherstellungspfade wird abgeraten. So könnten Sie beispielsweise einen zweiten Datenspeicher unterhalten, der nur für Leseabfragen verwendet wird. Wenn Sie Daten in einen Datenspeicher schreiben und der primäre Datenspeicher einen Fehler ausgibt, können Sie einen Failover auf den zweiten Datenspeicher durchführen. Wenn Sie diesen Failover nicht regelmäßig testen, werden Sie möglicherweise feststellen, dass Ihre Annahmen zu den Möglichkeiten des sekundären Datenspeichers unzutreffend sind. Die Kapazität des zweiten Datenspeichers, die bei den letzten Tests möglicherweise noch ausreichend war, genügt möglicherweise nicht mehr den Anforderungen dieses Szenarios. Unsere Erfahrungen haben gezeigt, dass bei einer Wiederherstellung nach einem Fehler nur der Pfad funktioniert, den Sie regelmäßig testen. Daher ist es ratsam, mehrere Wiederherstellungspfade zu pflegen. Sie können Wiederherstellungsmuster erstellen und diese regelmäßig testen. Auch komplexe oder kritische Wiederherstellungspfade müssen regelmäßig mittels Fehlersimulationen in der Produktion durchgeführt werden, um sicherzustellen, dass sie funktionieren. In dem gerade besprochenen Beispiel sollten Sie regelmäßig und unabhängig von der Erfordernis einen Failover auf die Standby-Ressourcen durchführen.
**Gängige Antimuster:**
+ Failover werden nie in der Produktion durchgeführt.
**Vorteile der Einführung dieser bewährten Methode:** Durch regelmäßige Tests des Notfallwiederherstellungsplans wird sichergestellt, dass er bei Bedarf funktioniert und vom Team umgesetzt werden kann.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Workloads für die Wiederherstellung auslegen. Testen Sie regelmäßig Ihre Wiederherstellungspfade. Mithilfe des Recovery Oriented Computing (wiederherstellungsorientiertes Computing) können Sie die für die Wiederherstellung förderlichen Merkmale in Systemen identifizieren. Hierzu zählen: Isolation und Redundanz, die systemweite Fähigkeit zum Zurücksetzen von Änderungen, das Überwachen und Ermitteln des Systemzustands, die Bereitstellung von Diagnosen, automatisierte Wiederherstellungen, ein modulares Design und die Möglichkeit von Neustarts. Erproben Sie den Wiederherstellungspfad, um sicherzustellen, dass die Wiederherstellung innerhalb des vorgegebenen Zeitraums erfolgt und der vorgegebene Zustand erreicht wird. Dokumentieren Sie während dieser Wiederherstellung auftretende Probleme in Ihren Runbooks und suchen Sie vor dem nächsten Test nach Lösungen.
+ [The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project](http://roc.cs.berkeley.edu/)
+ Verwenden Sie CloudEndure Disaster Recovery zum Implementieren und Testen Ihrer Strategie für die Notfallwiederherstellung.
+ [Testen der Lösung für die Notfallwiederherstellung mit CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [CloudEndure Disaster Recovery auf AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Testen der Lösung für die Notfallwiederherstellung mit CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project](http://roc.cs.berkeley.edu/)
+ [Was ist AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Lösungen für Sicherung, Wiederherstellung und Notfallwiederherstellung mit AWS AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Ähnliche Beispiele:**
+ [AWS Well-Architected Labs: Testen der Ausfallsicherheit](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Verwalten der Konfigurationsabweichungen am Standort oder in der Region der Notfallwiederherstellung:
Stellen Sie sicher, dass die Infrastruktur, die Daten und die Konfiguration am Standort oder in der Region der Notfallwiederherstellung den Anforderungen entsprechen. Sie sollten beispielsweise prüfen, ob AMIs und Service Quotas auf dem neuesten Stand sind.
AWS Config überwacht und zeichnet Ihre AWS-Ressourcenkonfigurationen kontinuierlich auf. Es kann Abweichungen erkennen und als Auslöser für [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) dienen, um diese zu beheben und Warnmeldungen zu senden. AWS CloudFormation kann zusätzlich Abweichungen in bereitgestellten Stacks erkennen.
**Gängige Antimuster:**
+ Versäumnis, Aktualisierungen an Ihren Wiederherstellungsstandorten vorzunehmen, wenn Sie Konfigurations- oder Infrastrukturänderungen an Ihren Hauptstandorten vornehmen.
+ Mögliche Einschränkungen (z. B. Serviceunterschiede) an Ihren primären Standorten und den Standorten für die Notfallwiederherstellung werden nicht berücksichtigt.
**Vorteile der Einführung dieser bewährten Methode:** Wenn Ihre Umgebung für die Notfallwiederherstellung mit der vorhandenen Umgebung konsistent ist, gewährleisten dies eine vollständige Wiederherstellung.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Sicherstellen, dass die Bereitstellung an Haupt- und Sicherungsstandorte erfolgt Pipelines für die Bereitstellung von Anwendungen in der Produktion müssen die Anwendungen an alle Standorte verteilen, die in der Strategie für die Notfallwiederherstellung angegeben sind. Dazu gehören auch Entwicklungs- und Testumgebungen.
+ Aktivieren von AWS Config zum Verfolgen von Standorten mit möglichen Abweichungen. Erstellen Sie mithilfe von AWS Config Regeln Systeme, die Ihre Strategien für die Notfallwiederherstellung durchsetzen und bei Erkennung von Abweichungen Warnungen generieren.
+ [Korrigieren von nicht konformen AWS-Ressourcen mit AWS-Config-Regeln](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Verwenden Sie AWS CloudFormation zur Bereitstellung Ihrer Infrastruktur. AWS CloudFormation kann Abweichungen zwischen den Angaben in den CloudFormation-Vorlagen und der tatsächlichen Bereitstellung erkennen.
+ [AWS CloudFormation: Ermitteln von Abweichungen im gesamten CloudFormation-Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: Ermitteln von Abweichungen im gesamten CloudFormation-Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Wie implementiere ich eine Lösung für die Verwaltung der Infrastrukturkonfiguration in AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Korrigieren von nicht konformen AWS-Ressourcen mit AWS-Config-Regeln](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05: Automatisieren der Wiederherstellung
Automatisieren Sie mit Tools von AWS oder Drittanbietern die Systemwiederherstellung und leiten Sie Datenverkehr zum Standort oder zur Region der Notfallwiederherstellung weiter.
Basierend auf konfigurierten Zustandsprüfungen können AWS-Services wie Elastic Load Balancing und AWS Auto Scaling die Last auf fehlerfreie Availability Zones verteilen während Services wie z. B, Amazon Route 53 und AWS Global Accelerator, die Last an fehlerfreie AWS-Regionen leiten können. Amazon Route 53 Application Recovery Controller hilft Ihnen, mithilfe von Bereitschaftsprüfungen und Routing-Steuerungsfunktionen Failover-Vorgänge zu verwalten und zu koordinieren. Diese Funktionen überwachen kontinuierlich die Fähigkeit Ihrer Anwendung, eine Wiederherstellung nach Fehlern durchzuführen, so dass Sie die Wiederherstellung der Anwendung über mehrere AWS-Regionen, Availability Zones und On-Premises kontrollieren können.
Für Workloads in bestehenden physischen oder virtuellen Rechenzentren oder privaten Clouds, [AWS Elastic Disaster Recovery,](https://aws.amazon.com/cloudendure-disaster-recovery/)verfügbar durch AWS Marketplace, ermöglicht es Unternehmen, eine automatisierte Notfallwiederherstellungsstrategie auf AWS einzurichten. CloudEndure unterstützt auch die regions- bzw. AZ-übergreifende Notfallwiederherstellung in AWS.
**Gängige Antimuster:**
+ Die Implementierung von identischem automatisiertem Failover und Failback kann bei einem Fehler zu Flapping führen.
**Vorteile der Einführung dieser bewährten Methode:** Die automatisierte Wiederherstellung verkürzt die Wiederherstellungszeit, da manuelle Fehler nicht mehr möglich sind.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Automatisieren von Wiederherstellungspfaden. Wenn in Szenarien mit hoher Verfügbarkeit kurze Wiederherstellungszeiten erforderlich sind, sind menschliche Beurteilungen und Aktionen zu langsam. Das System sollte in jeder Situation in der Lage sein, eine Wiederherstellung durchzuführen.
+ Verwenden Sie CloudEndure Disaster Recovery für automatisiertes Failover und Failback. CloudEndure Disaster Recovery repliziert Ihre Computer (einschließlich Betriebssystem, Systemstatuskonfiguration, Datenbanken, Anwendungen und Dateien) kontinuierlich in einen kostengünstigen Staging-Bereich in Ihrem AWS-Konto-Zielkonto und in Ihrer bevorzugten Region. Bei einem Notfall können Sie CloudEndure Disaster Recovery anweisen, innerhalb weniger Minuten automatisch Tausende Ihrer virtuellen Maschinen vollständig bereitgestellt zu starten.
+ [Ausführen von Failover und Failback bei Notfallwiederherstellungen](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Ressourcen
**Zugehörige Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Notfallwiederherstellung unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Notfallwiederherstellungsserie](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: Für die Notfallwiederherstellung geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [CloudEndure Disaster Recovery auf AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Notfallwiederherstellung von Workloads auf AWS: Wiederherstellung in der Cloud (AWS-Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Relevante Videos:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2) (Architekturmuster für Aktiv-Aktiv-Anwendungen in mehreren Regionen)](https://youtu.be/2e29I3dA8o4)