Manche sagen, die besten Dinge im Leben seien kostenlos, aber wenn es um Datenschutz in der Cloud geht, bietet Ihnen „kostenlos“ möglicherweise nur einen Teil dessen, was Sie benötigen, und kostet auf lange Sicht mehr. Letztendlich ist es gut, Optionen zu haben und die Vor- und Nachteile jeder Datenschutzlösung in der Public Cloud abzuwägen, um sicherzustellen, dass Sie das, was Sie benötigen, zu den niedrigsten Kosten erhalten.
Ich bin mir sicher, dass sich viele Leute gefragt haben: „Warum bietet Clumio kostenlose Funktionen zur Snapshot-Verwaltung an, wo Snapshots doch keine Backups sind?“ Sie haben Recht, Snapshots sind keine Backups, aber sie haben durchaus ihre Berechtigung in der Public Cloud.
Snapshots sind ein hervorragender Mechanismus für die operative Recovery von Anwendungen, die eine zeitpunktbezogene Recovery in AWS erfordern. Die operative Recovery ist möglicherweise die einzige Anforderung, wenn Sie zu den ersten Cloud-Nutzern gehören. Für die meisten Nutzer kann sie jedoch Teil einer umfassenderen, ganzheitlichen Datensicherungslösung sein, die eine Datensicherung mit einer Aufbewahrungsdauer von mehr als 14 bis 30 Tagen zur Erfüllung von Compliance-Anforderungen erfordert.
Wir stellen unseren Kunden diese Snapshot-Verwaltungsfunktion kostenlos zur Verfügung, während viele unserer Branchenkollegen dafür Gebühren erheben. Sie ist nur ein Teil einer umfassenden Datensicherungslösung in der Cloud. Allerdings finde ich, dass sie sie stattdessen in „AWS Operational Recovery“ umbenennen sollten. 🙂
Was sind die Vor- und Nachteile von Snapshots in AWS und warum handelt es sich dabei nicht um Backups?
Einer der größten Vorteile von Snapshots ist die Möglichkeit, Fehler, versehentliche Löschungen oder Datenbeschädigungen schnell wiederherzustellen. Lokale Snapshots werden in der Regel auf demselben Array oder in derselben Anwendungsinfrastruktur wie die Kernanwendung gespeichert, um schnelle Recovery-Prozesse zu ermöglichen. In AWS werden Snapshots im selben AWS-Konto wie die Produktionsdaten gespeichert. Unabhängig davon, wo sich diese Snapshots befinden, werden sie in der Regel nur für einen relativ kurzen Zeitraum aufbewahrt, da ihr Wert für die Recovery des Betriebs mit der Zeit abnimmt.
Über Snapshots hinaus müssen Backups außerhalb der Produktionsumgebung aufbewahrt werden, um sicherzustellen, dass Sie auch dann Zugriff auf Ihre Daten haben, wenn die Produktionsinfrastruktur ausfällt oder schwerwiegende Probleme auftreten. Backups eignen sich zudem hervorragend für eine detaillierte Recovery, da sie indexiert und katalogisiert sind und so außerhalb der Produktionsumgebung schnell und granular abgerufen werden können. Compliance-Backups gehen sogar noch einen Schritt weiter, da sie aus rechtlichen oder Compliance-Gründen aufbewahrt werden müssen und auch dann geschützt sein müssen, wenn ein gesamter Standort oder ein Konto kompromittiert wird.
Einer der größten Nachteile von Snapshots ist, dass sie sowohl hinsichtlich der Funktionalität als auch der Kosten völlig versagen, wenn sie für Backups und die langfristige Einhaltung von Vorschriften eingesetzt werden. Nehmen wir zum Beispiel an, Sie haben eine neue Anwendung, die Sie entwickelt oder aus einer lokalen Umgebung migriert haben und für die 30 tägliche Backups sowie 12 monatliche Backups zur langfristigen Aufbewahrung erforderlich sind. Snapshots werden auf demselben Konto wie die Produktionsdaten gespeichert. Wenn Sie also versehentlich ein Skript falsch ausführen, etwas Falsches löschen oder ein Angreifer Zugriff auf Ihr Konto erhält, verlieren Sie das Backup und möglicherweise auch die Daten. Das ist natürlich schlimm.
Um diese Schwachstelle zu vermeiden, könnten Sie diese Snapshots zwar jederzeit zur sicheren Aufbewahrung auf ein anderes AWS-Konto replizieren, doch dann entstehen Ihnen Übertragungskosten, die doppelte Snapshot-Abrechnung, und wenn Sie PaaS-Dienste wie RDS nutzen, müssen Sie vollständige Kopien anstelle von Snapshot-Ketten aufbewahren. Da keine der Daten indiziert oder katalogisiert ist, müssen Sie nun das gesamte System wiederherstellen und die Daten selbst suchen. Die Wiederherstellung der Daten ist ebenfalls mühsam, doch allein die Kosten in diesem Szenario machen Snapshots unbrauchbar.
Warum sollte man für die operative Recovery-Phase das kostenlose Angebot von Clumio nutzen statt AWS Backup oder Snapshot-Manager?
Der „Backup as a Service“-Dienst von Clumio für native AWS-Dienste bietet eine ganzheitliche Lösung zur Datensicherung, die weit über das Snapshot-Management hinausgeht. Auf Ihrem Weg in die Cloud kann Clumio Ihnen einen einheitlichen Datensicherungsdienst bereitstellen, der Ihren unternehmensweiten Anforderungen gerecht wird. Vielleicht nutzen Sie heute Snapshots für die Recovery-Prozesse in einer Test- und Entwicklungsumgebung. Wenn die Anwendung in die Produktion geht, ändern sich die Anforderungen und Sie benötigen mehr Schutz – dennoch möchten Sie keine massiven Kosten durch Snapshots verursachen und haben diese wahrscheinlich auch nicht eingeplant.
Mit Clumio können Sie unseren einzigartigen Air-Gap-Schutz, die vollständige Indizierung und Katalogisierung sowie die granulare Wiederherstellung von Dateien für EBS oder den granularen Abruf von Datensätzen für RDS über den direkten Abfragezugriff auf unseren Data Lake nutzen. Die Benutzererfahrung ist hervorragend und kann für jede Anwendung aktiviert werden, die über Snapshots hinaus diese Features benötigt. Das Beste daran ist, dass all dies im Vergleich zu AWS-Snapshots zu bis zu 50 % geringeren Kosten bereitgestellt werden kann.
Wie sieht die Clumio-Lösung für das Snapshot-Management aus?
Wie bei allem bei Clumio ist die Bedienung einfach, und die Inbetriebnahme dauert nur 15 Minuten. Der erste Schritt besteht darin, ein Benutzerkonto anzulegen – dazu müssen Sie lediglich eine E-Mail-Adresse und ein Passwort eingeben. Anschließend geben Sie Ihre AWS-Kontodaten ein, darunter die AWS-Kontonummer, eine Kontobeschreibung (damit Sie sich daran erinnern können) und die AWS-Region. Klicken Sie dann auf „Weiter“ und starten Sie den CloudFormation-Stack-Assistenten:
Dadurch werden Sie zu AWS weitergeleitet, um den Stack zu erstellen. Klicken Sie auf „Stack erstellen“ und warten Sie etwa 3 bis 5 Minuten, bis der Vorgang abgeschlossen ist.
Sobald der Vorgang abgeschlossen ist, wird Ihr Konto einer Bestandsaufnahme unterzogen. Sie können denselben Vorgang auch für alle anderen Konten durchführen, die Sie schützen möchten. Sobald Sie damit fertig sind, besteht der nächste Schritt darin, eine einheitliche Richtlinie für EBS und/oder RDS zu erstellen.
Legen Sie die Richtlinien für maximal 30 Tage für EBS bzw. maximal 35 Tage für RDS fest:
Clumio nutzt vorhandene Tags zur Anpassung von Richtlinien. Der nächste Schritt besteht daher darin, die Tags festzulegen, die Sie mit der soeben erstellten neuen Richtlinie schützen möchten. Auf diese Weise können Sie bestimmte Ressourcen mit Tags versehen, die durch diese Richtlinie geschützt werden sollen.
Das war’s! Jetzt können Sie die kostenlose Version von Clumio für die Wiederherstellung des Betriebs sowohl für EBS als auch für RDS nutzen.
Da nun die Recovery-Funktion für EBS und RDS verfügbar ist, wollen wir uns den Wiederherstellungsprozess für EBS noch einmal ansehen. Wählen Sie zunächst das EBS-Volume aus, das Sie wiederherstellen möchten, und legen Sie dann den Zeitpunkt fest, zu dem die Wiederherstellung erfolgen soll. In diesem Fall verfüge ich über Backups (dargestellt durch blaue Punkte) und Snapshots (dargestellt durch orangefarbene Punkte). Wenn Sie auf das Datum klicken, werden Ihnen Optionen für beides angezeigt.
Anschließend können Sie das Volume in einer beliebigen verfügbaren AZ wiederherstellen.
RDS bietet eine ähnliche Funktionsweise, unterscheidet sich jedoch geringfügig, da für den Schutz von RDS mehrere Optionen zur Verfügung stehen, darunter das rollierende Backup (zeitversetzte RDS-Instanz in Clumio) und die granulare Datensatzwiederherstellung (Langzeit-Backup).
Wählen Sie zunächst ein Wiederherstellungsdatum aus, für das ein Snapshot verfügbar ist (orangefarbener Punkt), klicken Sie auf „Wiederherstellen“ und wählen Sie dann den Zeitpunkt aus, zu dem Sie die Datenbank wiederherstellen möchten – auf die Sekunde genau. In diesem Fall führe ich die Wiederherstellung um 5:04:04 Uhr durch.
Wie Sie in dieser kurzen Übersicht sehen können, ist der Schutz von AWS-Ressourcen für die Recovery unglaublich einfach! Ganz gleich, ob Sie völlig neue Anwendungen entwickeln, Legacy-Anwendungen aus Ihrem lokalen Rechenzentrum in die Cloud migrieren oder bereits ein erfahrener Cloud-Nutzer sind, bei dem 100 % Ihrer Anwendungen in der Cloud laufen – Clumio hat die passende Lösung für Sie. Weitere Informationen finden Sie in unserem „Backup as a Service“ für AWS.
Bis zum nächsten Mal, bleibt SaaSy, meine Freunde.
