Häufig gestellte Fragen: Sichern von SAP HANA-Datenbanken auf virtuellen Azure-Computern

Sie können eine vollständige Sicherung und mehrere bedarfsgesteuerte Sicherungen pro Tag planen.

Erfolgreiche Sicherungsaufträge generieren heute keine Warnungen. Warnungen werden nur für Sicherungsaufträge generiert, bei denen ein Fehler aufgetreten ist. Erfahren Sie, wie Sie das Azure-Portal verwenden, um Azure Backup-Warnungen anzuzeigen.

Sie können den Status Ihrer Sicherungen (geplant oder bei Bedarf) an den folgenden Stellen überprüfen:

1. Sicherungsaufträge: Azure Backup zeigt alle manuell ausgelösten Aufträge im Azure-Portal im Abschnitt „Sicherungsaufträge“ an.
   
   Zu den Aufträgen, die im Azure-Portal angezeigt werden, gehören Datenbankermittlungs- und -registrierungsvorgänge sowie Sicherungs- und Wiederherstellungsvorgänge. Geplante Aufträge (einschließlich Protokollsicherungen) werden in diesem Abschnitt nicht angezeigt. Manuell ausgelöste Sicherungen über die nativen SAP HANA-Clients (Studio/Cockpit/DBA Cockpit) werden hier ebenfalls nicht angezeigt.

   

   

2. Sicherungswarnungen: Warnungen unterstützen Sie beim Überwachen von Sicherungen von SAP HANA-Datenbanken. Sie helfen Ihnen dabei, sich auf die erforderlichen Ereignisse zu konzentrieren, sodass Sie nicht mehr ständig die vielen Ereignisse überprüfen müssen, die beim Erstellen einer Sicherung generiert werden. Weitere Informationen finden Sie unter Anzeigen von Sicherungswarnungen.

3. Sicherungsberichte: Berichte sind eine weitere Möglichkeit, den Status Ihrer Sicherungsaufträge einzusehen. Diese Berichte sehen wie folgt aus:

   

   

   Weitere Informationen finden Sie unter Konfigurieren von Azure Backup-Berichten.

4. Native SAP HANA-Clients: Wenn Sie SAP HANA nutzen, können Sie auch HANA Studio verwenden, einen der gängigsten HANA-Clients. Navigieren Sie in diesem Client zu Backup Console ->Backup Catalog (Sicherungskonsole -> Sicherungskatalog), um den Sicherungsstatus anzuzeigen.

   

Im Menü „Sicherungsauftrag“ werden nur bedarfsgesteuerte Sicherungsaufträge angezeigt, die entweder in Bearbeitung, erfolgreich oder fehlgeschlagen sind. Verwenden Sie für geplante Aufträge Azure Monitor.

Azure Backup gibt keinen expliziten Aufbewahrungszeitraum für vollständige Sicherungen für eine automatische Reparatur vor. Diese Sicherung wird so lang aufbewahrt, wie Sie auch die abhängigen Deltasicherungen (differenziellen oder inkrementellen Sicherungen) und Protokollsicherungen aufbewahren. Wenn Sie die letzte abhängige Sicherung für diese Sicherung für eine automatische Reparatur gelöscht haben, wird die Sicherung für eine automatische Reparatur ebenfalls gelöscht.

Ja, eine vollständige Sicherung und eine Protokollsicherung können gleichzeitig ausgeführt werden. Dieser Fall tritt auf eine der folgenden Arten auf:

• Eine vollständige Sicherung wird gerade ausgeführt, und eine Protokollsicherung wird ausgelöst: Die Protokollsicherung sollte unabhängig von einer laufenden vollständigen Sicherung erfolgreich ausgeführt werden. Es sei denn, die ausgelöste vollständige Sicherung diente als Abhilfemaßnahme, um eine Unterbrechung der LSN-Kette zu beheben.
• Eine Protokollsicherung wird gerade ausgeführt, und eine vollständige Sicherung wird ausgelöst: Beide Sicherungen sollten gleichzeitig ausgeführt werden und erfolgreich sein.

Nein. Dies wird derzeit nicht unterstützt.

Wenn eine Datenbank aus einer SAP HANA-Instanz gelöscht wird, wird weiterhin versucht, Sicherungen der Datenbank durchzuführen. Dies bedeutet auch, dass die gelöschte Datenbank unter Sicherungselemente als fehlerhaft angezeigt wird und weiterhin geschützt ist. Die richtige Vorgehensweise zum Beenden des Schutzes dieser Datenbank besteht darin, hierfür die Option zum Beenden der Sicherung bei gelöschten Daten zu verwenden.

Eine umbenannte Datenbank wird wie eine neue Datenbank behandelt. Diese Situation wird daher vom Dienst so behandelt, als wäre die Datenbank nicht gefunden worden, und für die Sicherungen tritt ein Fehler auf. Die umbenannte Datenbank wird als neue Datenbank angezeigt und muss für Schutz konfiguriert werden.

Im Tutorial finden Sie eine Schritt-für-Schritt-Anleitung für den Einstieg in Azure Backup für SAP HANA-Datenbanken. Sie können auch die Befehlszeilenschnittstelle (CLI) verwenden, um Sicherungen zu konfigurieren und zu verwalten.

Lesen Sie die Voraussetzungen für die Verwendung von Azure Backup mit SAP HANA.

Weitere Informationen finden Sie in diesem Abschnitt des Leitfadens zur Problembehandlung.

Weitere Informationen finden Sie in diesem Abschnitt des Leitfadens zur Problembehandlung.

Derzeit besteht keine Möglichkeit, die Lösung nur für eine virtuelle IP-Adresse oder einen Proxy einzurichten. Es wird ein virtueller Computer zum Ausführen der Lösung benötigt.

Sie können eine bedarfsgesteuerte Sicherung mithilfe nativer SAP HANA-Clients im lokalen Dateisystem anstelle von Backint auslösen. Erfahren Sie mehr darüber, wie Sie Vorgänge mit nativen SAP-Clients verwalten.

Sie können den HANA-Katalog mit empfohlenen SAP-Methoden wie BACKUP CATALOG DELETE-Anweisungen oder HANA Studio/Cockpit löschen. Erfahren Sie mehr darüber, wie Sie Vorgänge mit nativen SAP-Clients verwalten.

1. Bei HANA System Replication (HSR) akzeptiert der sekundäre Knoten überhaupt keine Verbindungen. Sobald die Sicherung konfiguriert ist, pingt der Azure Backup-Dienst regelmäßig, wobei ein Fehler auftritt. Manchmal spiegeln sich diese Fehlversuche auf dem primären Knoten wider. Nach mehreren Fehlern wird der Benutzer bzw. die Benutzerin gesperrt, und beim primären Knoten beginnt der Fehler ODBCConnectionError aufzutreten.
   
   Wir haben festgestellt, dass dieses Problem nicht bei allen Benutzer*innen auftritt. Es wird empfohlen, dass Sie oder SAP die Ursache dafür untersuchen bzw. untersucht, dass Benutzer*innen auf dem primären Knoten gesperrt werden, wenn bei der Benutzerverbindung auf dem sekundären Knoten ein Fehler auftritt.

2. Wenn Sie das Vorregistrierungsskript ausführen, werden die Benutzerinformationen mit dem neuen Kennwort auf dem primären Knoten aktualisiert. Anschließend wird die Verbindung wiederhergestellt, und es wird versucht, eine Sicherung zu erstellen. Es kann jedoch sein, dass dasselbe Szenario noch mal eintritt.

3. Darüber hinaus werden bei den Sicherungen (vollständigen Sicherungen), bei denen auf dem sekundären Knoten Fehler auftreten, Warnungen generiert.

Zur Vermeidung der oben erläuterten Probleme empfiehlt es sich, den Schutz für einen Knoten zu beenden, sobald er zu einem sekundären Knoten wird, (damit nicht versucht wird, Verbindungen herzustellen, und Benutzer*innen nicht gesperrt werden) und den Schutz wieder zu aktivieren, sobald der Knoten zu einem primären Knoten wird. Wenn diese Sperrsituation bei HSR-Setups bei Ihnen nicht eintritt und die ausgelösten Warnungen Sie nicht stören, können Sie Sicherungen für beide Knoten einrichten, sodass der Dienst sich um Übernahme und Failback kümmert.

Sehen Sie sich die Informationen im verlinkten Abschnitt zur Durchsatzleistung bei Sicherungen und Wiederherstellungen an, die Azure Backup für HANA-Workloads bietet.

Verwenden Sie die folgenden Ressourcen, um Ihr HANA-System so einzurichten, dass es die verbesserte Leistung nutzt:

• Auswählen eines Datenträgertyps für virtuelle Azure IaaS-Computer: verwaltete Datenträger
• Leistungsstufen für Azure Managed Disks
• M-Serie
• SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer

Derzeit akzeptiert Azure Backup für SAP HANA 1 als Wert für die Eigenschaft parallel_backup_using_backint. Azure Backup teilt diesen einzelnen Stream jedoch in mehrere Datenströme auf, um die Leistung zu verbessern.

Derzeit werden nur Backint-Basissicherungen für HSR unterstützt. Momentaufnahmen werden noch nicht unterstützt.

Sie müssen die erneute Erkennung der Instanz auf dem Server ausführen, der die Kennzeichnung „Nicht bereit“ hat, um den Status zu aktualisieren.

Während des Sicherungsvorgangs stellt der Sicherungsauftrag eine Verbindung mit drei Dienstendpunkten her: AzureBackup, AzureStorage und Microsoft Entra ID. In this scenario, we recommend you to configure the Service Endpoint to AzureStorage. Dadurch kann der Datenverkehr direkt aus dem virtuellen Netzwerk an den Speicher gesendet werden. Für Azure Backup und Microsoft Entra ID können Sie UDR über Diensttags konfigurieren, sodass der Datenverkehr an das Backbone-Netzwerk und nicht an das lokale Netzwerk gesendet wird.

Der Recovery Services-Tresor zeigt alle Knoten, die Teil der SAP HANA-Systemreplikation sind. Alle Knoten werden hier gemäß der Ausgabe hdbnsutil aufgelistet. Gemäß dem erwarteten Verhalten wird jedoch nur der konfigurierte Knoten in diesem Tresor registriert.

Wenn Sie den Sicherungsauftrag über den Backint-Agenten hdbbackint auslösen, werden Informationen in das Verzeichnis /var/tmp geschrieben. Wenn beispielsweise während des Sicherungsvorgangs ein Fehler auftritt, wird die Fehlermeldung in eine Datei im Verzeichnis /var/tmp geschrieben. Der Dateiname wird im Format hdbbackint_<SID>.<random_string> erstellt, wobei <SID> die System-ID der SAP-HANA-Instanz ist und <random_string> eine zufällig generierte Zeichenfolge.

Der Sicherungsprozess wird nicht beeinträchtigt, wenn Sie die Datei „hdbbackint“ im Verzeichnis „/var/tmp“ löschen. Es werden jedoch möglicherweise alle Fehlermeldungen entfernt, die während des Sicherungsvorgangs in die Datei geschrieben wurden.

Sie können maximal 10 Wiederherstellungen pro HANA-System oder -Instanz an einem Tag ausführen. Beachten Sie, dass eine Wiederherstellung auch als Wiederherstellungsversuch angesehen wird, wenn sie abgebrochen wird oder fehlschlägt.

Überprüfen Sie, ob alle Voraussetzungen für die Wiederherstellung in der SAP HANA-Zielinstanz erfüllt sind. Weitere Informationen finden Sie unter Voraussetzungen: Wiederherstellen von SAP HANA-Datenbanken in einer Azure-VM.

Stellen Sie sicher, dass die Option Überschreiben erzwingen beim Wiederherstellen ausgewählt ist.

Lesen Sie den SAP HANA-Hinweis 1642148, um zu ermitteln, welche Wiederherstellungstypen derzeit unterstützt werden.

Ja. Sie können Streamingsicherungen, die auf einer auf SLES laufenden HANA-Datenbank ausgelöst wurden, verwenden, um sie auf einem RHEL HANA-System wiederherzustellen (und umgekehrt). Das heißt, dass die betriebssystemübergreifende Wiederherstellung mithilfe von Streamingsicherungen möglich ist. Sie müssen aber sicherstellen, dass sowohl das HANA-System, auf dem Sie die Wiederherstellung durchführen möchten, als auch das HANA-System, das für die Wiederherstellung verwendet wird, gemäß SAP für die Wiederherstellung kompatibel sind. Lesen Sie SAP HANA-Hinweis 1642148, um zu erfahren, welche Wiederherstellungstypen kompatibel sind.

Ja, Sie können Dateien teilweise wie hier dokumentiert herunterladen.

Ja, Sie müssen die HANA-Systemreplikation (HSR) auf dem Zielsystem deaktivieren und dann die Wiederherstellung durchführen. Sie können ein HSR-fähiges System laut SAP nicht wiederherstellen.

Bevor Sie eine Richtlinie erstellen, sollten Sie sich mit den Anforderungen in puncto RPO und RTO sowie mit den entsprechenden Auswirkungen auf die Kosten auseinandersetzen.

RPO (Recovery Point Objective) gibt den akzeptablen Datenverlust für den Benutzer/Kunden an. Dies wird durch das Protokollsicherungsintervall bestimmt. Häufigere Protokollsicherungen bedeuten einen niedrigeren RPO-Wert. Der kleinste vom Azure Backup-Dienst unterstützte Wert beträgt 15 Minuten. Das Protokollsicherungsintervall kann also 15 Minuten oder mehr betragen.

RTO (Recovery Time Objective) gibt an, wie schnell die Daten nach einem Datenverlust auf den letzten verfügbaren Zeitpunkt wiederhergestellt werden sollen. Dies hängt davon ab, welche Wiederherstellungsstrategie von HANA genutzt wird (was wiederum mit der Anzahl der für die Wiederherstellung erforderlichen Dateien zusammenhängt). Dadurch ergeben sich auch Auswirkungen auf die Kosten. Die folgende Tabelle gibt einen besseren Überblick über alle Szenarien und deren Auswirkungen:

Die Richtlinienvariante kann daher auf der Grundlage von RPO-, RTO- und Kostenaspekten gewählt werden.

Bei der Ermittlung, welche Auswirkungen die Umstellung der Richtlinie eines Sicherungselements von Richtlinie 1 (Policy 1, P1) auf Richtlinie 2 (Policy 2, P2) oder die Bearbeitung der Richtlinie 1 (Policy 1, P1) hat, sind ein paar Prinzipien zu beachten.

• Alle Änderungen werden auch rückwirkend angewendet. Die neueste Sicherungsrichtlinie wird auch auf zuvor erstellte Wiederherstellungspunkte angewendet. Ein Beispiel: Angenommen, die Aufbewahrungsdauer für tägliche vollständige Sicherungen beträgt 30 Tage, und auf der Grundlage der derzeit aktiven Richtlinie wurden zehn Wiederherstellungspunkte erstellt. Wenn nun die Aufbewahrungsdauer für tägliche vollständige Sicherungen auf zehn Tage verkürzt wird, wird auch die Ablaufzeit der vorherigen Punkte nach der Formel „Startzeit + zehn Tage“ neu berechnet, und abgelaufene Punkte werden gelöscht.
• Zum Änderungsumfang zählen auch der Tag der Sicherung, die Art der Sicherung und die Aufbewahrungsdauer. Beispiel: Wenn eine Richtlinie von täglichen vollständigen Sicherungen in wöchentliche vollständige Sicherungen am Sonntag geändert wird, werden alle vorherigen vollständigen Sicherungen, die nicht an einem Sonntag erstellt wurden, zum Löschen markiert.
• Ein übergeordnetes Element wird erst gelöscht, wenn das untergeordnete Element aktiv/nicht abgelaufen ist. Jeder Sicherungstyp verfügt über eine gemäß der aktuell aktiven Richtlinie festgelegte Ablaufzeit. Vollständige Sicherungen werden jedoch als übergeordnete Elemente für nachfolgende differenzielle Sicherungen, inkrementelle Sicherungen und Protokollsicherungen betrachtet. Eine differenzielle Sicherung und ein Protokoll sind niemals übergeordnete Elemente. Eine inkrementelle Sicherung kann ein übergeordnetes Element einer nachfolgenden inkrementellen Sicherung sein. Ein übergeordnetes Element, das zum Löschen markiert ist, wird nicht gelöscht, wenn die untergeordneten differenziellen Sicherungen oder Protokollsicherungen nicht abgelaufen sind. Wenn eine Richtlinie beispielsweise von täglichen vollständigen Sicherungen in wöchentliche vollständige Sicherungen am Sonntag geändert wird, werden alle vorherigen vollständigen Sicherungen, die nicht an einem Sonntag erstellt wurden, zum Löschen markiert. Sie werden jedoch erst wirklich gelöscht, wenn die zuvor täglich erstellten Protokolle abgelaufen sind. Anders ausgedrückt: Sie werden gemäß der aktuellen Protokolldauer aufbewahrt. Nach Ablauf der Protokolle werden sowohl die Protokolle als auch diese vollständigen Sicherungen gelöscht.

Mit diesen Prinzipien im Hinterkopf können Sie die folgende Tabelle lesen und die Auswirkungen einer Richtlinienänderung nachvollziehen.

Sie können den Speicherplatz im Stammordner mithilfe einer der folgenden Optionen verwalten:

• Erstellen Sie ein eigenes LV für /opt/msawb.
• Erstellen Sie einen Softlink/Symlink zu einem anderen Speicherort/Ordner auf demselben/einem anderen Datenträger.
• Vergrößern Sie den Speicherplatz auf der Stammpartition.

Nächste Schritte

• Erfahren Sie, wie SAP HANA-Datenbanken auf virtuellen Azure-Computern gesichert werden.
• Erfahren Sie, wie Sie Probleme mit der SAP HANA-Datenbanksicherung beheben können.