Disaster Recovery mit NAKIVO: Planung, Implementierung und Testen
Backup und Disaster Recovery bilden die Grundlage für Datensicherheitsstrategien in Unternehmen und Branchen. Disaster Recovery bezeichnet den Prozess der Wiederherstellung virtueller Maschinen und der darauf ausgeführten Dienste an einem sekundären Standort (auch als Disaster-Recovery-Standort bezeichnet), wenn der Produktionsstandort nicht mehr verfügbar ist. Diese Standorte beherbergen redundante Server, Computer und Netzwerkgeräte mit der erforderlichen Software und Sekundäre DR-Standorte können unterschiedlicher Art sein je nach Grad der Redundanz.
NAKIVO Backup & Replication umfasst die Standortwiederherstellung, mit der Sie erweiterte Wiederherstellungssequenzen (mit vollständigem Standort-Failover) erstellen können, die mit einem Klick gestartet werden können, wenn Ihr Primärstandort ausfällt. Lesen Sie diesen Blogbeitrag, um mehr über wichtige Komponenten der DR-Strategie zu erfahren, wie z. B. die IT-Notfallplanung, das Testen und die Durchführung von Disaster Recovery mit der integrierten Lösung von NAKIVO.
Schritt 1. Planung der Disaster Recovery
Als wesentlicher Schritt für eine effektive Disaster Recovery sollte die Planung eine Bewertung der Wiederherstellungsanforderungen der Organisation sowie die Erarbeitung eines umfassenden Verständnisses darüber umfassen, welche Komponenten, Schritte und Verfahren in einen Disaster Recovery-Workflow einbezogen werden sollten.
Planung der Disaster Recovery: Best Practices
1. Durchführung einer Business-Impact-Analyse
Eine Business-Impact-Analyse (oder BIA) dient dazu, die potenziellen negativen Auswirkungen größerer Vorfälle oder Naturkatastrophen auf den Geschäftsbetrieb zu ermitteln. Diese Analyse umfasst die Festlegung einer Prioritätenreihenfolge für verschiedene VMs, die Reihenfolge der Wiederherstellung sowie die verfügbare Zeit, bevor eine Störung den Geschäftsbetrieb erheblich beeinträchtigt. So kann beispielsweise der Ausfall einer VM zu Verzögerungen und Unannehmlichkeiten führen, während der Ausfall einer anderen VM einen vollständigen Ausfall geschäftskritischer Abläufe zur Folge haben kann.
2. Bewerten Sie die damit verbundenen Risiken
Stellen Sie vor der DR-Planung die relevanten Daten zu den Risiken für den Betrieb und die Geschäftskontinuität Ihres Unternehmens zusammen. In manchen Regionen sind ein längerer Stromausfall oder ein Virenangriff wahrscheinlicher als ein Tornado, während in anderen Regionen Naturkatastrophen häufig vorkommen. Eine Risikobewertung hilft Ihnen dabei, das angemessene Schutzniveau gegen bestimmte Bedrohungen zu ermitteln und Maßnahmen zu entwickeln, um die Risiken zu minimieren und die Folgen abzumildern. Auch wenn sich die Risiken nicht vollständig beseitigen lassen, sind Sie besser auf die Katastrophenszenarien vorbereitet, mit denen Sie wahrscheinlich konfrontiert werden.
3. Erstellen Sie eine Dokumentation zur Disaster Recovery
Sobald die Risiken und ihre potenziellen Auswirkungen auf Ihr Unternehmen identifiziert sind, haben Sie ein besseres Verständnis dafür, worauf Sie Ihre Bemühungen bei der Planung der Disaster Recovery-Prozesse konzentrieren sollten. Verfahren zur Wiederherstellung von Dokumenten, in der alle wichtigen Schritte und DR-Maßnahmen detailliert beschrieben werden, und aktualisieren Sie die Dokumente regelmäßig, um Änderungen in der Umgebung Rechnung zu tragen. Die Dokumentation sollte Folgendes enthalten:
Disaster recovery scope.Bewerten Sie die Bedeutung jeder Hardware- und Softwarekomponente in Ihrer Infrastruktur und beziehen Sie diejenigen, die für geschäftskritische Abläufe wichtig sind, in Ihren Plan für Disaster Recovery ein. Virtuelle Maschinen (VMs), die kritische Informationen, IT-Systeme und Anwendungen beherbergen, deren Betrieb für die Gewährleistung einer kontinuierlichen Dienstbereitstellung unerlässlich ist, sollten bei der Wiederherstellung oberste Priorität haben.VM recovery order.Bestimmte VMs sind möglicherweise von der Software oder den Informationen abhängig, die auf einer anderen VM gespeichert sind, was bedeutet, dass sie nicht separat betrieben oder willkürlich gestartet werden können. Sie sollten die Wiederherstellungsreihenfolge festlegen, um die Wiederherstellung zu optimieren und das Risiko von Softwarekonflikten am DR-Standort auszuschließen. Beispielsweise muss die VM, auf der der Active Directory-Domänencontroller läuft, bereits in Betrieb sein, bevor Sie eine VM mit einem Dateiserver starten können, der die Active Directory-Authentifizierung nutzt.
Ein weiteres Beispiel sind Webdienste, die häufig auf Software angewiesen sind, die auf mehreren verschiedenen VMs installiert ist. Möglicherweise muss die folgende Reihenfolge eingehalten werden:
- Die VM mit dem Datenbankserver sollte zuerst gestartet werden.
- Anschließend kann die VM mit dem Anwendungsserver gestartet werden.
- Erst dann kann die VM mit dem Webserver gestartet werden.
RTO and RPO in disaster recovery.Legen Sie die Wiederherstellungszeitziel (RTO) (RTO) und Wiederherstellungspunktziel (RPO) (RPO) für die VMs mit unterschiedlichen Prioritäten im Disaster Recovery-Plan fest. Beispielsweise können VMs mit Finanzsystemen kürzere Wiederherstellungsziele haben als solche, die zur Speicherung archivierter Dokumente verwendet werden.Dependencies.Berücksichtigen Sie bei der Ermittlung der Abhängigkeitskette zwischen Mitarbeitern und IT-Komponenten Ihre Mitarbeiter, um Schwachstellen zu vermeiden, die zu einem Scheitern der Wiederherstellung führen können. Beispielsweise muss eine von der Buchhaltung genutzte VM möglicherweise zuerst wiederhergestellt werden, wenn Mitarbeiter anderer Abteilungen für ihre Arbeit auf diese Finanzvorgänge angewiesen sind.Staff. Weisen Sie den Teammitgliedern, die an den DR-Prozessen beteiligt sind, Rollen und Verantwortlichkeiten zu. Falls sie am DR-Standort arbeiten werden, stellen Sie sicher, dass dort Arbeitsstationen mit der gesamten erforderlichen Ausstattung, Büromöbeln und Hardware eingerichtet sind, damit sie ihre Arbeit mit minimalen Unterbrechungen fortsetzen können. Wenn Mitarbeiter während einer Katastrophe remote arbeiten können, richten Sie den VPN-Zugang ein und stellen Sie VPN-Konten im Voraus bereit.Hardware requirements. Der Erfolg eines Disaster Recovery-Plans hängt stark von der Leistung und den Fähigkeiten der am DR-Standort befindlichen Hardware ab. Dabei sollten mehrere Faktoren berücksichtigt werden:- Server müssen über ausreichend CPU-Leistung, Arbeitsspeicher und Festplattenkapazität verfügen, um die übertragenen Workloads bewältigen zu können. Eine geringe CPU-Leistung und unzureichender Arbeitsspeicher können die Geschwindigkeit Ihrer VMs beeinträchtigen, während eine unzureichende Festplattengeschwindigkeit zu einer schlechten VM-Leistung führt.
- Netzwerke müssen genügend Bandbreite bereitstellen, damit die wiederhergestellten VMs untereinander, mit gemeinsam geteilter Speicherund bei Bedarf auch mit Benutzern kommunizieren können.
Schritt 2. Vorbereitung auf die Disaster Recovery-Wiederherstellung
Sobald Sie über die erforderliche Dokumentation verfügen, können Sie mit der Vorbereitung auf die Disaster Recovery-Wiederherstellung fortfahren, indem Sie den Standort für die Wiederherstellung vorbereiten und die Replikation kritischer Workloads an diesen Standort einrichten. Die Replikation ist erforderlich, damit VM-Failover Replik-VMs bereitgestellt werden können, wenn die primäre Infrastruktur ausfällt.
Was ist VM-Replikation?
Die Replikation virtueller Maschinen ist der Vorgang, bei dem eine identische Kopie einer Quell-VM (als „VM-Replik“ bezeichnet) auf einem anderen Host (dem Zielhost) erstellt wird. Die VM-Replik ist eine normale VM, die so lange im ausgeschalteten Zustand verbleibt, bis sie benötigt wird (zu diesem Zeitpunkt kann sie auf ihrem Host fast sofort hochgefahren und betriebsbereit sein).
Erfahren Sie, wie Sie eine VM-Replik erstellen und Einen VMware-Replikationsauftrag konfigurieren in NAKIVO Backup & Replication nutzen, um weitere Details zu erhalten.
Der Vorgang der Umstellung von Workloads von einer Quelle (Produktions-VM) auf eine VM-Replik am DR-Standort zum Zweck der Aufrechterhaltung der Geschäftskontinuität und der Hochverfügbarkeit wird als Failover bezeichnet.
Best Practices für die VM-Replikation
Es gibt eine Vielzahl Best Practices zur Replikation , um eine höhere Zuverlässigkeit und Effizienz des Prozesses zu gewährleisten. Hier konzentrieren wir uns auf zwei wichtige Punkte:
Perform VM replication at the{10}. Die Virtualisierungsebene ist die Zwischenschicht zwischen der physischen Hardware und dem auf einer VM laufenden Gastbetriebssystem. Eine auf der Virtualisierungsebene durchgeführte Replikation wird als Replikation auf Host-Ebene bezeichnet und ist effizienter als die Replikation auf Gast-Ebene.Use application-aware replication to avoid data loss.Wenn ein für die Replikation benötigter VM-Schnappschuss erstellt wird, während diese Anwendungen ohne zusätzliche Aktionen laufen, hätte dies ähnliche Auswirkungen wie ein unerwarteter Stromausfall und ein Herunterfahren, wodurch Daten verloren gehen können.
Bei Application-Aware-Methoden werden die Anwendungen eingefroren (in den Ruhezustand versetzt) und der Arbeitsspeicher geleert, sodass vor der Erstellung des Schnappschusses keine Daten auf die Festplatte geschrieben werden können. Sobald der konsistente Schnappschuss erstellt ist, kann ein Replikat erstellt werden. Solche Replikate lassen sich erfolgreich wiederherstellen, wobei die darin enthaltenen Anwendungen ordnungsgemäß weiterlaufen.
NAKIVO Backup & Replication unterstützt Application-Aware Replikation auf Host-Ebene für VMware-VMs, Hyper-V-VMs und EC2-Instanzen mit speziellen Funktionen für Microsoft SQL Server, Exchange Server und Active Directory-Domänencontroller.
Schritt 3. Erstellen eines Disaster-Recovery-Workflows
Um einen DR-Workflow zu erstellen, benötigen Sie eine spezialisierte Disaster-Recovery-Lösung wie NAKIVO Backup & Replication, die über eine integrierte Standortwiederherstellung verfügt, um DR-Abläufe zu orchestrieren und zu automatisieren.
- Was ist ein Workflow zur Disaster Recovery?
- Verfügbare Aktionen für einen DR-Workflow
- So erstellen Sie einen Workflow für die Disaster Recovery
- Schritt-für-Schritt-Anleitung zur Konfiguration von NAKIVO Standortwiederherstellung
Was ist ein Disaster-Recovery-Workflow?
Ein DR-Workflow ist eine Abfolge von Aktionen, die im Rahmen des Disaster-Recovery-Prozesses ausgeführt werden, um eine sichere und schnelle Umschaltung von Workloads auf Replikate zu gewährleisten. Der Workflow organisiert den Failover-Prozess mit Aktionen, die sich auf Quell-VMs, Ziel-VMs, zu erfüllende Bedingungen usw. beziehen. Sie sollten festlegen, in welcher Reihenfolge die Aktionen ausgeführt werden sollen, da einige Disaster-Recovery-Verfahren vom Ergebnis der Ausführung anderer Aktionen abhängen können.
Verfügbare Aktionen für die Standortwiederherstellung
Die Standortwiederherstellung ermöglicht es Ihnen, komplexe DR-Sequenzen zu erstellen, indem Sie Aktionen und Bedingungen in einem einzigen Workflow kombinieren. Jede Aktion kann in NAKIVO Backup & Replication nur im Testmodus, nur im Produktionsmodus oder in beiden Modi (dies ist die Standardeinstellung) ausgeführt werden.
Sie können eine oder alle der folgenden Aktionen in eine Sequenz einbinden:
Failover– leitet den Failover auf Replik-VMware-VMs, Hyper-V-VMs oder EC2-Instanzen ein.Failback– überträgt Workloads von der VM-Replik zurück zur Quell-VM. Die seit dem Zeitpunkt des Failovers in der VM-Replik vorgenommenen Änderungen werden bei der Durchführung des Failback-Vorgangs in die Quell-VM geschrieben. Die VMs werden synchronisiert, und die Quell-VM befindet sich wieder im aktuellen Produktionszustand.Start– startet VMware-VMs, Hyper-V-VMs oder EC2-Instanzen.Stop– stoppt laufende VMware-VMs, Hyper-V-VMs und EC2-Instanzen.Run job– führt einen Sicherungsauftrag, einen Replikationsauftrag, einen Auftrag für Standortwiederherstellung, einen Auftrag für Backupkopie oder einen Flash-VM-Boot-Auftrag aus.Stop jobs– stoppt einen Auftrag (einen der im vorherigen Punkt aufgeführten Aufträge).Run script– führt ein Skript auf einem der folgenden Ziele aus: dem Server mit dem Director, einem Remote-Windows-Server, einem Remote-Linux-Server, einer VMware-VM, einer Hyper-V-VM oder einer EC2-Instanz.Attach repository– bindet ein Backup-Repository ein, das von NAKIVO Backup & Replication zum Speichern von Backups verwendet wird.Detach repository– trennt ein Backup-Repository.Send email– versendet eine E-Mail mit der von Ihnen verfassten Nachricht an einen oder mehrere definierte Empfänger.Wait– wartet den angegebenen Zeitraum ab, bevor mit der nächsten Aktion fortgefahren wird.Check condition– prüft basierend auf Ihrer Eingabe (ganzer oder Teil eines Ressourcennamens) eine der folgenden Bedingungen:- Die Ressource existiert
- Die Ressource ist
-
- IP/Hostname ist erreichbar
Ausführung von
So erstellen Sie einen Standortwiederherstellungs-Workflow 
Sehen wir uns ein Beispiel für die Erstellung eines Standortwiederherstellungs-Auftrags in NAKIVO Backup & Replication an.
- Unsere Konfiguration
-
Hier ist die Konfiguration, die wir betrachten werden: ein primärer (Produktions-)Standort mit VMware vSphere-VMs und ein DR-Standort an einem entfernten Standort:
DC-VM ist eine Windows-basierte VM, auf der ein Active Directory-Domänencontroller läuft. - FS-VM ist eine Windows-basierte VM mit einem Dateiserver (für die Dateifreigabe wird das SMB-Protokoll verwendet). Zur Benutzerauthentifizierung wird Active Directory verwendet. Oracle-Datenbank-Dumps werden auf dem Dateiserver gespeichert.Oracle-Datenbanksoftware ist installiert
Ora-DB ist die VM, auf der die Oracle-Datenbank läuft.
Backup der Oracle-Datenbank
Die Disaster-Recovery-VMs sind Replikate der Produktions-VMs:
DC-VM-replica,
sowie
FS-VM-replica,
- sind Replikate der Produktions-VMs. Sie können als Ziele für einen Failover verwendet werden.
- DB-VM, ist eine Linux-basierte VM mit , enthält jedoch keine Datenbanken.
Die Datenbank wird mit NAKIVO Backup & Replication auf Datenbankebene auf
FS-VM gesichert (diese
- ist anwendungskonsistent).
- XML-PH-0024@deepl.internal und XML-PH-0025@deepl.internal DC-VM XML-PH-0026@deepl.internal werden auf Host-Ebene mit der NAKIVO-Lösung an den DR-Standort repliziert. XML-PH-0027@deepl.internal Reihenfolge der VM-Wiederherstellung XML-PH-0028@deepl.internal Bei einem Vorfall, der zum Ausfall des Produktionsstandorts führt, müssen die Komponenten am DR-Standort wie folgt wiederhergestellt werden: XML-PH-0029@deepl.internal Failover von XML-PH-0030@deepl.internal DC-VM XML-PH-0031@deepl.internal auf XML-PH-0032@deepl.internal DC-VM-Replik. XML-PH-0033@deepl.internal Sobald DC-VM-Replik laufend ist, führen Sie den Failover von FS-VM auf FS-VM-Replik durch. Sie müssen in dieser Reihenfolge vorgehen, da FS-VM für die Benutzerauthentifizierung auf dem Dateiserver auf DC-VM angewiesen ist.
- Sobald diese beiden VMs laufen, kann DB-VM auf das freigegebene Verzeichnis auf dem Dateiserver zugreifen, in dem der Dump gespeichert ist. Nun kann DB-VM gestartet werden.
- Sobald DB-VM läuft, führen Sie ein Skript aus, das die Datenbank aus dem auf dem Dateiserver befindlichen Dump wiederherstellen kann. Die blauen Pfeile in den obigen Abbildungen zeigen die Abhängigkeiten.
Beachten Sie, dass es einige Zeit dauern kann, bis die Dienste auf einer eingeschalteten VM-Replik nach dem Failover und vor dem Failover zur nächsten Replik oder der Wiederherstellung einer Anwendung oder einer Datenbank gestartet sind. Diese Wartezeit sollte Teil der DR-Sequenz sein.
Für diese Reihenfolge beim VM-Failover müssen Sie in NAKIVO Backup & Replication einen Standortwiederherstellungs-Auftrag mit der folgenden Logik erstellen:
Action 1: Failover der DC-VM . Warten Sie, bis diese Aktion abgeschlossen ist, bevor Sie mit dem nächsten Schritt fortfahren. Beenden Sie den Auftrag, wenn diese Aktion fehlschlägt.Action 2. Warten 3 Minuten lang.Action 3. Bedingung prüfen der DC-VM-Replik . Prüfen Sie, ob die Ressource ausgeführt wird. Wenn die Ressource ausgeführt wird, fahren Sie mit der nächsten Aktion im Auftrag der Standortwiederherstellung fort. Andernfalls beenden Sie den Auftrag und melden Sie ihn als fehlgeschlagen.Action 4. FS-VM ausfällen lassen . Warten Sie, bis diese Aktion abgeschlossen ist, bevor Sie mit der nächsten Aktion fortfahren. Beenden Sie den Auftrag, falls diese Aktion fehlschlägt.Action 5. Warten Sie 3 Minuten lang.Action 6. Überprüfen Sie den Zustand der FS-VM-Replik . Wenn die Ressource ausgeführt wird, fahren Sie mit der nächsten Aktion des Site Recovery-Auftrags fort. Ist dies nicht der Fall, beenden Sie den Auftrag und kennzeichnen Sie ihn als fehlgeschlagen.Action 7. Starten Sie die DB-VM . Warten Sie, bis diese Aktion abgeschlossen ist, bevor Sie mit der nächsten Aktion fortfahren. Beenden Sie den Auftrag, falls diese Aktion fehlschlägt.Action 8. Warten Sie 5 Minuten lang.Action 9. Führen Sie das Skript aus. Zieltyp: VMware-VM. Ziel-VM: DB-VM. Skriptpfad: /home/oracle/restore_db.sh (beim Hinzufügen dieses Schritts müssen Sie den Benutzernamen und das Passwort eines Kontos eingeben, das über ausreichende Berechtigungen zum Ausführen des Skripts verfügt).
NAKIVO-Anleitung für die Standortwiederherstellung
Erstellen wir nun einen neuen Standortwiederherstellungs-Auftrag auf der Grundlage des oben beschriebenen Plans. Klicken Sie auf der Seite „ Jobs “ Ihrer NAKIVO Backup & Replication-Instanz auf „ Create > Site recovery job“.
1. Aktionen
Der „ “ – Assistent für einen neuen Standortwiederherstellungs-Auftrag wird gestartet. Im linken Bereich finden Sie Aktionen, die dem Auftrag hinzugefügt werden können. Klicken Sie einfach auf eine Aktion, um sie der Abfolge hinzuzufügen. Beachten Sie, dass Sie in einer Abfolge keine Aktionen für verschiedene Plattformen mischen können (wir erstellen einen Auftrag für VMware-VMs).
Aktion 1. Failover der DC-VM
- Klicken Sie im linken Bereich auf
Failover VMware VMs.
- Wählen Sie im linken Bereich das Replikat der DC-VM aus einem bestehenden Auftrag aus. In unserem Workflow ist das Failover auf DC-VM-Replik die erste Aktion. Im rechten Bereich können Sie einen Wiederherstellungspunkt auswählen. Standardmäßig wird der aktuellste Wiederherstellungspunkt verwendet.
Klicken Sie auf Next , um fortzufahren. 
- Für die Optionen zur Notfallwiederherstellung und zum Failover können Sie die Option
Power off source VMsdeaktivieren – diese Option kann verwendet werden, um einen Konflikt bei den IP-Adressen zu vermeiden, wenn die Quell-VMs und die Replikate dieselben Netzwerke nutzen.
Basierend auf der oben beschriebenen Logik wählen wir die folgenden Optionen aus:
- Diese Aktion ausführen in:
Run this action in both testing and production mode - Warteverhalten:
Wait for this action to complete - Fehlerbehandlung:
Stop and fail the job if this action fails
Klicken Sie auf Save , um die erstellte Aktion zu speichern.

Aktion 2. 3 Minuten warten
Eine Warte- Aktion ist in diesem Fall sinnvoll, da die nachfolgende Failover-Aktion im Workflow (Failover zu FS-VM-Replik ) voraussetzt, dass die DC-VM-Replik verfügbar ist und bereits mit Active Directory-Domänendiensten läuft.
- Klicken Sie im linken Bereich des Bildschirms „ “ unter „Aktionen“ auf „
Wait“.
- Wählen Sie die Wartezeit aus (wir verwenden 3 Minuten ).
Wählen Sie die Aktionsoptionen wie bei der ersten Aktion aus und klicken Sie auf Save.

Die neue Aktion wird nach der vorherigen Aktion am Ende der Liste hinzugefügt. Sie können Aktionen neu anordnen, bearbeiten oder entfernen. Bewegen Sie einfach den Mauszeiger über eine Aktion, um die Optionen anzuzeigen.
Aktion 3. Zustand prüfen von DC-VM-Replik
- Klicken Sie im linken Bereich des Bildschirms Aktionen auf
Check condition, um zu prüfen, ob die VM, die in der ersten Aktion per Failover umgeschaltet wurde, läuft.
- Konfigurieren Sie diese Aktion wie folgt:
- Wählen Sie den Bedingungstyp aus:
Resource is running. Die anderen Optionen sind Ressource existiert oder IP/Hostname ist erreichbar. - Wählen Sie den Ressourcentyp aus:
VMware VM. - Wählen Sie die Identifizierungsmethode aus:
Name(die andere Option ist ID ), um die betreffende VM zu identifizieren. Sie können einen beliebigen Teil der Zeichenfolge der VM verwenden. Da wir hier den genauen Namen kennen, verwenden wir die FunktionEquals. - Definieren Sie die Suchzeichenfolge:
DC-VM-replica.
Nun haben wir eine Aktion, die prüft, ob die VMware-VM mit dem Namen DC-VM-replica läuft. Klicken Sie auf Save , um fortzufahren.

Aktion 4. Failover der FS-VM
- Genau wie bei Aktion 1 klicken Sie auf
Failover VMware VMs.
- In diesem Fall wählen wir FS-VM-replica aus. Klicken Sie auf
Nextund wählen Sie dann für die Failover-Aktion dieselben Optionen aus wie zuvor bei Aktion 1 und klicken Sie aufSave.
Aktion 5.
Wait
Check condition Warten Sie 3 Minuten
Klicken Sie auf und konfigurieren Sie diese Aktion genauso wie bei Aktion 2
. Die angegebene Zeit beträgt in unserem Fall erneut 3 Minuten .
Aktion 6. Überprüfen Sie den Status von
- FS-VM-replica
Start VMware VMs
Klicken Sie auf , um zu überprüfen, ob die VMware-VM FS-VM-replica
läuft. Beziehen Sie sich auf
Aktion 2
und wählen Sie dieselben Optionen aus – natürlich mit Ausnahme des VM-Namens.
- Aktion 7. Starten Sie die DB-VM „
- “
Klicken Sie im linken Bereich des Bildschirms „Save“ unter „Aktionen“
auf „
Wait
Wählen Sie die DB-VM „ “ aus. Diese VM kann gestartet werden, sobald Sie sicher sind, dass die FS-VM-Replik „ “
läuft. Wählen Sie unten auf der Seite dieselben Aktionsoptionen aus, wie sie in den vorherigen Aktionen gezeigt wurden. Klicken Sie anschließend auf „
“.
-
Aktion 8. Warten Sie 5 MinutenRun script
Warten Sie 5 Minuten. Klicken Sie auf und konfigurieren Sie diese Aktion ähnlich wie bei Aktion 2
. Diese Zeit sollte ausreichen, um den Oracle-Dienst auf
- Aktion 9. Skript ausführen
Klicken Sie auf dem Bildschirm
- Aktionen
- auf . Beachten Sie, dass dieses Skript dazu dient, die Oracle-Datenbank auf Datenbankebene aus einem auf FS-VM-Replik
-
- Legen Sie die Skriptoptionen fest. In unserem Fall:
- Zieltyp: VMware-VM
- Ziel-VM:
gespeicherten Dump wiederherzustellen.
DB-VM
- /home/oracle/restore.db.sh
Next
Benutzername:
Passwort: (Passwort)mit verschiedenen Netzwerken verbunden
Enable network mapping
Ihr Skriptpfad, Benutzername und Passwort weichen davon ab. Vergessen Sie nicht, sicherzustellen, dass die Skriptdatei ausführbar ist und der Benutzer über ausreichende Berechtigungen zum Ausführen des Skripts verfügt. Die Aktionsoptionen werden in diesem Beispiel wie gewohnt konfiguriert.
Klicken Sie auf „ Create new mapping “, wenn Sie bereit sind, fortzufahren.
Save
Next
Nun sehen Sie alle konfigurierten Aktionen. Sie können auch vorhandene Zuordnungsregeln verwenden, wenn Sie diese in anderen Replikations-, Failover- oder Standortwiederherstellung-Aufträgen konfiguriert haben.
3. Re-IP
Wenn die für die VM-Verbindung am Quell- und Zielstandort verwendeten Netzwerke unterschiedliche IP-Adressen haben, sollten Sie Re-IP aktivieren, indem Sie Enable Re-IPauswählen.
- Erstellen Sie eine neue Re-IP-Regel, indem Sie auf
Create new ruleklicken. Legen Sie die Quell- und Zieleinstellungen fest und klicken Sie anschließend aufSave.
- Klicken Sie auf
Select VMsund wählen Sie die VMs aus, für die „Re-IP“ verwendet werden soll. Sie sollten die Anmeldeinformationen eines Benutzers angeben, der über ausreichende Berechtigungen verfügt, um die Netzwerkeinstellungen im Gastbetriebssystem der VM zu ändern.
4. Zeitplan testen
Sie können einen Zeitplan erstellen, der speziell für die Ausführung von Standortwiederherstellung-Aufträgen im Testmodus und die Durchführung von Disaster Recovery-Tests vorgesehen ist. Auf diese Weise können Sie testen, ob der Auftrag innerhalb der erforderlichen Zeitrahmen erfolgreich ausgeführt werden kann. Klicken Sie anschließend auf „Weiter“.
Wir werden in Schritt 6 näher auf das Testen von Site Recovery-Aufträgen eingehen.
5. Optionen
Geben Sie den Auftrags-Name und das Wiederherstellungszeit-Ziel ein. Klicken Sie auf Finish , wenn die Konfiguration abgeschlossen ist.
Schritt 4. Erneutes Absichern der Umgebung
Nachdem die VMs umgeschaltet und die Workloads zum DR-Standort migriert wurden, sind die ursprünglichen Produktions-VMs nun offline, und die Replikate am DR-Standort sind nun die einzigen funktionsfähigen Kopien. Sollte nun eine eingeschaltete VM-Replik ausfallen, hätten Sie keine Möglichkeit, die Daten und Workloads schnell wiederherzustellen.
Um die am DR-Standort ausgeführten VMs zu schützen, sollten Sie diese VMs an einen anderen sicheren Ort replizieren. Auf diese Weise können Sie, falls die am DR-Standort ausgeführte VM ausfällt, schnell auf die neue VM-Replik umschalten.
Mit der Funktionalität der Standortwiederherstellung können Sie eine automatisierte Replikation konfigurieren, sobald der VM-Failover abgeschlossen ist. Hier finden Sie ein Beispiel, das Schritt für Schritt zeigt, wie Sie VMs nach einem Failover mit einem Standortwiederherstellungs-Auftrag erneut schützen können.
- Klicken Sie auf der Seite „
Jobs“ mit der rechten Maustaste auf den Namen des Standortwiederherstellungs-Auftrags, den Sie kürzlich erstellt haben. Klicken Sie im Kontextmenü auf „Edit“.
- Sie sehen, dass Ihre zuvor durchgeführten Failover-Aktionen dem Standortwiederherstellungs-Auftrag hinzugefügt wurden. Suchen Sie den Eintrag „
Run jobs“ in der Aktionsliste im linken Bereich des Standortwiederherstellungs-Bildschirms „Actions“ und klicken Sie darauf.
- Wählen Sie den Replikationsjob aus der Jobliste aus. Wählen Sie wie gewohnt die Aktionsoptionen aus und klicken Sie auf „
Save“.
- Fügen Sie zwischen der Failover-Aktion und dem Replikationsauftrag die Aktion „ “ („Warten“) ein. Dadurch erhält die VM-Replik etwas Zeit, um hochzufahren und das Betriebssystem zu laden (eine ausgeschaltete VM kann nicht repliziert werden). Klicken Sie in der Liste „Aktionen“ im linken Bereich auf „
Wait“.
- Wählen Sie eine Wartezeit aus – 5 Minuten sollten ausreichen. Wählen Sie die Aktionsoptionen aus und klicken Sie auf „
Save“.
- Wenn Sie die Aktion hinzufügen, wird sie an das Ende der Aktionsliste angehängt. Klicken Sie auf „
Move up“ und verschieben Sie die Aktion „ “ „Wait“ von der vierten Position auf die dritte Position – sie muss vor der Replikation stattfinden.

Nun sind die Aktionen in der erforderlichen Reihenfolge angeordnet.

- Schließlich ist der Site Recovery-Auftrag bereit für die Durchführung des VM-Failovers und des automatischen erneuten Schutzes der für das Failover verwendeten VM-Replikate. Klicken Sie auf der Startseite mit der rechten Maustaste auf den Namen Ihres Site Recovery-Auftrags und wählen Sie im Kontextmenü „
Run job“ aus.
Schritt 5. Failback
Failback ist der Vorgang, bei dem Virtuelle Maschinen in ihrem aktuellen Zustand vom DR-Standort zurück zum ursprünglichen oder einem neuen Produktionsstandort wiederhergestellt werden. Um zu verstehen, warum Sie das Failback benötigen, lassen Sie uns noch einmal zusammenfassen, wie das Failover funktioniert:
- Wenn eine Katastrophe eintritt (oder prognostiziert wird), wird ein Failover auf eine VM-Replik durchgeführt.
- Alle Änderungen an der VM (beispielsweise Transaktionen, die bei Online-Käufen von Kunden in eine Datenbank geschrieben werden) werden auf eine virtuelle Festplatte der VM-Replik geschrieben. Einige Blöcke werden geschrieben, andere gelöscht. Die virtuelle Festplatte der Quelle-VM enthält diese Transaktionen nicht.
- Sobald der Vorfall behoben ist und der Produktionsstandort wieder funktionsfähig ist, müssen die Workloads zurück zum Produktionsstandort gebracht werden. Die aktualisierten Daten des VM-Replikats müssen zurück zur Quelle-VM übertragen werden. Die VMs müssen mittels Failback mit umgekehrter Replikation neu synchronisiert werden.
Konfiguration des Failbacks in NAKIVO Backup & Replication
Das Failback kann entweder im Produktionsmodus oder im Testmodus durchgeführt werden (wobei alle durch die Failback-Aktion in Ihrer virtuellen Umgebung vorgenommenen Änderungen nach dem Test auf den Zustand vor dem Failback zurückgesetzt werden).
Betrachten wir im Detail, wie die einzelnen Fälle funktionieren.
|
Production failback |
Test failback |
| 1 | Herunterfahren der ursprünglichen Quell-VM (sofern vorhanden und eingeschaltet). | |
| 2 |
Erstellen eines Sicherungs-Schnappschuss der Quell-VM (sofern die Quell-VM funktionsfähig ist). Durch das Erstellen dieses Schnappschusses können Sie den Zustand der Quell-VM vor dem Failover wiederherstellen, falls der Failback nicht ordnungsgemäß durchgeführt werden kann. |
|
| 3 | Führen Sie eine inkrementelle Replikation durch (sofern die ursprüngliche Quelle am Produktionsstandort online ist) oder eine vollständige Replikation (sofern die VM an einem neuen Produktionsstandort wiederhergestellt wird). | |
| 4 | Schalten Sie die VM-Replik aus (optional). | Die VM-Replik wird zum Hosten der Workloads verwendet und wird nicht ausgeschaltet. |
| 5 | Die inkrementelle Replikation wird noch einmal von der VM-Replik zur Quelle durchgeführt. Das Delta (die Daten, die sich seit dem ersten Replikationslauf geändert haben) sollte dieses Mal deutlich kleiner sein. | Die Replikation von einem Replikat zur ursprünglichen Quell-VM (oder einer neuen Produktions-VM) erfolgt nur einmal, da dies für Testzwecke ausreichend ist. |
| 6 | Verbinden der ursprünglichen Quell-VM mit ihrem neuen Netzwerk mittels Netzwerkzuordnung (optional). | Verbinden der Quell-VM mit einem isolierten Netzwerk, damit die Produktionsumgebung in keiner Weise gestört wird (optional). |
| 7 | Änderung der statischen IP-Adresse der ursprünglichen Quell-VM mit „Re-IP“ (optional). | |
| 8 | Einschalten der ursprünglichen Quell-VM. | |
| 9 | Cleanup after a successful failback. Nach einem erfolgreichen Failback-Vorgang befinden sich sowohl die Quell-VM als auch die VM-Replik in ihrem regulären Zustand.
|
Cleanup if the source VM didn't exist before the test failback was run:
|
Vorbereitung des Failbacks
Zunächst sollten Sie einen Standortwiederherstellungs-Auftrag erstellen, der Failover-Aktionen enthält. Dieser Vorgang wurde bereits ausführlich beschrieben.
- Für die Durchführung einer Failover-Aktion sind ein Replikationsauftrag und eine VM-Replik erforderlich.
- Ein Standortwiederherstellungs-Auftrag muss eine Failover-Aktion enthalten, damit ein Failback durchgeführt werden kann.
- Die VM-Replikate müssen sich im Failover-Zustand befinden; daher können Sie ein Failback erst nach Durchführung eines Failovers durchführen.
Failback ausführen
Sehen wir uns anhand eines Beispiels an, wie ein Failback mit NAKIVO Backup & Replication durchgeführt wird.
- Stellen Sie sicher, dass der Failover als Teil eines Standortwiederherstellungs-Auftrags ausgeführt wurde (dieser sollte bereits erstellt worden sein).
- Erstellen Sie einen neuen Standortwiederherstellungs-Auftrag – die Failback-Aktionen können in diesen Auftrag integriert werden. Klicken Sie auf der Seite „
Jobs“ auf „Create>Site recovery job“.
Der Assistent „ “ für neue Site Recovery-Jobs wird gestartet.
1. Actions.
- Klicken Sie im linken Bereich auf „
Failback VMware VMs“ (für andere Umgebungen verwenden Sie „Failback Hyper-V VMs“ oder „Failback EC2 Instances“).
- Wählen Sie die VM-Replikate aus, auf die der Failover-Vorgang angewendet werden soll. Klicken Sie auf „
Next“.
- Wählen Sie einen Failback-Standort aus – dies kann der ursprüngliche Produktionsstandort oder ein neuer Standort sein. Klicken Sie auf „
Next“.
- Wählen Sie die Joboptionen aus. Wählen Sie bei Bedarf „
Power off replica VMs“ aus. Klicken Sie aufSave, wenn Sie bereit sind, fortzufahren.
- Nachdem Sie die Failback-Aktion hinzugefügt haben, sieht der Site Recovery-Auftrag wie im folgenden Screenshot dargestellt aus. Klicken Sie auf
Next.
2. Networks. Wählen Sie diese Option aus, wenn Sie die Netzwerkzuordnung für diesen Auftrag aktivieren müssen. Klicken Sie auf Next.
3. Re-IP. Wählen Sie diese Option aus, wenn Sie „Re-IP“ für diesen Auftrag aktivieren müssen. Klicken Sie auf Next.
4. Test Schedule. Konfigurieren Sie Ihre Planungsoptionen und klicken Sie anschließend auf Next.
5. Options. Definieren Sie die Site Recovery-Auftragsoptionen und geben Sie den Auftragsnamen ein. Sie können den erforderlichen RTO für die VM festlegen und die E-Mail-Adresse für den Failback-Bericht angeben. Klicken Sie auf „ Finish “, um die Erstellung dieses neuen Site Recovery-Auftrags mit Failback abzuschließen.
Nun können Sie diesen Site Recovery-Auftrag ausführen, um den VM-Failback durchzuführen: Klicken Sie einfach mit der rechten Maustaste auf den Namen des Site Recovery-Auftrags, wählen Sie „ Run job“ und anschließend „ Test site recovery job “ oder „ Run site recovery job“.
Schritt 6. Durchführen von Disaster-Recovery-Tests
Disaster-Recovery-Tests helfen Ihnen sicherzustellen, dass Sie im Katastrophenfall für die Wiederherstellung gerüstet sind und dass alle ausgewählten Komponenten innerhalb der festgelegten Zeitrahmen erfolgreich wiederhergestellt werden können.
Es gibt zwei Hauptgründe Warum Sie Tests zur Disaster Recovery durchführen müssen:
To make sure that everything can be recovered successfully. Wenn Sie Ihren Disaster-Recovery-Plan testen und dabei Probleme erkennen, können Sie diese beheben, bevor sie in einem echten Krisenszenario zu ernsthaften Problemen führen.To make sure that RTO values can be met. Mit Disaster-Recovery-Tests können Sie überprüfen, ob Ihre Workloads innerhalb der relevanten RTOs wiederhergestellt werden können. Ein Standortwiederherstellungs-Test kann manuell bei Bedarf oder automatisch nach einem festgelegten Zeitplan durchgeführt werden, was den Vorgang vereinfacht und Ihnen Zeit spart.
Die Unterschiede zwischen Failover im Test- und im Produktionsmodus
Der Mechanismus zur Ausführung eines Failovers unterscheidet sich je nachdem, ob der Standortwiederherstellungs-Auftrag im Test- oder im Produktionsmodus ausgeführt wird. Eine Aufschlüsselung der Schritte für jeden Modus ist in der folgenden Tabelle dargestellt.
Production (emergency) failover |
Test failover |
|
| 1 | Deaktivieren Sie die Replikation von der Quell-VM zur Replik | |
| 2 | Setzen Sie die VM-Replik auf einen bestimmten Wiederherstellungspunkt (RP) zurück (optional, standardmäßig wird der letzte RP verwendet) | Führen Sie einmalig eine inkrementelle Replikation von der Quell-VM zur Replik durch |
| 3 | Verbinden Sie die VM-Replik über Netzwerkzuordnung mit einem new Netzwerk (optional) |
Verbinden Sie die VM-Replik mit einem isolated Netzwerk mittels Netzwerkzuordnung (optional) |
| 4 | Ändern Sie die statische IP-Adresse der Replik mit Re-IP (optional) | |
| 4A | Schalten Sie die Quell-VM aus (optional) | — |
| 5 | Schalten Sie die Replik ein | |
| 6 | Versetzen Sie die Replik in den Status „Failover“ | |
Wie Sie sehen können, unterscheiden sich der zweite und dritte Punkt zwischen dem Produktions- und dem Test-Workflow. Sie können die Replikation von einer Quelle im Testmodus ausführen, während die Quelle läuft. In den meisten Fällen funktioniert die Quelle im Katastrophenfall nicht mehr, sodass keine Replikation durchgeführt werden kann. Die Netzwerke für die VM-Verbindung können bei der Konfiguration eines Standortwiederherstellungs-Auftrags in den Netzwerkzuordnungen für den Produktionsmodus und den Testmodus separat definiert werden.
Die Bereinigung nach dem Failover-Test wird nach der Ausführung eines Standortwiederherstellungs-Auftrags im Testmodus durchgeführt. Die VM-Replik wird ausgeschaltet und über einen Schnappschuss in den Zustand vor dem Failover zurückversetzt (vor der Durchführung einer Failover-Aktion wird ein Schnappschuss der VM-Replik erstellt). Die Replik wird dann vom Failover-Zustand in ihren normalen Zustand versetzt, und die Replikation vom Quellobjekt zur Replik wird wieder aktiviert.
Funktionen zum Testen der Disaster Recovery in NAKIVOs Standortwiederherstellung
Lassen Sie uns kurz die wichtigsten Punkte der Testfunktionen in NAKIVOs Standortwiederherstellung durchgehen.
1. Checking the actions included in testing
Überprüfen Sie die Logik der Aktionen im Standortwiederherstellungs-Auftrag. Vergewissern Sie sich, dass die Aktionen in der richtigen Reihenfolge angeordnet sind und keine Endlosschleife bilden. Sie können die Auftragsoptionen des Site Recovery-Jobs bearbeiten, solange der Job nicht ausgeführt wird: Ändern Sie die Reihenfolge der Aktionen, fügen Sie Aktionen hinzu, entfernen Sie Aktionen oder bearbeiten Sie die Aktionsoptionen nach Bedarf.
2. Checking networking
Überprüfen Sie, ob Ihr Netzwerk ordnungsgemäß funktioniert. Zwischen einem Produktionsstandort und einem Disaster Recovery-Standort (DR-Standort) kann eine VPN-Verbindung verwendet werden, diese Verbindung darf jedoch im Normalbetrieb nicht periodisch unterbrochen werden. Das Netzwerk am DR-Standort muss ebenfalls störungsfrei funktionieren. Überprüfen Sie die Einstellungen für „Network Mapping“ und „Re-IP“, die Sie zur Konfiguration von Failover und Failback verwendet haben. Wenn eine VM für das falsche Netzwerk konfiguriert ist, kann möglicherweise keine Netzwerkverbindung hergestellt werden. Dasselbe gilt für die IP-Einstellungen.
3. Setting the test schedule
Das Testen von Standortwiederherstellung-Aufträgen kann in den Auftragsoptionen für Standortwiederherstellung-Aufträge geplant werden. Öffnen Sie die Weboberfläche Ihrer NAKIVO Backup & Replication-Instanz. Klicken Sie im linken Bereich mit der rechten Maustaste auf den Namen Ihres Auftrags und wählen Sie im Kontextmenü „ Edit “ aus.

Die Vorteile von NAKIVOs Standortwiederherstellung
Comprehensive DR orchestration and automation. Mit der Standortwiederherstellung können Sie Disaster-Recovery-Pläne mit einem hohen Automatisierungsgrad umsetzen. Sie können die Reihenfolge der VM-Wiederherstellung unter Berücksichtigung der VM-Abhängigkeiten festlegen, sodass die Wiederherstellung im Katastrophenfall so effizient wie möglich erfolgt.Flexibility to accommodate the needs of various businesses. Sie können je nach Bedarf mehrere Standortwiederherstellungs-Aufträge erstellen.-
Built into the data protection solution. Standortwiederherstellung ist eine Funktion, die in NAKIVO Backup & Replication enthalten ist und zusammen mit dem übrigen umfassenden Funktionsumfang des Produkts zur Verfügung steht; Sie müssen keine separate Lizenz für Standortwiederherstellung erwerben. Mit dieser Lösung lassen sich alle Aktivitäten zur Datensicherheit und Disaster Recovery über eine zentrale Oberfläche verwalten. Significant savings compared to other DR solutions. NAKIVO Backup & Replication mit dem integrierten Tool für Standortwiederherstellung ist eine kostengünstige Lösung. Das Produkt überzeugt die Anwender weiterhin mit nützlichen neuen Funktionen und behält dabei die gleichen erschwinglichen Preise bei – insbesondere im Vergleich zu den Mitbewerbern auf dem Markt für Disaster Recovery.
Die Auswahl an Aktionen, die in Standortwiederherstellungs-Aufträgen integriert werden können, ermöglicht die Erstellung verschiedener Wiederherstellungs-Workflows, die individuell auf unterschiedliche Situationen zugeschnitten sind.




































