Tipps und Strategien für kosteneffiziente Snapshot-Verwaltung
Snapshots sind der günstige Weg zur Sicherung der Daten im Falle von Hardwaredefekten. Werden Snapshots jedoch als Backup-Ersatz eingesetzt, muss einiges beachtet werden.
Snapshots haben ihre Vor- und Nachteile. Zunächst bieten Snapshots einen schnellen und kostengünstigen Weg zum Sichern und Replizieren der Instanzen eines Datenträgers. In der Cloud können Snapshots jedoch auch unerwartete Kosten verursachen. Sie sind in vielen Fällen eine Ergänzung zu einem vollständigen Backup und manche Anwender setzen Snapshots auch Ersatz für ein Backup ein. Deshalb ist die Implementierung effektiver Snapshot-Management-Strategien besonders wichtig.
Bevor Sie das nützliche Werkzeug der Snapshots effizient nutzen können, müssen Anwender verstehen, wie sie implementiert werden. Wird zum ersten Mal ein Snapshot eines Datenträgers erstellt, werden sämtliche Daten auf der Quellplatte kopiert. Beim nächsten Durchlauf eines Snapshots dieses Datenträgers, werden nur noch die Änderungen gegenüber der initialen beziehungsweise jüngsten vorherigen Kopie übertragen.
Dieses Prinzip ist eigentlich optimal, da Sie nur für die Daten bezahlen müssen, die mit jedem Snapshot übertragen und gespeichert werden. Sie brauchen nicht dafür zu bezahlen, dass redundante Daten kopiert werden, die ja bereits in der Sicherungskopie vorhanden sind. Bei der Wiederherstellung eines Snapshots wird jeder abgeschlossene Snapshot und jeder inkrementelle Snapshot kopiert, um den Zustand des Datenträgers zum Zeitpunkt der Erstellung des letzten Snapshots wiederherzustellen.
Diese augenscheinlich optimale Lösung zum Kopieren von Daten kann einige unerwartete Folgen herbeiführen, darunter
keine große Platzersparnis beim Löschen von Snapshots;
keine Anpassung der Verwaltung der Snapshot-Lebenszyklus-Richtlinien an die jeweilige Umgebung und
das Entstehen von Egress-Gebühren beim Kopieren von Snapshots über Regionen hinweg.
Einige Strategien zur Verwaltung von Snapshots sind jedoch hilfreicher als andere. Es gilt, die Fallstricke zu vermeiden.
Löschen nicht mehr benötigter Snapshot-Daten
Fällt die Rechnung für den genutzten Speicherplatz unerwartet hoch aus, was bei vielen Unternehmen nach einigen Monaten eintritt, sollte das direkt den Impuls auslösen, unnötige Daten zu löschen. Besser noch ist die Vermeidung zu vieler Snapshots: Anstatt dass das Entwicklungsteam zum Beispiel die fünf neuesten Snapshots für ihre Entwicklungsserver aufbewahrt, könnte eine Aufbewahrungsrichtlinie bestimmen, dass nur drei Snapshots gespeichert werden.
Manche Anwender dürften aus solch einer Maßnahme schließen, dass Daten im Umfang von zwei Snapshots oder 40 Prozent der gesamten Snapshot-Größe eingespart werden könnten. Aufgrund der Methodik, mit der jedoch Snapshots inkrementelle Updates verwenden, fallen die Einsparungen allerdings weitaus geringer aus.
Wenn der älteste Snapshot eine vollständige Kopie eines Datenträgers ist und es bezieht sich ein weiterer Snapshot auf diesen, so werden beim Löschen des ältesten Snapshots alle darin enthaltenen Daten wieder in den nächsten Snapshot kopiert. Dies mag aus Sicht einer Datensicherung genau richtig sein, weil dann keine Daten verloren gehen. Allerdingsbringt das Löschen des initialen Snapshots nicht viel hinsichtlich der Einsparung von Speicherplatz und Kostensenkung.
Snapshot-Richtlinien auf die IT- und Anwendungsumgebung abstimmen
Eine Möglichkeit, Kosten für die Speicherung von Snapshots zu sparen, besteht im Anlegen einer Managementrichtlinie für Snapshots unter Berücksichtigung der jeweiligen IT- und Anwendungsumgebung anzupassen, beispielsweise Entwicklung, Test, Benutzerakzeptanz und Produktion. Natürlich wollen Sie eine robuste Sicherheit für der Daten in der Produktion herstellen, auch wenn dies oft zu vermehrten Snapshots führt. Entwicklungsumgebungen sind da anders.
Abbildung 1: Es gibt verschiedene Backup-Verfahren, die entsprechend unterschiedliche Vorteile bieten.
Entwickler arbeiten bei Anwendungen, die regelmäßig umgebaut und wieder bereitgestellt werden, oft anhand einer gemeinsamen Codebasis. Die immer beliebter werdende Continuous-Integration/Continuous-Delivery-Praxis ermöglichtes, dass Entwicklungsumgebungen einen geringen Bedarf an Snapshots haben.
Funktionstests von Entwicklern und Tests der Benutzerakzeptanz ähneln sich insofern, als die Umgebung typischerweise zum Testen der letzten Änderungen an einer Anwendung verwendet wird. Wenn Daten auf einem Server in einer der beiden Testumgebungen verloren gehen, können sie viel einfacher wiederhergestellt werden als bei einem Datenverlust in der Produktionsumgebung. Dann ist der Bedarf an Snapshots geringer als bei Produktionsdaten.
Der Faktor Datenbank-Abhängigkeit
Ein weiterer Aspekt, der beim Management von Snapshots zu berücksichtigen ist, ist die Abhängigkeit eines Snapshots von der Datenbank, mit der er erstellt wurde.
Datenbank-Snapshots müssen in einer Version der Datenbank wiederhergestellt werden, die mit der Version kompatibel ist, mit der der Snapshot erstellt wurde. Dies ist in der Regel kein Problem, wenn Snapshots zur kurzfristigen Datenwiederherstellung verwendet werden, zum Beispiel wenn Daten versehentlich gelöscht und schnell wiederhergestellt werden.
Eine Möglichkeit, Kosten für die Snapshot-Speicherung zu sparen, ist die Anpassung der Snapshot-Verwaltungsrichtlinien an eine bestimmte Umgebung.
Wenn Snapshots jedoch über längere Zeiträume aufbewahrt werden, steigt die Wahrscheinlichkeit, dass die Quelldatenbank-Software ein Update erhielt wird. Das macht Snapshots für die langfristige Sicherung von Datenbanken weniger attraktiv.
Um dieses Problem zu umgehen, erstellen Sie am besten Sicherungen, die von der Quelldatenbank unabhängig sind, indem Sie einen Snapshot exportieren und in Amazon S3 speichern. Beim Exportieren werden die Daten im Apache Parquet-Format gespeichert. Dabei handelt es sich um ein weit verbreitetes spaltenförmiges Format aus dem Hadoop-Ökosystem. Jede Anwendung, die Parquet unterstützt, kann diese Dateien importieren. Um noch mehr Datenvolumen zu sparen, kann für die exportierten Daten ein Bucket der Speicherklasse Infrequent Access S3 genutzt werden.
Es ist wichtig zu beachten, dass beim Kopieren von Snapshots über Regionen hinweg Vorsicht geboten ist, da dadurch Egress-Gebühren anfallen. Erstellen und speichern Sie Snapshots stattdessen innerhalb einer einzigen Region, um die Übertragungsgebühren zu minimieren.
Datenbank-Services wie der AWS Relational Database Service bieten Datenbank-Snapshots. Diese sind besonders für die Sicherung von Produktivdaten nützlich, aber nicht die beste Option für die langfristige Datenspeicherung. Sind dieverschiedenen IT- und Anwendungsumgebungen gut bekannt, bietet es sich an, Richtlinien für das Snapshot-Managementzu implementieren, die zum Bedarf des Unternehmens passen. Dann lassen sich Fallstricke wie überhöhte Egress-Gebühren vermeiden.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
