Eine häufig gestellte Frage zur Verwendung von Snapshots als Datensicherungsstrategie ist die Tatsache, dass sich die „echten“ Daten und 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. Deshalb bietet NetApp Technologien wie SnapMirror und SnapVault-Replizierung, um Snapshots schnell und effizient auf einen unabhängigen Laufwerkssatz zu replizieren. 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.

Für die Sicherung Ihrer Daten gibt es viele Optionen für den Einsatz von ONTAP Snapshots. Snapshots bilden die Basis vieler anderer ONTAP Funktionen wie Replizierung, Disaster Recovery und Klonen. Eine vollständige Beschreibung der Snapshot-Technologie geht über den Umfang dieses Dokuments hinaus. Die folgenden Abschnitte bieten jedoch einen allgemeinen Überblick.

Es gibt zwei primäre Ansätze zum Erstellen eines Snapshots eines Datensatzes:

Ein absturzkonsistentes Backup eines Datensatzes bezieht sich auf die Erfassung der gesamten Datensatzstruktur zu einem bestimmten Zeitpunkt. Wenn der Datensatz in einem einzigen Volume gespeichert wird, ist der Vorgang einfach. Ein Snapshot kann jederzeit erstellt werden. Wenn ein Datensatz in mehreren Volumes gespeichert ist, muss ein Snapshot einer Konsistenzgruppe (CG) erstellt werden. Für das Erstellen von Snapshots von Konsistenzgruppen stehen verschiedene Optionen zur Verfügung, darunter NetApp SnapCenter-Software, native Funktionen von ONTAP-Konsistenzgruppen und vom Benutzer verwaltete Skripts.

Absturzkonsistente Backups kommen vor allem dann zum Einsatz, wenn die Recovery am Point-of-the-Backup ausreichend ist. Wenn ein granulareres Recovery erforderlich ist, sind in der Regel applikationskonsistente Backups erforderlich.

Das Wort „konsistent“ in „anwendungskonsistent“ ist oft eine Fehlbezeichnung. Das Platzieren einer Oracle-Datenbank in den Backup-Modus wird beispielsweise als applikationskonsistentes Backup bezeichnet, die Daten werden jedoch in keiner Weise konsistent oder stillgelegt. Die Daten ändern sich während des Backups weiterhin. Im Gegensatz dazu machen die meisten MySQL und Microsoft SQL Server Backups die Daten tatsächlich stillgelegt, bevor sie das Backup ausführen. VMware kann bestimmte Dateien konsistent machen oder auch nicht.

Der Begriff „Konsistenzgruppe“ bezieht sich auf die Fähigkeit eines Speicherarrays, mehrere Speicherressourcen als ein einziges Image zu verwalten. Beispielsweise kann eine Datenbank aus 10 LUNs bestehen. Das Array muss in der Lage sein, diese 10 LUNs konsistent zu sichern, wiederherzustellen und zu replizieren. Eine Wiederherstellung ist nicht möglich, wenn die Images der LUNs zum Zeitpunkt des Backups nicht konsistent waren. Die Replikation dieser 10 LUNs erfordert, dass alle Replikate perfekt miteinander synchronisiert sind.

ONTAP konnte schon immer konsistente lokale und replizierte Datenabbilder erstellen. Obwohl die verschiedenen Volumes auf einem ONTAP AFF/FAS-System üblicherweise nicht formal als Konsistenzgruppe bezeichnet werden, sind sie genau das. Ein Snapshot dieses Volumes ist ein Konsistenzgruppen-Abbild, die Wiederherstellung dieses Snapshots ist eine Konsistenzgruppen-Wiederherstellung, und sowohl SnapMirror als auch SnapVault bieten Konsistenzgruppen-Replikation.

AFF-Systeme umfassen auch einen umfassenderen Typ von Konsistenzgruppe. Mehrere Volumes können als eine Konsistenzgruppe (CG) innerhalb von ONTAP definiert werden. Snapshots, Klone und Replikation lassen sich dann auf CG-Ebene konfigurieren. Dies vereinfacht Datenschutzstrategien, da Richtlinien für Datensätze und nicht nur für einzelne Volumes oder LUNs festgelegt werden können. Auch in ASA-Systemen existieren Konsistenzgruppen (CGs). Mehrere LUNs oder Namespaces können zu einer Konsistenzgruppe (CG) zusammengefasst werden, und diese CG kann dann durch Snapshots geschützt, repliziert, wiederhergestellt oder geklont werden.

Consistency group (CG)-Snapshots sind eine Erweiterung der grundlegenden ONTAP Snapshot Technologie. Ein Standard-Snapshot-Vorgang erstellt ein konsistentes Abbild aller Daten innerhalb eines einzelnen AFF/FAS-Volumes oder ASA LUN/Namespace, aber manchmal ist es notwendig, einen konsistenten Satz von Snapshots über mehrere Speicherressourcen und sogar über mehrere Speichersysteme hinweg zu erstellen. Das Ergebnis ist ein Satz von Snapshots, der auf die gleiche Weise verwendet werden kann wie ein Snapshot eines einzelnen Volumes. Sie können für die lokale Datenwiederherstellung verwendet, für Zwecke der Notfallwiederherstellung repliziert oder als eine einzige konsistente Einheit geklont werden.

CG-Snapshots skalieren hervorragend. Der größte bekannte Einsatz eines CG-Snapshots betrifft eine Datenbankumgebung mit ca. 1PB Größe, die sich über 12 Controller erstreckt. Die auf diesem System erstellten CG-Snapshots wurden für Backup, Recovery und Klonen verwendet.

Meistens kann, wenn sich ein Datensatz über AFF Volumes oder ASA LUNs/Namespaces erstreckt und die Schreibreihenfolge erhalten bleiben muss, einfach eine ONTAP Konsistenzgruppe definiert werden, und die Gruppe von Volumes, LUNs oder Namespaces kann nativ verwaltet werden, um Snapshots zu erstellen. Wenn Management-Software verwendet wird, sollte sie den Bedarf an Konsistenzgruppen-Snapshots erkennen und die erforderlichen APIs aufrufen.

In solchen Fällen ist es nicht notwendig, die technischen Details von CG snapshot zu verstehen. Es gibt jedoch Situationen, in denen komplexe Anforderungen an den Datenschutz eine detaillierte Kontrolle über den Datenschutz- und Replikationsprozess erfordern. Automatisierungs-Workflows oder die Verwendung benutzerdefinierter Skripte zum Aufrufen der CG snapshot APIs sind einige der Optionen. Das Verständnis der besten Option und der Rolle von CG snapshots erfordert eine detailliertere Erklärung der Technologie.

Die Erstellung eines Satzes von Konsistenzgruppen-Snapshots ist ein zweistufiger Prozess:

Die Schreibsperre wird sequenziell eingerichtet. Das bedeutet, dass während der Einrichtung der Sperre über mehrere Speicherziele hinweg die Schreib-E/A für das erste Objekt in der Sequenz eingefroren wird, während sie weiterhin für Ziele eingefroren bleibt, die später in der Liste erscheinen. Dies mag zunächst den Anschein erwecken, als verletze es die Anforderung, die Schreibreihenfolge beizubehalten, aber dies gilt nur für E/A, die asynchron auf dem Host ausgeführt werden und nicht von anderen Schreibvorgängen abhängen.

Beispielsweise kann eine Datenbank eine Vielzahl asynchroner Datendatei-Updates ausgeben und dem Betriebssystem ermöglichen, die I/O-Vorgänge neu zu ordnen und sie gemäß seiner eigenen Scheduler-Konfiguration abzuschließen. Die Reihenfolge dieser E/A-Typen kann nicht garantiert werden, da die Anwendung und das Betriebssystem bereits die Anforderung zur Wahrung der Schreibreihenfolge freigegeben haben.

Als Gegenbeispiel ist der Großteil der Datenbank-Protokollierung synchron. Die Datenbank führt keine weiteren Protokollschreibvorgänge durch, bis die E/A bestätigt wurde, und die Reihenfolge dieser Schreibvorgänge muss erhalten bleiben. Trifft eine Protokoll-E/A auf einem geschützten LUN ein, wird sie nicht bestätigt und die Anwendung blockiert weitere Schreibvorgänge. Ebenso ist die Metadaten-E/A des Dateisystems üblicherweise synchron. Beispielsweise darf ein Löschvorgang nicht verloren gehen. Wenn ein Betriebssystem mit einem xfs-Dateisystem eine Datei löscht und die E/A, die die xfs-Dateisystem-Metadaten aktualisiert, um den Verweis auf diese Datei zu entfernen, auf einem geschützten LUN landet, wird die Dateisystemaktivität angehalten. Dies gewährleistet die Integrität des Dateisystems während CG-Operationen.

Nachdem die Schreibsperre für die Ziele eingerichtet wurde, sind sie bereit für die Snapshot-Erstellung. Die Snapshots müssen nicht exakt gleichzeitig erstellt werden, da der Zustand der Ziele aus Sicht abhängiger Schreibvorgänge eingefroren ist. Um gegen einen Fehler in der Anwendung, die die Konsistenzgruppen-Snapshots erstellt, zu schützen, beinhaltet die anfängliche Schreibsperre eine konfigurierbare Zeitüberschreitung, bei der ONTAP die Sperre nach einer definierten Anzahl von Sekunden automatisch aufhebt und die Schreibverarbeitung fortsetzt. Werden alle Snapshots vor Ablauf der Zeitüberschreitung erstellt, bilden die resultierenden Snapshots eine gültige Konsistenzgruppe.

Es gibt zwei primäre Ansätze bei Snapshot-basierten Backups:

Ein absturzkonsistenter Backup einer Datenbank bezieht sich auf die Erfassung der gesamten Datenbankstruktur, einschließlich Datenbankdateien, Wiederherstellungsprotokollen und Steuerdateien, zu einem einzigen, zeitpunktgenauen Zeitpunkt. Wenn die Datenbank in einem einzelnen Volume, einer LUN oder einem Namespace gespeichert ist, ist der Vorgang einfach; ein Snapshot kann jederzeit erstellt werden. Wenn eine Datenbank sich über AFF Volumes oder ASA LUNs/Namespaces erstreckt, muss ein Konsistenzgruppen-(CG-)Snapshot erstellt werden. Für die Erstellung von CG-Snapshots gibt es mehrere Optionen, darunter NetApp SnapCenter software, native ONTAP Konsistenzgruppenfunktionen und benutzerverwaltete Skripte.

Absturzkonsistente Snapshot-Backups werden hauptsächlich dann eingesetzt, wenn eine zeitpunktgenaue Wiederherstellung zum Zeitpunkt des Backups ausreicht. Archivprotokolle können unter bestimmten Umständen verwendet werden, aber wenn eine granularere zeitpunktgenaue Wiederherstellung erforderlich ist, ist ein Online-Backup vorzuziehen.

Das grundlegende Verfahren für ein Snapshot-basiertes Online-Backup ist wie folgt:

Dieses Verfahren ergibt einen Satz von Snapshots, die Datendateien im Backup-Modus enthalten, und die kritischen Archivprotokolle, die im Backup-Modus generiert wurden. Dies sind die beiden Anforderungen für das Recovery einer Datenbank. Dateien wie Kontrolldateien sollten ebenfalls aus Gründen der Bequemlichkeit geschützt werden, aber die einzige absolute Anforderung ist die Sicherung von Datendateien und Archivprotokollen.

Auch wenn unterschiedliche Kunden möglicherweise sehr unterschiedliche Strategien verfolgen, basieren fast alle diese Strategien letztendlich auf den unten erläuterten Prinzipien.

Bei der Entwicklung von Storage-Layouts für Oracle-Datenbanken ist die erste Entscheidung, ob die volumenbasierte NetApp SnapRestore (VBSR) Technologie verwendet werden soll, die die zugrunde liegende Technologie für die Wiederherstellung von AFF Volumes und ASA LUNs/Namespaces ist.

VBSR ermöglicht die nahezu sofortige Wiederherstellung von Daten auf einen früheren Zeitpunkt. Da alle Daten auf dem wiederhergestellten Datenträger verloren gehen, ist VBSR möglicherweise nicht für alle Anwendungsfälle geeignet. Wenn beispielsweise eine gesamte Datenbank, einschließlich Datenbankdateien, Wiederherstellungsprotokollen und Archivprotokollen, auf einem einzelnen AFF Volume gespeichert ist und dieses Volume mit VBSR wiederhergestellt wird, gehen Daten verloren, da die neueren Archivprotokolle und Wiederherstellungsprotokolldaten verworfen werden. Dasselbe gilt für ASA Daten. Wenn die gesamte Datenbank in einer einzelnen ASA Konsistenzgruppe gespeichert war und diese Konsistenzgruppe auf einen früheren Zustand wiederhergestellt wurde, gehen einige der späteren Archivprotokolle und Wiederherstellungsprotokolldaten verloren.

VBSR ist für die Wiederherstellung nicht erforderlich. Viele Datenbanken können mithilfe der dateibasierten Einzeldatei SnapRestore (Einzeldatei SnapRestore) oder durch einfaches Klonen von Dateien aus dem Snapshot zurück in das aktive Dateisystem wiederhergestellt werden.

VBSR ist die bevorzugte Methode, wenn eine Datenbank sehr groß ist oder so schnell wie möglich wiederhergestellt werden muss, und die Verwendung von VBSR erfordert die Isolation der Datendateien. In einer NFS-Umgebung müssen die Datendateien einer bestimmten Datenbank in dedizierten Volumes gespeichert werden, die nicht durch andere Dateitypen verunreinigt sind. In einer SAN-Umgebung müssen Datendateien in dedizierten LUNs oder Namespaces gespeichert werden. Wird ein Volume-Manager verwendet (einschließlich Oracle Automatic Storage Management [ASM]), muss die Festplattengruppe ebenfalls ausschließlich für Datendateien reserviert sein.

Durch die Isolierung von Datendateien auf diese Weise können diese in einen früheren Zustand zurückversetzt werden, ohne andere Dateisysteme zu beschädigen.

Für jedes Volume mit Oracle-Daten in einer AFF SAN-Umgebung sollte der percent-snapshot-space auf Null gesetzt werden, da die Reservierung von Speicherplatz für einen Snapshot in einer LUN-Umgebung nicht sinnvoll ist. Wenn die anteilige Reserve auf 100 gesetzt ist, benötigt ein Snapshot eines Volumes mit LUNs genügend freien Speicherplatz im Volume, ohne die Snapshot-Reserve, um einen 100%igen Austausch aller Daten aufzunehmen. Wenn die anteilige Reserve auf einen niedrigeren Wert gesetzt ist, wird entsprechend weniger freier Speicherplatz benötigt, aber die Snapshot-Reserve wird immer ausgeschlossen. Das bedeutet, dass der Speicherplatz für die Snapshot-Reserve in einer LUN-Umgebung verschwendet wird.

In einer NFS-Umgebung gibt es zwei Optionen:

Mit der ersten Option percent-snapshot-space Wird auf einen Wert ungleich Null gesetzt, normalerweise etwa 20 %. Dieser Raum wird dann vor dem Benutzer ausgeblendet. Dieser Wert schafft jedoch keine Begrenzung der Auslastung. Wenn bei einer Datenbank mit einer Reservierung von 20 % 30 % anfällt, kann der Snapshot-Platz über die Grenze der 20-prozentigen Reserve hinauswachsen und nicht reservierten Speicherplatz belegen.

Der Hauptvorteil, wenn Sie eine Reserve auf einen Wert wie 20% setzen, besteht darin zu überprüfen, ob etwas Speicherplatz für Snapshots immer verfügbar ist. Bei einem 1-TB-Volume mit einer Reserve von 20 % wäre es beispielsweise nur einem Datenbankadministrator (DBA) möglich, 800 GB an Daten zu speichern. Diese Konfiguration garantiert mindestens 200 GB Speicherplatz für den Snapshot-Verbrauch.

Wenn percent-snapshot-space Ist auf null festgelegt, sodass der gesamte Speicherplatz im Volume für den Endbenutzer verfügbar ist, sodass bessere Sichtbarkeit gewährleistet wird. Ein DBA muss verstehen, dass ein 1-TB-Volume, das Snapshots nutzt, 1 TB Speicherplatz zwischen aktiven Daten und dem Snapshot-Umsatz gemeinsam genutzt wird.

Es gibt keine klare Präferenz zwischen Option 1 und Option 2 unter den Endbenutzern.

Oracle Doc ID 604683.1 erläutert die Anforderungen für die Snapshot-Unterstützung von Drittanbietern und die verschiedenen verfügbaren Optionen für Backup- und Wiederherstellungsvorgänge.

Der Drittanbieter muss sicherstellen, dass die Snapshots des Unternehmens den folgenden Anforderungen entsprechen:

Die Oracle Managementprodukte von ONTAP und NetApp erfüllen diese Anforderungen.