Ein häufig vorgebrachter Einwand gegen die Verwendung von Snapshots als Datensicherungsstrategie ist die Tatsache, dass sich die „echten“ Daten und die Snapshot-Daten auf denselben Laufwerken befinden. Der Verlust dieser Laufwerke würde sowohl zum Verlust der Primärdaten als auch des Backups führen.

Das ist ein berechtigte Anliegen. Lokale Snapshots werden für tägliche Backup- und Recovery-Anforderungen verwendet, in dieser Hinsicht ist der Snapshot ein Backup. Beinahe 99 % aller Recovery-Szenarien in NetApp Umgebungen basieren auf Snapshots, um selbst die anspruchsvollsten RTO-Anforderungen zu erfüllen.

Lokale Snapshots sollten jedoch nie die einzige Backup-Strategie sein. Aus diesem Grund bietet NetApp Technologien wie SnapMirror Replizierung, mit denen Snapshots schnell und effizient auf einen unabhängigen Laufwerkssatz repliziert werden können. In einer richtig konzipierten Lösung mit Snapshots und Snapshot-Replikation kann die Verwendung von Tapes auf ein vierteljährliches Archiv minimiert oder ganz eliminiert werden.

Bei einem Konsistenzgruppenbackup wird der Status eines Datensatzes (oder mehrerer Datensätze) zu einem einzelnen atomischen Zeitpunkt erfasst. Als Datenbankbeispiel umfasst dies alle Datenbankkomponenten, z. B. Datendateien, Protokolldateien und andere Dateien, die direkt mit der Datenbank verknüpft sind. Dies funktioniert mit fast allen relationalen Datenbankprodukten, einschließlich Oracle RDBMS, Microsoft SQL Server, SAP HANA, PostgreSQL, MySQL und MariaDB. Der Schutz einer VMware-Konfiguration mit einer Consistency Group-Sicherung wäre ähnlich - Erfassung aller Datenspeicher und potenziell der ESX-Boot-LUNs in einem einzigen atomaren Point-in-Time.

Die Erstellung eines solchen Snapshots einer Konsistenzgruppe simuliert im Wesentlichen einen Absturz. Aus diesem Grund werden solche Backups häufig als Crash-konsistente Backups bezeichnet. Es gibt manchmal Bedenken bei der Unterstützung für Recovery-Szenarien, aber es ist wichtig zu verstehen, dass in der Regel kein Recovery-Verfahren erforderlich ist. Wenn die Anwendung nach dem Wiederherstellen einer Consistency Group-Sicherung gestartet wird, führt sie die üblichen Protokollwiederherstellungsprozesse, Wiederholungen von Dateisystemjournalen und andere Aufgaben aus, um alle I/O-Vorgänge, die am Zeitpunkt des Backups im laufenden Vorgang waren, wiederzugeben. Die Anwendung startet dann wie gewohnt.

Somit können grundsätzlich alle Applikationen geschützt werden, die einem Stromausfall oder Serverabsturz ohne Datenbeschädigung standhalten. Dass dies funktioniert, zeigt sich auch an der großen Zahl an Applikationen, die mit synchronen und asynchronen Spiegelungsprodukten vieler verschiedener Anbieter geschützt sind. Wenn plötzlich am primären Standort ein Notfall eintritt, enthält der Replikatstandort zum Zeitpunkt des Ausfalls ein konsistentes Abbild der ursprünglichen Umgebung. Auch hier ist kein besonderes Recovery-Verfahren erforderlich.

Der RPO für diesen Ansatz ist in der Regel auf den Punkt des Backups begrenzt. Im Allgemeinen beträgt der RPO-Mindestwert für Snapshots mit einem einzigen Volume eine Stunde. Zum Beispiel sind 48 stündliche Schnappschüsse plus weitere 30 Tage nächtlicher Schnappschüsse vernünftig und würden nicht die Aufbewahrung einer übermäßigen Anzahl von Snapshots erfordern. Ein RPO von unter einer Stunde ist schwieriger zu erreichen. Es wird nicht empfohlen, ohne zuvor die NetApp Professional Services einzuarbeiten, um sich mit den Anforderungen in Bezug auf Umgebung, Skalierung und Datensicherung vertraut zu machen.

Die RTO kann in der Regel in Sekunden gemessen werden. Eine Anwendung wird heruntergefahren, die Volumes wiederhergestellt und die Anwendung neu gestartet.

Am einfachsten legen Sie alle Dateien oder LUNs in einer einzelnen Volume-Konsistenzgruppe ab, wodurch die Erstellung von Snapshots direkt in ONTAP geplant werden kann. Wenn ein Datensatz über mehrere Volumes erstrecken muss, ist ein KonsistenzgruppenSnapshot (cg-Snapshot) erforderlich. Dies kann mit System Manager oder RESTful API-Aufrufen konfiguriert werden. Außerdem ist SnapCenter in der Lage, einen einfachen KonsistenzgruppenSnapshot auf einer definierten Liste von Volumes zu erstellen.

In diesem Abschnitt geht es um die Remote-Datensicherung, bei der Daten zum sicheren externen Storage und zur Disaster Recovery an einen Remote-Standort repliziert werden. Beachten Sie, dass diese Tabellen keine Datensicherung für die synchrone Spiegelung berücksichtigen. Informationen zu dieser Anforderung finden Sie in der NetApp MetroCluster-Dokumentation einschließlich "MetroCluster" und "SnapMirror Active Sync"

Das DR RPO wird durch die verfügbare Netzwerkbandbreite und die Gesamtgröße der zu sichernden Daten begrenzt. Nach der Erstellung des ersten Basistransfers basieren die Updates nur auf den geänderten Daten. Dies ist in der Regel ein geringer Prozentsatz des gesamten Datacenter-Platzbedarfs, obwohl es Ausnahmen gibt.

Beispielsweise weist eine 10-TB-Datenbank mit einer wöchentlichen Änderungsrate von 10 % im Schnitt eine Gesamtänderung von 6 GB pro Stunde auf. Mit 10 GB Konnektivität benötigt diese Datenbank etwa sechs Minuten für die Übertragung. Die Änderungsrate unterliegt Schwankungen der Änderungsrate der Datenbank, sollte jedoch insgesamt ein Update-Intervall von 15 Minuten und somit ein RPO von 15 Minuten erreichbar sein. Wenn es 100 solche Datenbanken gibt, dann sind 600 Minuten erforderlich, um die Daten zu übertragen. Daher ist ein RPO von einer Stunde nicht möglich. Ebenso kann ein Replikat einer einzelnen Datenbank mit einer Größe von 100 TB mit einer wöchentlichen Änderungsrate von 10 % nicht innerhalb einer Stunde zuverlässig aktualisiert werden.

Zusätzliche Faktoren können sich auf die Replikation auswirken, wie etwa der Overhead für die Replikation und Einschränkungen bei der Anzahl gleichzeitiger Replikationsvorgänge. Die Gesamtplanung einer Replikationsstrategie für ein einzelnes Volume kann jedoch auf der verfügbaren Bandbreite basieren, und ein Replikations-RPO von einer Stunde ist im Allgemeinen erreichbar. Ein RPO von unter einer Stunde ist schwieriger zu erreichen und sollte erst nach Rücksprache mit den NetApp Professional Services durchgeführt werden. In einigen Fällen sind 15 Minuten mit einer sehr guten Site-to-Site-Netzwerkverbindung möglich. Wenn jedoch insgesamt ein RPO von unter einer Stunde erforderlich ist, liefert die Architektur für die Wiedergabe mehrerer Volumes bessere Ergebnisse.

Das RTO mit Konsistenzgruppenreplikation in einem Disaster Recovery-Szenario ist ausgezeichnet, das aus Storage-Sicht in Sekunden gemessen wird. Der übersichtlichste Ansatz besteht darin, die Spiegelung zu zerbrechen und die Datenbank zu starten. Der Start der Datenbank dauert in der Regel ca. 10 Sekunden, aber sehr große Datenbanken mit vielen protokollierten Transaktionen können einige Minuten dauern.

Der wichtigere Faktor bei der Bestimmung der RTO ist nicht das Speichersystem, sondern die Anwendung und das Host-Betriebssystem, auf dem es ausgeführt wird. Die replizierten Daten können beispielsweise in ein oder zwei Sekunden verfügbar gemacht werden, aber dies stellt nur die Daten dar. Es muss auch ein korrekt konfiguriertes Betriebssystem mit Anwendungsbinärdateien vorhanden sein, um die Daten verwenden zu können.

In einigen Fällen haben Kunden Disaster-Recovery-Instanzen schon vor der Zeit vorbereitet, da der Speicher auf Betriebssystemen vorerkannt wurde. In diesen Fällen erfordert die Aktivierung des Disaster-Recovery-Szenarios nicht mehr als das Brechen einer Spiegelung und das Starten der Anwendung. In anderen Fällen können das Betriebssystem und die zugehörigen Applikationen neben der Datenbank als ESX Virtual Machine Disk (VMDK) gespiegelt werden. In diesen Fällen hängt der RPO davon ab, wie viel ein Kunde in die Automatisierung investiert hat, um die VMDK schnell zu booten und damit die Applikationen zu starten.

Die Aufbewahrungszeit wird zum Teil durch das Snapshot Limit gesteuert. Volumes in ONTAP haben beispielsweise eine Grenze von 1024 Snapshots. In einigen Fällen haben Kunden die Replikation multipliziert, um das Limit zu erhöhen. Wenn zum Beispiel 2000 Tage Backups erforderlich sind, kann eine Quelle auf zwei Volumes repliziert werden, wobei Aktualisierungen an alternativen Tagen stattfinden. Dies erfordert eine Erhöhung des anfänglichen Platzbedarfs, stellt aber dennoch einen wesentlich effizienteren Ansatz dar als ein herkömmliches Backup-System, bei dem mehrere vollständige Backups durchgeführt werden müssen.