Die folgende Abbildung zeigt die logische Sicht der Kommunikation zwischen dem SnapCenter -Server, der SAP HANA-Datenbank und dem Speichersystem. Der SnapCenter -Server nutzt die HANA- und Linux-Plug-ins zur Kommunikation mit der HANA-Datenbank und den Linux-Betriebssystemen.

Die empfohlene und standardmäßige Bereitstellungsoption für die SnapCenter -Plug-ins ist die Installation auf dem HANA-Datenbankhost. Bei dieser Bereitstellungsoption sind alle im Kapitel „Von SnapCenter unterstützte Konfigurationen“ beschriebenen Konfigurationen und Funktionen gültig. Es gibt einige Ausnahmen, bei denen die SnapCenter -Plug-ins nicht auf dem HANA-Datenbankhost installiert werden können, sondern auf einem zentralen Plug-in-Host konfiguriert werden müssen, bei dem es sich beispielsweise um den SnapCenter -Server selbst handeln kann. Für HANA-Mehrhostsysteme oder HANA-Systeme, die auf der IBM Power-Plattform laufen, ist ein zentraler Plug-in-Host erforderlich. Beide Bereitstellungsoptionen können auch kombiniert werden, z. B. durch die Verwendung des SnapCenter -Servers als zentralen Plug-in-Host für ein System mit mehreren Hosts und die Bereitstellung der Plug-ins auf den HANA-Datenbankhosts für alle anderen HANA-Systeme mit einem einzelnen Host.

In SnapCenter kann eine HANA-Ressource entweder automatisch erkannt oder manuell konfiguriert werden. Ein HANA-System wird standardmäßig automatisch erkannt, sobald die HANA- und Linux-Plug-ins auf dem Datenbankhost bereitgestellt sind. Die automatische Erkennung SnapCenter unterstützt keine mehreren HANA-Installationen auf demselben Host. HANA-Systeme, die über einen zentralen Plug-in-Host verwaltet werden, müssen in SnapCenter manuell konfiguriert werden. Auch Nicht-Datenvolumes sind standardmäßig manuell konfigurierte Ressourcen.

SnapCenter unterstützt zwar die zentrale Bereitstellung von Plug-ins für HANA-Systeme, es gibt jedoch Einschränkungen hinsichtlich Plattform- und Funktionsunterstützung. Die folgenden Infrastrukturkonfigurationen und -vorgänge werden für HANA-Systeme, die mit einem zentralen Plug-in-Host konfiguriert sind, nicht unterstützt:

SAP empfiehlt, regelmäßige HANA-Blockkonsistenzprüfungen in die gesamte Backup-Strategie aufzunehmen. Bei herkömmlichen dateibasierten Backups wird diese Prüfung bei jedem Backup-Vorgang durchgeführt. Bei Snapshot-Backups muss zusätzlich zu den Snapshot-Backup-Operationen auch die Konsistenzprüfung durchgeführt werden, zum Beispiel einmal pro Woche.

Technisch gesehen gibt es zwei Möglichkeiten, die Blockkonsistenzprüfung durchzuführen.

Das HANA-Tool hdbpersdiag ist Bestandteil der HANA-Installation und ermöglicht die Durchführung von Blockkonsistenzprüfungen an einer Offline-HANA-Datenbank. Daher eignet es sich perfekt für die Verwendung in Kombination mit Snapshot-Backups, bei denen vorhandene Snapshot-Backups hdbpersdiag präsentiert werden können.

Beim Vergleich der beiden Ansätze bietet hdbpersdiag deutliche Vorteile gegenüber der dateibasierten Sicherung für HANA-Blockkonsistenzprüfungen. Eine Dimension ist die benötigte Speicherkapazität. Bei dateibasierten Backups muss mindestens die Größe eines Backups für jedes HANA-System verfügbar sein. Wenn Sie beispielsweise 15 HANA-Systeme mit einer Persistenzgröße von 3 TB haben, benötigen Sie zusätzlich 45 TB allein für die Konsistenzprüfungen. Für hdbpersdiag wird keine zusätzliche Speicherkapazität benötigt, da der Vorgang auf einem vorhandenen Snapshot-Backup oder einem FlexClone eines vorhandenen Snapshot-Backups ausgeführt wird. Die zweite Dimension ist die CPU-Auslastung des HANA-Hosts während der Konsistenzprüfung. Eine dateibasierte Datensicherung benötigt CPU-Zyklen auf dem HANA-Datenbankhost, während die hdbpersdiag-Verarbeitung vollständig vom HANA-Host ausgelagert werden kann, wenn sie in Kombination mit einem zentralen Verifizierungshost verwendet wird. Die wichtigsten Merkmale sind in der folgenden Tabelle zusammengefasst.

NetApp empfiehlt die Verwendung von hdbpersdiag zur Durchführung von HANA-Blockkonsistenzprüfungen. Weitere Einzelheiten zur Umsetzung finden sich in Kapitel "Blockkonsistenzprüfungen mit SnapCenter"Die

Vor der Konfiguration von SnapCenter und dem SAP HANA Plug-in muss die Datensicherungsstrategie auf Grundlage der RTO- und RPO-Anforderungen der verschiedenen SAP Systeme definiert werden.

Ein gemeinsamer Ansatz besteht in der Definition von Systemtypen wie Systemen für Produktion, Entwicklung, Test oder Sandbox. Alle SAP-Systeme des gleichen Systemtyps haben typischerweise die gleichen Datenschutzparameter.

Folgende Parameter müssen definiert werden:

Die folgende Tabelle zeigt ein Beispiel für Datenschutzparameter für die Systemtypen Produktion, Entwicklung und Test. Für das Produktionssystem wurde eine hohe Backup-Frequenz festgelegt, und die Backups werden einmal täglich auf einen sekundären Backup-Standort repliziert. Die Testsysteme haben geringere Anforderungen und es findet keine Replikation der Backups statt.

Die folgende Tabelle zeigt die Richtlinien und Zeitpläne, die für die oben genannten Datenschutzparameter konfiguriert werden müssten.

Die folgende Abbildung fasst die Zeitpläne und die Aufbewahrungsfristen der Backups zusammen. Wird SnapCenter zur Verwaltung der Aufbewahrung von Protokollsicherungen verwendet, werden alle Protokollsicherungen gelöscht, die älter als die älteste Snapshot-Sicherung sind. Mit anderen Worten: Protokollsicherungen werden so lange aufbewahrt, wie es erforderlich ist, um für jede verfügbare Sicherung eine zeitgerechte Wiederherstellung auf den aktuellen Stand zu ermöglichen.

Bei Verwendung der HANA-Persistenzverschlüsselung ist es unerlässlich, zusätzlich zu den Standard-Datensicherungen auch Sicherungskopien der Stammschlüssel zu erstellen. Zur Wiederherstellung der HANA-Datenbank im Falle eines Datenverlusts und des Verlusts des HANA-Installationsdateisystems werden Root-Key-Backups benötigt. Weitere Informationen finden Sie unter "SAP HANA Administration Guide"Die

SnapCenter unterstützt Snapshot-Backup-Operationen von HANA MDC-Systemen mit einem oder mehreren Mandanten. SnapCenter unterstützt außerdem zwei verschiedene Wiederherstellungsvorgänge eines HANA MDC-Systems. Sie können entweder das gesamte System, die Systemdatenbank und alle Mandanten wiederherstellen oder nur einen Mandanten. Es gibt einige Voraussetzungen, damit SnapCenter diese Operationen ausführen kann.

In einem MDC-System ist die Mandantenkonfiguration nicht unbedingt statisch. Mieter können hinzugefügt oder gelöscht werden. SnapCenter kann sich nicht auf die Konfiguration verlassen, die beim Hinzufügen der HANA-Datenbank zu SnapCenter ermittelt wird. Um eine Wiederherstellung für einen einzelnen Mandanten zu ermöglichen, muss SnapCenter wissen, welche Mandanten in den einzelnen Snapshot-Backups enthalten sind. Darüber hinaus muss es wissen, welche Dateien und Verzeichnisse zu jedem Mandanten gehören, der in der Snapshot-Sicherung enthalten ist.

Daher ermittelt SnapCenter bei jedem Backup-Vorgang die Mandanteninformationen. Dies umfasst die Mandantennamen und die entsprechenden Datei- und Verzeichnisinformationen. Diese Daten müssen in den Snapshot-Backup-Metadaten gespeichert werden, um eine Wiederherstellung durch einen einzelnen Mandanten zu ermöglichen.

Ein weiterer Schritt der automatischen Anwendungserkennung ist die Erkennung des primären oder sekundären Knotens der HANA-Systemreplikation (HSR). Wenn ein HANA-System mit HSR konfiguriert ist, muss SnapCenter bei jedem Sicherungsvorgang den primären Knoten identifizieren, damit die Backup-SQL-Befehle auf dem primären HSR-Knoten ausgeführt werden. Siehe auch "SAP HANA System Replication – Backup und Recovery mit SnapCenter"Die

SnapCenter erkennt außerdem die HANA-Datenvolumenkonfiguration und ordnet sie Dateisystem- und Speicherressourcen zu. Mit diesem Ansatz kann SnapCenter Änderungen an der HANA-Volume-Konfiguration verarbeiten, z. B. mehrere Partitionen oder Änderungen an der Speicherkonfiguration wie die Migration von Volumes.

Der nächste Schritt ist die eigentliche Snapshot-Sicherungsoperation. Dieser Schritt umfasst den SQL-Befehl zum Auslösen des HANA-Datenbank-Snapshots, die Sicherung des Speicher-Snapshots und den SQL-Befehl zum Beenden des HANA-Snapshot-Vorgangs. Durch die Verwendung des Befehls „close“ aktualisiert die HANA-Datenbank den Sicherungskatalog der Systemdatenbank und jedes Mandanten.

Für das Aufbewahrungsmanagement von Daten-Backups und das HANA-Backup-Katalogmanagement muss SnapCenter die Kataloglösch-Operationen für die Systemdatenbank und alle Mandantendatenbanken ausführen, die im ersten Schritt identifiziert wurden. Auf dieselbe Weise für die Log-Backups muss der SnapCenter-Workflow auf jedem Mandanten laufen, der Teil des Backup-Vorgangs war.

Die folgende Abbildung zeigt einen Überblick über den Backup-Workflow.

Das Management der Daten-Backup-Aufbewahrung und die allgemeine Ordnung der Backup-Protokollierung können in fünf Hauptbereiche unterteilt werden, einschließlich Aufbewahrungsmanagement von:

Die folgende Abbildung bietet einen Überblick über die verschiedenen Workflows und die Abhängigkeiten jedes einzelnen Vorgangs. In den folgenden Abschnitten werden die verschiedenen Operationen im Detail beschrieben.