Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Workflow zur Notfallwiederherstellung

08/18/2025 Beitragende

PDFs

Unternehmen haben die öffentliche Cloud als praktikable Ressource und Ziel für die Notfallwiederherstellung angenommen. SnapCenter gestaltet diesen Prozess so nahtlos wie möglich. Dieser Notfallwiederherstellungs-Workflow ist dem Klon-Workflow sehr ähnlich, allerdings wird bei der Datenbankwiederherstellung das letzte verfügbare Protokoll verwendet, das in die Cloud repliziert wurde, um alle möglichen Geschäftstransaktionen wiederherzustellen. Es gibt jedoch zusätzliche Schritte vor und nach der Konfiguration, die speziell für die Notfallwiederherstellung erforderlich sind.

Klonen Sie eine lokale Oracle-Produktionsdatenbank für die Notfallwiederherstellung in die Cloud

Um zu überprüfen, ob die Klonwiederherstellung über das letzte verfügbare Protokoll läuft, haben wir eine kleine Testtabelle erstellt und eine Zeile eingefügt. Die Testdaten würden nach einer vollständigen Wiederherstellung des letzten verfügbaren Protokolls wiederhergestellt.
Melden Sie sich bei SnapCenter mit einer Datenbankverwaltungs-Benutzer-ID für Oracle an. Navigieren Sie zur Registerkarte „Ressourcen“, auf der die von SnapCenter geschützten Oracle-Datenbanken angezeigt werden.

Wählen Sie die Oracle-Protokollressourcengruppe aus und klicken Sie auf „Jetzt sichern“, um manuell eine Oracle-Protokollsicherung auszuführen und die letzte Transaktion an das Ziel in der Cloud zu übertragen. In einem echten DR-Szenario hängt die letzte wiederherstellbare Transaktion von der Replikationshäufigkeit des Datenbankprotokollvolumens in die Cloud ab, die wiederum von der RTO- oder RPO-Richtlinie des Unternehmens abhängt.

Abbildung, die einen Eingabe-/Ausgabedialog zeigt oder schriftlichen Inhalt darstellt

Beim asynchronen SnapMirror gehen in einem Notfallwiederherstellungsszenario Daten verloren, die es im Intervall der Datenbankprotokollsicherung nicht zum Cloud-Ziel geschafft haben. Um Datenverluste zu minimieren, können häufigere Protokollsicherungen geplant werden. Allerdings gibt es eine technisch erreichbare Grenze für die Häufigkeit der Protokollsicherung.

Wählen Sie die letzte Protokollsicherung auf den sekundären Spiegelsicherungen aus und mounten Sie die Protokollsicherung.
Wählen Sie die letzte vollständige Datenbanksicherung aus und klicken Sie auf „Klonen“, um den Klon-Workflow zu starten.
Wählen Sie eine eindeutige Klon-DB-ID auf dem Host aus.
Stellen Sie ein Protokollvolume bereit und mounten Sie es auf dem Ziel-DR-Server für den Oracle-Flash-Wiederherstellungsbereich und die Online-Protokolle.

Beim Oracle-Klonvorgang wird kein Protokollvolume erstellt, das vor dem Klonen auf dem DR-Server bereitgestellt werden muss.
Wählen Sie den Ziel-Klonhost und den Speicherort für die Datendateien, Steuerdateien und Redo-Protokolle aus.
Wählen Sie die Anmeldeinformationen für den Klon aus. Geben Sie die Details der Oracle-Home-Konfiguration auf dem Zielserver ein.
Geben Sie die Skripte an, die vor dem Klonen ausgeführt werden sollen. Datenbankparameter können bei Bedarf angepasst werden.
Wählen Sie „Bis zum Abbrechen“ als Wiederherstellungsoption aus, damit die Wiederherstellung alle verfügbaren Archivprotokolle durchläuft, um die letzte an den sekundären Cloud-Speicherort replizierte Transaktion wiederherzustellen.
Konfigurieren Sie den SMTP-Server bei Bedarf für E-Mail-Benachrichtigungen.
Zusammenfassung des DR-Klons.
Geklonte Datenbanken werden unmittelbar nach Abschluss des Klonvorgangs bei SnapCenter registriert und stehen dann für den Backup-Schutz zur Verfügung.

Validierung und Konfiguration des Post-DR-Klons für Oracle

Validieren Sie die letzte Testtransaktion, die am DR-Standort in der Cloud gelöscht, repliziert und wiederhergestellt wurde.
Konfigurieren Sie den Flash-Wiederherstellungsbereich.
Konfigurieren Sie den Oracle-Listener für den Benutzerzugriff.
Trennen Sie das geklonte Volume vom replizierten Quellvolume.
Führen Sie eine umgekehrte Replikation von der Cloud zum lokalen Server durch und erstellen Sie den ausgefallenen lokalen Datenbankserver neu.

Durch die Klonaufteilung kann es zu einer deutlich höheren temporären Speicherplatzauslastung als im Normalbetrieb kommen. Nach dem Neuaufbau des lokalen DB-Servers kann jedoch zusätzlicher Speicherplatz freigegeben werden.

Klonen Sie eine lokale SQL-Produktionsdatenbank zur Notfallwiederherstellung in die Cloud.

Um zu überprüfen, ob die SQL-Klonwiederherstellung das letzte verfügbare Protokoll durchlaufen hat, haben wir eine kleine Testtabelle erstellt und eine Zeile eingefügt. Die Testdaten würden nach einer vollständigen Wiederherstellung bis zum letzten verfügbaren Protokoll wiederhergestellt.
Melden Sie sich bei SnapCenter mit einer Datenbankverwaltungs-Benutzer-ID für SQL Server an. Navigieren Sie zur Registerkarte „Ressourcen“, auf der die SQL Server-Schutzressourcengruppe angezeigt wird.
Führen Sie manuell eine Protokollsicherung aus, um die letzte zu replizierende Transaktion in den sekundären Speicher in der öffentlichen Cloud zu übertragen.
Wählen Sie die letzte vollständige SQL Server-Sicherung für den Klon aus.
Legen Sie die Kloneinstellungen fest, z. B. Klonserver, Kloninstanz, Klonname und Mount-Option. Der sekundäre Speicherort, an dem das Klonen durchgeführt wird, wird automatisch ausgefüllt.
Wählen Sie alle anzuwendenden Protokollsicherungen aus.
Geben Sie optionale Skripts an, die vor oder nach dem Klonen ausgeführt werden sollen.
Geben Sie einen SMTP-Server an, wenn eine E-Mail-Benachrichtigung gewünscht ist.
Zusammenfassung des DR-Klons. Geklonte Datenbanken werden sofort bei SnapCenter registriert und stehen für den Backup-Schutz zur Verfügung.

Validierung und Konfiguration des Post-DR-Klons für SQL

Überwachen Sie den Status des Klonauftrags.
Überprüfen Sie, ob die letzte Transaktion mit allen Protokolldateiklonen und -wiederherstellungen repliziert und wiederhergestellt wurde.
Konfigurieren Sie ein neues SnapCenter -Protokollverzeichnis auf dem DR-Server für die SQL Server-Protokollsicherung.
Trennen Sie das geklonte Volume vom replizierten Quellvolume.
Führen Sie eine umgekehrte Replikation von der Cloud zum lokalen Server durch und erstellen Sie den ausgefallenen lokalen Datenbankserver neu.

Wo bekomme ich Hilfe?

Wenn Sie Hilfe bei dieser Lösung und den Anwendungsfällen benötigen, treten Sie bitte dem"Slack-Kanal für den Support der NetApp Solution Automation-Community" und suchen Sie nach dem Kanal zur Lösungsautomatisierung, um Ihre Fragen oder Anfragen zu posten.