Die Notwendigkeit, eine effektive Backup-Strategie zu entwickeln, ist in der heutigen Zeit von zunehmender Digitalisierung und Cloud-Nutzung von entscheidender Bedeutung. Im Zusammenhang mit Amazon Web Services (AWS) gibt es eine Vielzahl von Tools und Techniken, die es Unternehmen ermöglichen, ihre Daten sicher zu speichern, bei Bedarf wiederherzustellen und die Betriebsfähigkeit des Unternehmens auch bei unerwarteten Vorfällen zu gewährleisten. In diesem Kontext spielen Amazon Elastic Block Store (EBS)-Snapshots, AWS Backup und AWS Storage Gateway eine zentrale Rolle bei der Automatisierung und Optimierung der Backup-Strategien. Diese Lösungen bieten nicht nur eine zuverlässige Sicherung von Daten, sondern ermöglichen auch eine effiziente Verwaltung und Integration in hybride Cloud-Umgebungen.

EBS-Snapshots bieten inkrementelle Backups, die sich hervorragend eignen, um regelmäßig aktualisierte Daten zu schützen. Diese Art der Sicherung ermöglicht es, den Zustand von EC2-Instanzen zu einem bestimmten Zeitpunkt zu speichern, was für dynamische Datenbanken oder laufende Anwendungen ideal ist. AWS Backup bietet eine zentrale Lösung zur Verwaltung und Automatisierung von Backups über verschiedene AWS-Dienste hinweg, wie z.B. Amazon Relational Database Service (RDS), DynamoDB und Amazon Elastic File System (EFS). Diese Lösung vereinfacht die Erstellung von Backup-Plänen und die Überwachung der Backups über eine einzige Konsole hinweg.

Eine weitere nützliche Lösung ist das AWS Storage Gateway, das es ermöglicht, lokale Backups von On-Premise-Daten zu erstellen und so eine zusätzliche Redundanz zu schaffen. Dieses Hybrid-Modell hilft Unternehmen, ihre Daten sowohl lokal als auch in der Cloud zu sichern, was zu einer höheren Verfügbarkeit und Sicherheit führt. Der strategische Einsatz dieser Dienste ermöglicht es, maßgeschneiderte und skalierbare Backup-Lösungen zu schaffen, die den individuellen Bedürfnissen eines Unternehmens gerecht werden.

Der Aufbau einer effektiven AWS-Backup-Strategie beginnt mit einer gründlichen Analyse der wichtigsten Daten und Anwendungen im Unternehmen. Es ist entscheidend, die Häufigkeit und Dauer der Backups auf die kritischen Daten abzustimmen. Für Unternehmen mit besonders sensiblen oder geschäftskritischen Informationen sind möglicherweise häufigere Backups erforderlich, während weniger wichtige Daten mit längeren Intervallen gesichert werden können. Ein weiteres zentrales Element bei der Planung einer Backup-Strategie ist die Wahl des geeigneten Speicherorts für die Backups. AWS bietet mit S3, Glacier und anderen Diensten verschiedene Optionen, die unterschiedlichste Anforderungen in Bezug auf Kosten, Haltbarkeit und Zugänglichkeit abdecken.

Eine automatisierte Backup-Planung ist ebenfalls von großer Bedeutung. Durch den Einsatz von AWS Backup oder dem Amazon Data Lifecycle Manager können Unternehmen ihre Backup-Prozesse automatisieren und regelmäßig sicherstellen, dass alle Daten gesichert werden. Eine weitere wesentliche Praxis ist die Überwachung und regelmäßige Überprüfung der Backups. Nur durch kontinuierliche Tests der Backup-Integrität kann sichergestellt werden, dass Daten im Ernstfall zuverlässig wiederhergestellt werden können.

Die Validierung von Backups und das regelmäßige Testen von Disaster-Recovery-Szenarien sind ebenfalls essenziell für die Effektivität einer Backup-Strategie. Diese Tests bestätigen, dass die Backup-Daten tatsächlich korrekt und im gewünschten Umfang wiederhergestellt werden können. Neben der technischen Durchführung von Tests sollte auch die Sicherheit der Backups oberste Priorität haben. Die Verschlüsselung der Daten, sowohl im Ruhezustand als auch während der Übertragung, stellt sicher, dass diese vor unbefugtem Zugriff geschützt sind. Ebenso ist die Verwaltung der Zugriffsrechte über IAM (Identity and Access Management) von entscheidender Bedeutung, um den Zugriff auf sensible Daten zu kontrollieren.

Ein weiterer wichtiger Aspekt ist die Einhaltung von regulatorischen Anforderungen, die je nach Branche variieren können. Sektorspezifische Vorschriften, wie etwa HIPAA im Gesundheitswesen, erfordern oft, dass Daten in mehreren geografischen Regionen gesichert und verarbeitet werden. Hier kommen Geo-Replikation und Multi-Region-Strategien ins Spiel, die eine erhöhte Ausfallsicherheit und Compliance gewährleisten. Die geografische Redundanz bietet nicht nur Schutz vor regionalen Ausfällen, sondern schützt auch vor größeren Naturkatastrophen, die ein einzelnes Rechenzentrum betreffen könnten.

Ein integrierter Ansatz, der sowohl lokale als auch Cloud-basierte Lösungen umfasst, ist oft der Schlüssel zu einer umfassenden und robusten Backup-Strategie. Mit der richtigen Kombination von AWS-Diensten und einer gut durchdachten Automatisierung können Unternehmen ihre Backup-Strategien nicht nur optimieren, sondern auch sicherstellen, dass ihre Daten stets verfügbar und geschützt sind, unabhängig von den äußeren Umständen.

Ein oft übersehener, aber wichtiger Bestandteil der Backup-Strategie ist die Erstellung von Runbooks – vordefinierten Abläufen, die im Falle eines Notfalls eine schnelle und fehlerfreie Wiederherstellung der Systeme ermöglichen. Diese Runbooks, die in AWS Systems Manager Automation integriert werden können, erleichtern die Automatisierung von Disaster-Recovery-Prozessen und beschleunigen die Wiederherstellung von Diensten.

Zu guter Letzt ist es von entscheidender Bedeutung, regelmäßig Disaster-Recovery-Übungen durchzuführen, um sicherzustellen, dass alle Mitarbeiter und Systeme auf den Ernstfall vorbereitet sind. Diese Übungen helfen nicht nur dabei, Lücken in der Strategie zu identifizieren, sondern stärken auch das Vertrauen in die Fähigkeit des Unternehmens, im Falle eines Ausfalls schnell und effizient zu reagieren.

Wie man Betriebsresilienz mit gut gestalteten Reaktionsverfahren und kontinuierlicher Verbesserung stärkt

Das Szenario einer verzögerten Datenbankantwort und der daraus resultierenden Auswirkung auf das Service Level Agreement (SLA) verdeutlicht, wie wichtig es ist, gut durchdachte Reaktionsprozeduren und sogenannte Runbooks zu haben. In solchen kritischen Momenten kann ein detailliertes Runbook den entscheidenden Unterschied machen. Es führt den Teamleiter dazu, bestimmte Dashboards zu überprüfen und mithilfe von X-Ray-Traces die Ursache für die hohe Latenz in der Datenbanktier zu isolieren. Ein Runbook kann sogar den genauen SQL-Befehl angeben, um eine blockierte Datenbankoperation zu bereinigen. In solchen Fällen hilft es, wenn das Team auch bei Schlafmangel oder Konzentrationsstörungen auf vordefinierte Verfahren zurückgreifen kann, um schnell die Auswirkungen auf das Geschäft zu minimieren.

Ein gut gestaltetes Reaktionsverfahren stellt sicher, dass die Betriebsresilienz auch dann aufrechterhalten wird, wenn kritische Systeme ausfallen. Eine bewährte Praxis im Rahmen der operationalen Exzellenz ist es, regelmäßig die Betriebsprozeduren und Runbooks zu überprüfen und weiterzuentwickeln. Die Service-Verantwortlichen sollten sich regelmäßig treffen, um diese lebenden Dokumente auf Basis der neuesten Erfahrungen zu aktualisieren. Dies gibt nicht nur die Möglichkeit, Erfolge zu feiern, sondern auch eine Kultur der kontinuierlichen Verbesserung über verschiedene Teams hinweg zu fördern. Zudem sollten Dashboards überprüft und nach größeren Vorfällen wie der Datenbanklatenz ein „blameless postmortem“ durchgeführt werden. Ziel eines solchen postmortems ist es, ohne Schuldzuweisungen zu verstehen, was passiert ist, warum es passiert ist und wie es in Zukunft verhindert werden kann. Wie es im Buch „Site Reliability Engineering“ von Google beschrieben wird, liegt der Fokus auf systemischen Problemen und Prozesslücken und nicht auf den Fehlern einzelner Personen. Eine solche Kultur ermöglicht es den Teams, Fehler offen zu diskutieren, aus Misserfolgen zu lernen und die Verfahren ohne Angst vor Bestrafung zu verbessern.

Die Erkenntnisse aus jedem Postmortem sollten in die Verbesserung von Erkennungs-, Untersuchungs- und Wiederherstellungsverfahren einfließen. Die kontinuierliche Verbesserung von Runbooks und das Lernen aus Ausfällen sind entscheidend, um die betriebliche Resilienz über die Zeit hinweg zu erhöhen. Nach der Analyse des Vorfalls mit der Datenbanklatenz konnten wir mehrere Engpässe identifizieren, die verbessert werden mussten. Wir entschieden uns, eine Warteschlange direkt nach der Benutzerregistrierung einzuführen, um die initiale Anmeldung vom Zahlungsprozess zu entkoppeln. Darüber hinaus fügten wir eine weitere Warteschlange nach Abschluss der Zahlung hinzu, um den Account in einem separaten Schritt final zu konfigurieren. Diese Änderungen trugen zur Minderung der ursprünglichen Ursache bei.

Doch solche Änderungen machen Teile unserer Runbooks und Dashboards veraltet. Deshalb ist es entscheidend, alle Beteiligten in der Vorfallsreaktion über Änderungen an der Dokumentation zu informieren. Runbooks und Überwachungstools müssen aktualisiert werden, um die neuen Warteschlangen und Systemarchitekturen widerzuspiegeln. Veraltete Dokumentation kann zu Verwirrung bei zukünftigen Ausfällen führen. Die Aktualisierung unserer Verfahren gehört daher zur kontinuierlichen Verbesserung. Während wir unsere Systeme für eine bessere Resilienz weiterentwickeln, müssen auch unsere betrieblichen Handlungsanweisungen entsprechend weiterentwickelt werden. Die Synchronisation dieser lebenden Dokumente ist entscheidend, um ihren Wert während der Vorfallsbehandlung zu maximieren.

Ein wichtiger Grundsatz der Resilienztechnik besagt, dass alles immer ausfällt. Dies ist eine Wahrheit, die immer wieder in diesem Buch auftaucht. Anstatt zu versuchen, alle Ausfälle zu verhindern, müssen wir Systeme so entwerfen, dass sie den unvermeidlichen Ausfällen standhalten. Obwohl wir nicht jedes mögliche Szenario vorhersagen können, können wir Erfahrungen – sogenannte Produktionsnarben – und Überwachungsmetriken nutzen, um wahrscheinliche Ausfälle zu antizipieren. Für unsere Entwicklung der Warteschlangen können wir vorab annehmen, dass die Warteschlange wächst, wenn zu viele Nachrichten sich stauen oder fehlerhafte Releases die Warteschlange mit ungültigen Nachrichten verseuchen, die eine Verarbeitung verhindern. Um diese Annahmen proaktiv zu validieren, könnten wir absichtlich Fehler während des Tests einfügen, um das Verhalten des Systems zu beobachten.

Solche Annahmen zu testen und Fehler gezielt zu provozieren, hat sich als Praxis des „Chaos Engineering“ etabliert. Chaos Engineering zielt darauf ab, die Systemresilienz zu verbessern, indem absichtlich Fehler in Produktionsumgebungen auf kontrollierte Weise eingeführt werden. Dienste wie der AWS Fault Injection Service (FIS) ermöglichen es Ingenieuren, Experimente zu entwerfen, die Fehler wie hohe CPU-Auslastung, Netzwerkverzögerungen oder Instanzabschaltungen simulieren. Teams können mit risikoarmen Testumgebungen beginnen und dann allmählich Produktionssysteme testen, wenn die Verfahren verfeinert sind. Jeder Test sollte eine Hypothese und ein erwartetes Ergebnis haben. Wenn das System anders als erwartet reagiert, fließen die Erkenntnisse in weitere Verbesserungen der Resilienz ein.

Eine weitere Möglichkeit zur Förderung der operationalen Exzellenz ist der Einsatz von sogenannten „Game Days“. Dabei handelt es sich um simulierte Produktionsvorfälle, bei denen Teams ihre Reaktionen üben. Solche Spieltage helfen nicht nur dabei, das Wissen zu erneuern, wenn sich die Architektur verändert oder Mitarbeiter das Unternehmen verlassen, sondern auch, um Lücken in Runbooks, Überwachungs- und Koordinationsprozessen zwischen Teams aufzudecken. Durch die Replikation von Produktionsumgebungen über Infrastructure as Code (IaC) können realistische Szenarien geschaffen werden, die Teams testen, untersuchen und entschärfen müssen. Game Days sind ein wertvolles Instrument, um die betriebliche Bereitschaft aufrechtzuerhalten und weiterzuentwickeln.

Ein weiteres Element der Resilienzsteigerung ist die Nutzung von vollständig verwalteten AWS-Diensten. Durch die Nutzung solcher Dienste wie Amazon RDS für Datenbanken statt selbstverwalteter EC2-Datenbanken profitieren Unternehmen von den bewährten Betriebspraktiken von AWS, ohne diese selbst entwickeln zu müssen. Diese verwalteten Dienste verringern den Wartungsaufwand und ermöglichen es den Unternehmen, sich auf die wesentlichen Geschäftsprozesse zu konzentrieren. Amazon SQS etwa entfernt die Notwendigkeit, ein eigenes Warteschlangensystem zu entwickeln. Selbstverständlich sind verwaltete Dienste nicht immer die beste Wahl für jede Arbeitslast, aber im Allgemeinen tragen sie zur Erhöhung der Betriebsresilienz bei.

Was bedeutet "immutable Infrastruktur" und wie verbessern Container die Resilienz von Systemen?

Immutable Infrastruktur ist ein Paradigmenwechsel im Umgang mit der Bereitstellung und Verwaltung von Anwendungen. Anstatt bestehende Systeme zu verändern, verfolgt diese Methode den Ansatz, bei jeder notwendigen Änderung neue, unveränderliche Instanzen zu erstellen. Dies bringt verschiedene Vorteile hinsichtlich der Resilienz, Konsistenz und Verwaltung. Der Kerngedanke hinter der Immutable-Infrastruktur besteht darin, VMs und Cloud-Infrastrukturkomponenten als wegwerfbare Entitäten zu behandeln. Dies sorgt nicht nur für eine einfachere Handhabung, sondern auch für eine zuverlässigere und skalierbare Systemarchitektur.

In der AWS-Welt werden VMs als Elastic Compute Cloud (EC2)-Instanzen bezeichnet. Instanzen sind grundsätzlich auch als Server bekannt, wobei AWS zusätzlich Bare-Metal-Server (physische Maschinen) mit unterschiedlichen CPU-Architekturen anbietet. Diese bieten weitere Optionen, die vor allem bei speziellen Anforderungen wie Performance oder Hardwarezugriff von Interesse sind. Das Verständnis von EC2-Instanzen und den Unterschieden zwischen virtuellen Maschinen und Bare-Metal-Servern ist entscheidend, um zu wissen, wie man Immutable-Infrastruktur optimal in der AWS-Umgebung nutzen kann.

Ein praktisches Beispiel für den Umgang mit Immutable-Infrastruktur könnte eine EC2 Auto Scaling-Gruppe (ASG) sein, die mit einer Amazon Machine Image (AMI) instanziiert wird. Wird eine neue Version einer Anwendung entwickelt, sorgt eine CI/CD-Pipeline dafür, dass eine neue AMI-Version (z.B. AMI-002) erstellt wird. Diese enthält die aktualisierte Version des Codes. Der ASG-Launch-Config wird dann aktualisiert, und es werden neue Instanzen gestartet, die exakt der neuen Konfiguration entsprechen. Alle alten Instanzen werden entweder verworfen oder abgeschaltet. Dies minimiert das Risiko von Konfigurationsabweichungen und stellt sicher, dass alle Instanzen identisch sind, was zu einer hohen Zuverlässigkeit führt.

Ein weiterer Vorteil der Immutable-Infrastruktur ist die verbesserte Trennung der Zuständigkeiten. Der Prozess des Erstellens und Konfigurierens von Instanzen wird von der Laufzeitumgebung entkoppelt. Dies ermöglicht eine robustere und automatisierte Bereitstellungspipeline, die wiederum häufigere und schnellere Deployments sowie ein einfacheres Rollback bei Problemen ermöglicht. Dadurch wird die Gesamtresilienz des Systems erhöht und Ausfallzeiten werden verringert.

Um diese Theorie in der Praxis zu testen, kann man ein Beispiel aus einem GitHub-Repository verwenden, das mit der Erstellung und Bereitstellung von AMIs auf AWS arbeitet. Das Skript, das hier bereitgestellt wird, kann verwendet werden, um eine neue AMI zu erstellen und zu veröffentlichen, was den beschriebenen Prozess weiter verdeutlicht.

Container als unveränderliche Bausteine

Container sind ein zentraler Bestandteil der Immutable-Infrastruktur und bieten eine Reihe von Vorteilen, die in traditionellen Virtualisierungen oder Instanzen nicht immer in gleicher Weise zur Verfügung stehen. Container bieten eine isolierte Umgebung, die eine maximale Flexibilität bei der Bereitstellung und Skalierung von Anwendungen ermöglicht. Sie beinhalten alle notwendigen Systemtools, Bibliotheken und Einstellungen, die für die Ausführung einer Anwendung erforderlich sind. Dies führt zu einer leichten, portablen und vor allem schnellen Bereitstellung von Anwendungen, da die Containerumgebung unabhängig vom zugrunde liegenden Betriebssystem ist.

Die Erstellung und Verwaltung von Container-Images erfolgt in mehreren Schritten. Container-Images sind unveränderlich und enthalten alles, was nötig ist, um eine Anwendung auszuführen. Sie werden über Container-Registries wie Docker Hub oder Amazon Elastic Container Registry (ECR) verwaltet und verbreitet. Container-Images können dabei als unveränderliche Bausteine betrachtet werden, die den gesamten Lifecycle einer Anwendung begleiten. Die Nutzung von CI/CD-Pipelines zur Automatisierung der Erstellung und Bereitstellung dieser Container-Images sorgt für eine schnelle, fehlerfreie und skalierbare Produktion.

Der Prozess, Container-Images zu erstellen, wird durch eine sogenannte Multi-Stage-Build-Technik erheblich vereinfacht. Bei dieser Methode wird ein größeres Image verwendet, um die Anwendung zu bauen, und nach erfolgreichem Build wird nur das Ergebnis in ein kleineres Image übertragen. Diese Technik spart Speicherplatz und reduziert die Build-Zeit. In einem konkreten Beispiel könnte ein Dockerfile verwendet werden, das einen Golang-Build-Prozess in zwei Phasen unterteilt: in einer ersten Phase wird das vollständige Entwicklungsumfeld genutzt, während in einer zweiten Phase nur das finale Ergebnis in ein minimalistisches Image überführt wird.

Container-Registries und das Management von Container-Images

Container-Images sind in Registries gespeichert, die als zentrale Repositories dienen. Sie ermöglichen eine einfache Verwaltung und Verteilung von Images über mehrere Umgebungen hinweg. Häufig verwendete Container-Registries sind Docker Hub und Amazon ECR. Es ist wichtig zu beachten, dass Docker Inc. die Tools entwickelt hat, die den Umgang mit Containern erheblich erleichtern. Obwohl Docker und Container-Technologien oft synonym verwendet werden, existieren Container schon lange vor Docker als Technologie. Docker hat jedoch einen einfachen und benutzerfreundlichen Ansatz entwickelt, der die weltweite Akzeptanz von Containern maßgeblich beeinflusste.

Für eine Produktionsumgebung ist es empfehlenswert, Versionierungssysteme wie das semantische Versionierungssystem zu nutzen, um sicherzustellen, dass jedes Container-Image eindeutig und nachvollziehbar ist. Dies ist besonders wichtig, wenn man mehrere Versionen einer Anwendung parallel betreibt oder kontinuierlich neue Releases veröffentlicht.

Der Ablauf beim Erstellen von Container-Images ist relativ einfach, wenn man die richtigen Werkzeuge wie Docker verwendet. Dabei werden die Images lokal gebaut, getaggt und dann in einer Registry gespeichert, um die Verteilung und Nutzung in unterschiedlichen Umgebungen zu ermöglichen. Dies stellt sicher, dass alle Instanzen die gleiche, unveränderte Version der Anwendung ausführen, was die Konsistenz und Sicherheit des Systems erhöht.

Wichtige Überlegungen und Konsequenzen

Ein zentraler Punkt bei der Verwendung von Immutable-Infrastruktur ist, dass durch die Schaffung neuer Instanzen anstelle der direkten Modifikation alter Systeme die Gefahr von Konfigurationsabweichungen (Configuration Drift) minimiert wird. Jede neue Instanz basiert auf einem identischen Image, was sicherstellt, dass alle Umgebungen gleich sind und die Anwendung konstant funktioniert. Dies hat nicht nur positive Auswirkungen auf die Bereitstellung und das Testen von Anwendungen, sondern auch auf die Wartung und das Troubleshooting, da jeder Server exakt gleich konfiguriert ist.

Darüber hinaus sorgt die Trennung von Build und Laufzeitumgebung für eine bessere Fehlerisolierung und schnellere Rollbacks bei Problemen. Wenn eine neue Version einer Anwendung fehlschlägt, kann schnell auf eine frühere, funktionierende Version zurückgegriffen werden, ohne dass langwierige und fehleranfällige manuelle Anpassungen erforderlich sind.

Die Nutzung von Containern als Teil der Immutable-Infrastruktur ermöglicht es, Anwendungen effizienter zu skalieren und schneller zu deployen. Container bieten die nötige Flexibilität, um in verschiedenen Umgebungen (lokal, in der Cloud, on-premise) mit der gleichen Konfiguration und den gleichen Abhängigkeiten zu arbeiten. So lassen sich Entwicklungs-, Test- und Produktionsumgebungen nahtlos miteinander integrieren.

Welche Disaster-Recovery-Strategien bietet AWS, um Infrastruktur schnell wiederherzustellen?

Die Sicherstellung einer schnellen Wiederherstellung der Infrastruktur nach einem Ausfall ist von ebenso großer Bedeutung wie die Vermeidung von Datenverlusten. Ein zentrales Element bei der Planung einer effektiven Wiederherstellungslösung ist die Implementierung von Infrastructure as Code (IaC). IaC ermöglicht es, die Infrastrukturkonfiguration zu versionieren, zu verfolgen und bei Bedarf zu reproduzieren. AWS stellt mit CloudFormation ein eigenes IaC-Framework zur Verfügung, es gibt jedoch auch Drittanbieterlösungen wie Terraform, die ähnliche Funktionen bieten.

Eine weitergehende Maßnahme zur Verbesserung der Disaster-Recovery- (DR-)Prozesse ist die Automatisierung der Wiederherstellung. Hierbei können Deployment-Pipelines wie CodePipeline oder Jenkins zum Einsatz kommen, die eine schnelle und zuverlässige Wiederherstellung von Infrastruktur und Anwendungen ermöglichen. Die Automatisierung verkürzt die Wiederherstellungszeiten erheblich und stellt sicher, dass nach einem Ausfall die benötigten Ressourcen zeitnah wiederhergestellt werden.

AWS bietet zudem eine umfassende Backup-Lösung an – AWS Backup – die es einfach macht, Backups über die gesamte AWS-Cloud-Infrastruktur hinweg zu orchestrieren. Viele AWS-Dienste, wie DynamoDB, RDS oder Amazon S3, bieten bereits eingebaute Funktionen zur Wiederherstellung zu einem bestimmten Zeitpunkt (point-in-time recovery), wodurch die Anforderungen an das Recovery Point Objective (RPO) problemlos erfüllt werden können. So bietet beispielsweise Amazon S3 mit Versionierung und Cross-Region-Replikation die Möglichkeit, ältere Daten zu speichern und sie nahtlos in andere Regionen zu replizieren, ohne dass ein separates Backup-Service erforderlich ist.

Das Thema Backup ist jedoch nicht nur auf die Sicherung von Daten angewiesen. Es ist auch von entscheidender Bedeutung, eine solide Strategie für die Aufbewahrung und Löschung von Backups zu entwickeln. Die regelmäßige Planung von Backups sollte mit einer Strategie zur Lebenszyklusverwaltung kombiniert werden, um veraltete und nicht mehr benötigte Backups systematisch zu löschen. Dies trägt nicht nur dazu bei, Speicherressourcen zu optimieren, sondern sorgt auch dafür, dass das Backup-Repository effizient bleibt. Der Erfolg dieser Maßnahmen liegt in der Balance zwischen Datenaufbewahrung und Speicherverwaltung, um sicherzustellen, dass die Backups im Falle eines Ausfalls schnell wiederhergestellt werden können.

Dennoch bieten Backup- und Restore-Prozesse nicht immer die optimale Lösung für hochkritische Anwendungen, bei denen schnelle Wiederherstellung und minimierte Datenverluste erforderlich sind. Für diese Fälle ist eine fortgeschrittene DR-Strategie wie „Pilot Light“ erforderlich. Diese Methode verbessert das RTO (Recovery Time Objective) und das RPO erheblich, da sie den Datenwiederherstellungsprozess in der Wiederherstellungsregion minimiert. Statt eine komplette Datenwiederherstellung durchzuführen, wird die Datenreplication in eine sekundäre Region fortlaufend aufrechterhalten, wodurch Daten jederzeit verfügbar und aktuell sind.

Obwohl die Pilot-Light-Strategie viele Vorteile in Bezug auf Geschwindigkeit und Kosten hat, müssen trotzdem Infrastrukturrichtlinien in der sekundären Region bereitgestellt werden, was zusätzliche Kosten verursacht. AWS-Dienste wie Aurora Global Database, DynamoDB Global Tables und S3 erleichtern die kontinuierliche Replikation von Daten in eine sekundäre Region und ermöglichen so eine fast sofortige Wiederherstellung mit minimalem Datenverlust.

Die Pilot-Light-Strategie hält jedoch nur minimale Infrastruktur in der sekundären Region bereit. Für den Betrieb der Anwendungen muss weitere Infrastruktur provisioniert werden, was jedoch zusätzliche Zeit erfordert. Um diese Zeit zu verkürzen, kann IaC und Versionskontrollsysteme wie GitHub oder CodeCommit genutzt werden, um den Bereitstellungsprozess zu beschleunigen. Trotz dieser Hilfe bleibt jedoch ein gewisser Zeitaufwand bestehen, was den RTO beeinträchtigen kann. Um dieses Problem zu lösen, bietet sich der Ansatz der „Warm Standby“-Strategie an.

Die Warm-Standby-Strategie baut auf der Pilot-Light-Strategie auf und verbessert sie, indem eine skaliert reduzierte Version der Infrastruktur in der sekundären Region bereitgestellt wird, die zusammen mit den replizierten Daten sofort einsatzbereit ist. Diese Vorgehensweise reduziert die Bereitstellungszeit von Infrastruktur und ermöglicht es, DR-Prozesse regelmäßig zu testen, um sicherzustellen, dass die Systeme im Falle eines Ausfalls tatsächlich bereit sind. Trotz der höheren Kosten im Vergleich zur Pilot-Light-Strategie bietet diese Methode eine signifikante Verbesserung der RTO, da die Infrastruktur bereits teilweise vorgehalten wird.

Allerdings sind auch hier Anpassungen nötig, um den Echtbetrieb zu unterstützen, wie etwa das Hochskalieren von Datenbankinstanzen und die Erhöhung der Durchsatzkapazitäten. Mit serverlosen Optionen wie AWS Fargate, die auf den Traffic dynamisch reagieren, lässt sich die Infrastruktur flexibler an die aktuellen Anforderungen anpassen.

Für extrem anspruchsvolle Workloads, bei denen eine nahezu sofortige Wiederherstellung erforderlich ist, kommt die „Hot Standby“-Strategie zum Tragen. Diese Lösung bietet eine nahezu Null-RTO, indem eine vollständige Produktionsumgebung in Echtzeit gespiegelt wird. Hierbei wird entweder eine aktive/aktive oder eine aktive/passive Architektur genutzt, was die Verfügbarkeit und Resilienz auf ein äußerst hohes Niveau hebt. Allerdings sind die damit verbundenen Kosten und der Verwaltungsaufwand erheblich, sodass diese Strategie nur für hochkritische Anwendungen sinnvoll ist.

Unabhängig von der gewählten Strategie bleibt die Frage der genauen Planung und Definition von DR-Zielen ein essentieller Bestandteil jeder DR-Strategie. Die Ziele sollten klar definiert und auf die spezifischen Geschäftsanforderungen abgestimmt sein. Nur durch präzise Planung und kontinuierliche Tests kann gewährleistet werden, dass ein Unternehmen im Falle eines Ausfalls schnell und effizient reagieren kann.

Wie kann man die Zuverlässigkeit und Gültigkeit von Studien sicherstellen?
Wie wurde Juri Gagarin zum ersten Menschen im All und was bedeutete sein Flug für die Sowjetunion?
Welche Rolle spielen zweidimensionale Halbleitermaterialien bei der Wasserstofferzeugung durch Lichtspaltung?