Allgemeine Fragen zu Azure Site Recovery

Site Recovery unterstützt Ihre Strategie für Geschäftskontinuität und Notfallwiederherstellung, indem die Replikation von virtuellen Azure-Computern zwischen Regionen, von lokalen virtuellen Computern und physischen Servern in Azure und von lokalen Computer in ein sekundäres Rechenzentrum orchestriert und automatisiert werden. Weitere Informationen

Nein, Azure Site Recovery unterstützt keine Docker-Workloads, die auf VMs ausgeführt werden. Um diese virtuellen Computer mit Site Recovery zu schützen, schließen Sie die Datenträger aus, auf denen Docker installiert ist.

Mit verschiedenen Maßnahmen stellt Site Recovery die Datenintegrität sicher. Zwischen allen Diensten wird mithilfe des HTTPS-Protokolls eine sichere Verbindung hergestellt. Dadurch wird sichergestellt, dass Malware oder externe Entitäten die Daten nicht manipulieren können. Eine weitere Maßnahme ist die Verwendung von Prüfsummen. Bei der Datenübertragung zwischen Quelle und Ziel werden Prüfsummen zwischen den Daten berechnet. So wird eine konsistente Datenübertragung sichergestellt.

Azure unterstützt keine beständigen MAC-Adressen. Daher kann Software mit MAC-basierten Lizenzmodellen nicht für die Migration aus der lokalen Umgebung in Azure oder die Notfallwiederherstellung verwendet werden.

Nein, Azure Site Recovery unterstützt derzeit keine kurzlebigen Datenträger.

Microsoft Recovery Services-Agent wird zum Konfigurieren/Registrieren bei Site Recovery-Diensten und zum Überwachen der Integrität aller Komponenten verwendet. Diese Komponente ist einer der grundlegenden Bausteine der gesamten lokalen Azure Site Recovery-Infrastruktur. Es hilft Ihnen, Ihre Arbeitslasten von einem lokalen Standort aus auf eine andere Azure-Region zu replizieren und im Falle eines Desasters auf Azure umzuschalten.

Ja, Site Recovery unterstützt dedizierte und gemeinsam genutzte Infrastrukturmodelle.

Nein. Die Mandantenidentität bleibt anonym. Ihre Mandanten benötigen keinen Zugriff auf das Site Recovery-Portal. Nur der Administrator des Dienstanbieters interagiert mit dem Portal.

Wenn Sie in Azure replizieren, werden Anwendungsdaten an den Azure-Speicher gesendet, jedoch nicht an den Azure Site Recovery-Dienst. Daten werden während der Übertragung verschlüsselt (HTTPS) und bleiben in Azure verschlüsselt.

Nein. Azure rechnet direkt mit dem Dienstanbieter ab. Mandantenspezifische Rechnungen müssen von den Dienstanbietern selbst erstellt werden.

Nein. Die Daten werden in einem Azure-Speicherkonto Ihres Abonnements repliziert. Wenn Sie einen Test-Failover (Disaster Recovery Drill) oder einen tatsächlichen Failover durchführen, erstellt Site Recovery automatisch virtuelle Maschinen in Ihrem Abonnement.

Ja.

Wir unterstützen Bereitstellungen auf der Grundlage von Azure Pack, Cloud Platform System und System Center (2012 und höher). Erfahren Sie mehr zur Integration von Azure Pack und Site Recovery.

Nein, Sie können virtuelle Hyper-V-Computer nur in Azure replizieren.

Sehen Sie sich die Details unter Azure Site Recovery – Preise an.

Sie können den Preisrechner verwenden, um die Kosten für die Verwendung von Site Recovery zu schätzen.

Für eine detaillierte Kostenschätzung können Sie das Bereitstellungsplanertool für VMware oder Hyper-V ausführen und den Kostenschätzungsbericht verwenden.

Ja, es gibt zusätzliche Gebühren für die Verwendung des Cachespeicherkontos beim Replizieren virtueller Computer mithilfe von Site Recovery. Die Kosten für das Cache-Speicherkonto bleiben gleich, wenn der Replikatspeicher vom Typ verwaltete Festplatten oder unverwaltete Festplatten ist.

Ja. Für jede geschützte Instanz fallen in den ersten 31 Tagen keine Azure Site Recovery-Gebühren an. Wenn Sie beispielsweise in den letzten sechs Monaten zehn Instanzen geschützt haben und eine elfte Instanz mit Azure Site Recovery verbinden, fallen in den ersten 31 Tagen keine Gebühren für die elfte Instanz an. Für die ersten zehn Instanzen werden weiterhin Azure Site Recovery-Gebühren berechnet, da sie seit mehr als 31 Tage geschützt werden.

Ja. Auch wenn Site Recovery während der ersten 31 Tage einer geschützten Instanz kostenlos ist, können für Azure Storage, Speichertransaktionen und Datenübertragungen Gebühren anfallen. Auch für einen wiederhergestellten virtuellen Computer können Azure-Computegebühren anfallen.

Es gibt keine separaten Kosten für den Notfallwiederherstellungs-Drilldown. Nachdem die VM nach dem Test-Failover erstellt wurde, fallen Computegebühren an.

Nein. Site Recovery fängt replizierte Daten nicht ab und besitzt keine Informationen dazu, was auf Ihren virtuellen Computern oder physischen Servern ausgeführt wird. Replikationsdaten werden zwischen lokalen Hyper-V-Hosts, VMware-Hypervisoren oder physischen Servern und Azure-Speicher an Ihrem sekundären Standort ausgetauscht. Site Recovery hat keine Möglichkeit, diese Daten abzufangen. Nur die Metadaten, die zum Orchestrieren von Replikation und Failover erforderlich sind, werden an den Site Recovery-Dienst gesendet.

Site Recovery ist nach ISO 27001:2013, 27018, HIPAA und DPA zertifiziert und durchläuft gerade die Prüfungen für SOC2 und FedRAMP JAB.

Ja. Durch die Erstellung eines Site Recovery-Tresors in einer Region wird sichergestellt, dass alle Metadaten, die wir zum Ermöglichen und Orchestrieren von Replikation und Failover benötigen, innerhalb der geografischen Grenzen dieser Region bleiben.

Für virtuelle Computer und physische Server wird bei der Replikation in Azure sowohl die Verschlüsselung während der Übertragung als auch die Verschlüsselung ruhender Daten (in Azure) unterstützt.

Ja, das TLS 1.2-Protokoll wird standardmäßig für das Azure-zu-Azure-Site Recovery-Szenario erzwungen.

Auf den replizierten Elementen installierte Mobility-Agents kommunizieren ausschließlich über TLS 1.2 mit dem Prozessserver. Die Kommunikation zwischen dem Konfigurationsserver und Azure sowie zwischen dem Prozessserver und Azure kann jedoch über TLS 1.1 oder 1.0 erfolgen. Befolgen Sie die Anweisungen zum Erzwingen von TLS 1.2 für alle von Ihnen eingerichteten Konfigurations- und Prozessserver.

Die gesamte Kommunikation zwischen den Microservices von Azure Site Recovery erfolgt über das TLS 1.2-Protokoll. Site Recovery verwendet Sicherheitsanbieter, die im System (BS) konfiguriert sind, und verwendet das neueste verfügbare TLS-Protokoll. Sie müssen TLS 1.2 explizit in der Registrierung aktivieren, und dann wird Site Recovery mit der Verwendung von TLS 1.2 zur Kommunikation mit Diensten beginnen.

Sie können die verwaltete Identität des Recovery Services-Tresors aktivieren, indem Sie zur Identity-Einstellung (Identität) wechseln. Nachdem der Tresor bei Microsoft Entra ID registriert wurde, können Sie zu Ihren Speicherkonten wechseln und dem Tresor die folgenden Rollen zuweisen:

• Resource Manager-basierte Speicherkonten (Standard):
  • Mitwirkender
  • Mitwirkender an Speicherblobdaten
• Resource Manager-basierte Speicherkonten (Premium):
  • Mitwirkender
  • Besitzer von Speicherblobdaten
• Klassische Speicherkonten:
  • Mitwirkender von klassischem Speicherkonto
  • Klassische Dienstrolle „Speicherkonto-Schlüsseloperator“

Das Cachespeicherkonto wird bei verwalteten Identitäten nicht unterstützt.

Azure Site Recovery verfolgt keine Änderungen an der virtuellen Quellmaschine außerhalb des Quellbetriebssystems. Wenn Sie beispielsweise Azure für die Azure-Replikation verwenden und die Größe der Quell-VM ändern, wird die Änderung der Größe der Quell-VM nicht auf die Ziel-VM repliziert.

• Virtuelle Azure-Computer: Site Recovery kann jede Workload replizieren, die auf einem unterstützten virtuellen Azure-Computer ausgeführt wird.
• Virtuelle Hyper-V-Computer: Mit Site Recovery kann jede Workload, die auf einer Hyper-V-VM ausgeführt wird, geschützt werden.
• Physische Server: Mit Site Recovery können physische Server unter Windows oder Linux geschützt werden.
• Virtuelle VMware-Computer: Mit Site Recovery kann jede Workload, die auf einer VMware-VM ausgeführt wird, geschützt werden.

Mit Site Recovery können die meisten Workloads geschützt werden, die auf einer unterstützten VM oder einem physischen Server ausgeführt werden. Site Recovery bietet Unterstützung für die anwendungsorientierte Replikation, sodass für Apps ein „intelligenter Zustand“ wiederhergestellt werden kann. Eine Integration in Microsoft-Anwendungen wie SharePoint, Exchange, Dynamics, SQL Server und Active Directory ist möglich. Zudem kann Site Recovery eng in die Produkte führender Anbieter, z. B. Oracle, SAP, IBM und Red Hat, eingebunden werden. Erfahren Sie mehr über den Schutz von Workloads.

Ja. Wenn Sie Site Recovery zum Orchestrieren von Replikation und Failover in Zweigstellen verwenden, erhalten Sie eine einheitliche Orchestrierung und Anzeige der Workloads aller Zweigstellen an einer zentralen Stelle. Sie können problemlos über Ihren Hauptsitz für alle Zweigstellen Failover ausführen und die Notfallwiederherstellung verwalten, ohne die Zweigstellen zu besuchen.

Ja, Site Recovery unterstützt die Notfallwiederherstellung für virtuelle Azure-Computer zwischen Azure-Regionen. Überprüfen Sie allgemeine Fragen zur Notfallwiederherstellung für virtuelle Azure-Computer. Wenn Sie zwischen zwei Azure-Regionen auf demselben Kontinent replizieren möchten, verwenden Sie unser Azure to Azure Disaster Recovery-Angebot. Sie müssen weder einen Konfigurationsserver/Prozessserver noch ExpressRoute-Verbindungen einrichten.

Ja, Site Recovery unterstützt die Notfallwiederherstellung von lokalen virtuellen VMware-Computern. Lesen Sie häufig gestellte Fragen zur Notfallwiederherstellung von virtuellen VMware-Computern.

Ja, Site Recovery unterstützt die Notfallwiederherstellung von lokalen virtuellen Hyper-V-Computern. Lesen Sie häufig gestellte Fragen zur Notfallwiederherstellung von virtuellen Hyper-V-Computern.

Ja, Site Recovery unterstützt die Notfallwiederherstellung von lokalen physischen Servern unter Windows und Linux in Azure. Erfahren Sie mehr über die Anforderungen für die Notfallwiederherstellung für Azure. Die physischen Server werden nach dem Failover als virtuelle Computer in Azure ausgeführt. Das Failback von Azure auf einen lokalen physischen Server wird derzeit nicht unterstützt. Ein Failback kann nur auf einen virtuellen VMware-Computer ausgeführt werden.

Nein, Azure Site Recovery unterstützt nicht das Verschieben eines Recovery Services-Tresors, in dem geschützte VMs gehostet werden.

Azure Site Recovery repliziert Daten über einen öffentlichen Endpunkt in ein Azure Storage-Konto oder verwaltete Datenträger. Die Replikation kann jedoch auch über ein Site-to-Site-VPN ausgeführt werden. Die Site-to-Site-VPN-Konnektivität ermöglicht Organisationen, vorhandene Netzwerke mit Azure oder Azure-Netzwerken miteinander zu verbinden. Site-to-Site-VPN erfolgt über IPSec-Tunneling über das Internet, wobei vorhandene lokale Edge-Netzwerkgeräte und Netzwerk-Appliances in Azure genutzt werden, z. B. native Funktionen wie Azure Virtual Private Network (VPN) Gateway oder Optionen von Drittanbietern wie Check Point CloudGaurd, Palo Alto NextGen Firewall.

• Private Konnektivität über das öffentliche Internet zu Microsoft Edge
• Recovery Services-Tresore für Sicherheit mit privaten Endpunkten konfiguriert
• Replikation über die VPN-Verbindung des Kunden
• Einfacher Übergang zu „Zukünftiger Status“
• Keine SLA und potenziell höhere Latenz
• Lokales VPN-Gerät erforderlich

Unser Partner Riverbed bietet eine detaillierte Anleitung zum Arbeiten mit Azure Site Recovery. Lesen Sie den entsprechenden Lösungsleitfaden.

Ja, ExpressRoute kann zum Replizieren virtueller Computer zu Azure verwendet werden.

• Azure Site Recovery repliziert Daten über einen öffentlichen Endpunkt in ein Azure Storage-Konto. Wenn Sie ExpressRoute für die Site Recovery-Replikation verwenden möchten, müssen Sie Microsoft-Peering oder ein vorhandenes öffentliches Peering (für neue Verbindungen veraltet) einrichten.
• Microsoft-Peering ist die empfohlene Routingdomäne für die Replikation.
• Die Replikation über privates Peering wird nur unterstützt, wenn für den Tresor private Endpunkte aktiviert sind.
• Falls Sie VMware-Computer oder physische Computer schützen, stellen Sie sicher, dass die Netzwerkanforderungen auch für den Konfigurationsserver erfüllt sind. Der Konfigurationsserver muss für die Orchestrierung der Site Recovery-Replikation eine Verbindung mit bestimmten URLs herstellen können. Für diese Verbindung kann ExpressRoute nicht verwendet werden.
• Nachdem für die VMs ein Failover auf ein virtuelles Azure-Netzwerk ausgeführt wurde, können Sie mithilfe der Einrichtung des privaten Peering für das virtuelle Azure-Netzwerk darauf zugreifen.

Die Verwendung von Speicherkonten als Zielspeicher wird von Azure Site Recovery nicht unterstützt. Es wird empfohlen, stattdessen verwaltete Datenträger als Zielspeicher für Ihre Computer zu verwenden. Verwaltete Datenträger unterstützen nur den LRS-Typ für die Datenresilienz.

• Hyper-V: Hyper-V-VMs können alle 30 Sekunden (außer bei Storage Premium) oder alle 5 Minuten repliziert werden.
• Virtuelle Azure-Computer, virtuelle VMware-Computer, physische Server: Hier ist keine Replikationshäufigkeit relevant. Die Replikation ist fortlaufend.

Eine erweiterte oder verkettete Replikation wird nicht unterstützt. Fordern Sie dieses Feature im Feedbackforum.

Dies wird nicht unterstützt. Fordern Sie dieses Feature im Feedbackforum.

Dies wird unterstützt, wenn Sie virtuelle VMware-Computer und virtuelle Hyper-V-Computer mithilfe des Azure-Portals in Azure replizieren.

Dynamische Datenträger werden beim Replizieren virtueller Hyper-V-Computer und beim Replizieren virtueller VMware-Computer und physischer Computer in Azure unterstützt. Der Betriebssystem-Datenträger muss ein Basisdatenträger sein.

Ja. In folgenden Artikeln erfahren Sie mehr über die Drosselung der Bandbreite:

• Kapazitätsplanung für die Replikation von VMware-VMs und physischen Servern
• Kapazitätsplanung zum Replizieren virtueller Hyper-V-Computer in Azure

Ja. Azure Site Recovery für Linux-Betriebssysteme unterstützt benutzerdefinierte Anwendungsskripts für App-Konsistenz. Das benutzerdefinierte Skript mit Prä- und Post-Optionen wird vom Azure Site Recovery Mobility Agent während der App-Konsistenz verwendet. Im Folgenden sind die Schritte zum Aktivieren aufgeführt.

1. Melden Sie sich beim Computer als Root-Benutzer an.

2. Wechseln Sie in das Installationsverzeichnis des Mobilitäts-Agent von Azure Site Recovery. Der Standardwert ist „/usr/local/ASR“.
   # cd /usr/local/ASR

3. Wechseln Sie im Installationsverzeichnis in „VX/Scripts“.
   # cd VX/scripts

4. Erstellen Sie ein Bash-Shellskript mit dem Namen „customscript.sh“ mit Ausführungsberechtigungen für den Root-Benutzer.
   a. Das Skript sollte die Befehlszeilenoptionen „--pre“ und „--post“ (beachten Sie die doppelten Bindestriche) unterstützen.
   b. Wenn das Skript mit der „--pre“-Option aufgerufen wird, sollte es die Eingabe/Ausgabe der Anwendung einfrieren, und wenn es mit der „--post“-Option aufgerufen wird, sollte es die Eingabe/Ausgabe der Anwendung reaktivieren.
   c. Eine Beispielvorlage –
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Fügen Sie die Eingabe-/Ausgabebefehle zum Einfrieren und Reaktivieren in „--pre“- und „--post“-Schritten für Anwendungen hinzu, die App-Konsistenz erfordern. Sie können wahlweise ein weiteres Skript hinzufügen, das diese Befehle angibt, und von „customscript.sh“ aus mit „--pre“- und „--post“-Option aufrufen.

Eine Replikationsrichtlinie definiert die Einstellungen für den Aufbewahrungsverlauf von Wiederherstellungspunkten. Die Richtlinie definiert auch die Häufigkeit anwendungskonsistenter Momentaufnahmen. Standardmäßig erstellt Azure Site Recovery eine neue Replikationsrichtlinie mit folgenden Standardeinstellungen:

• Ein Tag für den Aufbewahrungsverlauf von Wiederherstellungspunkten.
• Keine App-konsistenten Momentaufnahmen.

Ein absturzkonsistenter Wiederherstellungspunkt enthält die Daten auf dem Datenträger, als ob Sie das Netzkabel während der Momentaufnahme vom Server abgezogen hätten. Der absturzkonsistente Wiederherstellungspunkt enthält nichts, was sich zum Zeitpunkt der Momentaufnahme im Arbeitsspeicher befand.

Heutzutage können die meisten Anwendungen aus absturzkonsistenten Momentaufnahmen gut wiederhergestellt werden. Ein absturzkonsistenter Wiederherstellungspunkt ist ausreichend für Betriebssysteme ohne Datenbank und Anwendungen wie Dateiserver, DHCP-Server und Druckerserver.

Site Recovery erstellt alle 5 Minuten einen absturzkonsistenten Wiederherstellungspunkt.

Anwendungskonsistente Wiederherstellungspunkte werden aus anwendungskonsistenten Momentaufnahmen erstellt. Anwendungskonsistente Wiederherstellungspunkte erfassen dieselben Daten wie absturzkonsistente Momentaufnahmen. Zudem werden alle Daten im Arbeitsspeicher und alle laufenden Transaktionen erfasst.

Durch diesen zusätzlichen Inhalt sind anwendungskonsistente Momentaufnahmen am stärksten involviert, und ihre Ausführung dauert am längsten. Anwendungskonsistente Wiederherstellungspunkte werden für Betriebssysteme mit Datenbank und Anwendungen wie SQL Server empfohlen.

Anwendungskonsistente Wiederherstellungspunkte erfassen alle Daten im Arbeitsspeicher und in Prozessen. Da Wiederherstellungspunkte diese Daten erfassen, benötigen Sie ein Framework wie den Volumeschattenkopie-Dienst unter Windows, um die Anwendung in einen inaktiven Status zu versetzen. Wird der Erfassungsprozess häufig ausgeführt, kann sich dies auf die Leistung auswirken, wenn die Workload bereits hoch ist. Wir raten davon ab, für anwendungskonsistente Wiederherstellungspunkte bei Nicht-Datenbankworkloads ein kleines Intervall zu verwenden. Auch für die Datenbankworkloads reicht eine Stunde aus.

Site Recovery kann einen anwendungskonsistenten Wiederherstellungspunkt mit einer Mindesthäufigkeit von einmal pro Stunde erstellen.

Sehen Sie sich das folgende Beispiel für eine Replikationsrichtlinie an, um zu verstehen, wie Site Recovery Wiederherstellungspunkte generiert. Diese Replikationsrichtlinie verfügt über einen Wiederherstellungspunkt mit einem Aufbewahrungszeitfenster von einem Tag und einem Intervall von einer Stunde für App-konsistente Momentaufnahmen.

Site Recovery erstellt alle 5 Minuten einen absturzkonsistenten Wiederherstellungspunkt. Der Benutzer kann diese Häufigkeit nicht ändern. Für die letzten zwei Stunden können Sie zwischen 24 absturzkonsistenten und zwei App-konsistenten Punkten wählen. Im Laufe der Zeit löscht Site Recovery alle Wiederherstellungspunkte, die älter als zwei Stunden sind, und speichert nur einen Wiederherstellungspunkt pro Stunde für bis zu 24 Stunden des Tages.

Der folgende Screenshot veranschaulicht dieses Beispiel. Im Screenshot:

• Innerhalb der letzten zwei Stunden sind Wiederherstellungspunkte im Intervall von fünf Minuten vorhanden.

• Für den Zeitraum nach den letzten zwei Stunden bewahrt Site Recovery nur einen Wiederherstellungspunkt pro Stunde auf.

  

Der älteste Wiederherstellungspunkt, den Sie verwenden können, ist 15 Tage (verwalteter Datenträger) bzw. drei Tage (nicht verwalteter Datenträger) alt.

Nein. Site Recovery bewahrt alle Ihre vorherigen Wiederherstellungspunkte auf. Abhängig vom Aufbewahrungszeitfenster für Wiederherstellungspunkte ersetzt Site Recovery den ältesten Punkt nur, wenn er neue Punkte generiert. Aufgrund des Problems kann Site Recovery keine neuen Wiederherstellungspunkte generieren. Bis neue Wiederherstellungspunkte vorhanden sind, bleiben alle alten Punkte erhalten, auch wenn das Aufbewahrungszeitfenster erreicht ist.

Navigieren Sie zu Site Recovery-Tresor>Site Recovery-Infrastruktur>Replikationsrichtlinien. Wählen Sie die Richtlinie aus, die Sie bearbeiten möchten, und speichern Sie die Änderungen. Alle Änderungen gelten auch für alle vorhandenen Replikationen.

Der erste Wiederherstellungspunkt, der generiert wird, ist eine vollständige Kopie. Alle nachfolgenden Wiederherstellungspunkte enthalten nur die geänderten Daten (Deltaänderungen).

Ja, wenn Sie die Aufbewahrungsdauer von einem auf drei Tage erhöhen, speichert Site Recovery die Wiederherstellungspunkte für zusätzliche zwei Tage. Durch die zusätzliche Zeit fallen Speicherkosten an, da zwölf zusätzliche Wiederherstellungspunkte gespeichert werden müssen, wenn die Aufbewahrungsdauer von einem auf drei Tage erhöht wird. Beispiel: Ein einzelner Wiederherstellungspunkt weist Deltaänderungen von 10 GB auf, bei pro-GB-Kosten von $0,16 pro Monat. Die zusätzlichen Kosten betragen 1,60 US-Dollar × 12 pro Monat.

Sie können auf die Azure-VMs über eine sichere Internetverbindung, über eine Site-to-Site-VPN-Verbindung oder über Azure ExpressRoute zugreifen. Sie müssen eine Reihe von Vorbereitungen treffen, um eine Verbindung herzustellen. Weitere Informationen

Azure ist auf Resilienz ausgelegt. Site Recovery ist bereits für ein Failover zu einem sekundären Azure-Rechenzentrum (gemäß Azure-SLA) konzipiert. Wenn dies der Fall ist, stellen wir sicher, dass Ihre Metadaten und Tresore innerhalb der gleichen geografischen Region bleiben, die Sie für Ihren Tresor ausgewählt haben.

Sie können ein ungeplantes Failover vom sekundären Standort auslösen. Site Recovery benötigt keine Verbindung mit dem primären Standort, um das Failover auszuführen.

Ein Failover erfolgt nicht automatisch. Sie initiieren Failover mit einem Mausklick im Portal, oder Sie können die Site Recovery-PowerShell verwenden, um ein Failover auslösen. Ein Failback ist eine einfache Aktion im Site Recovery-Portal.

Zum Automatisieren können Sie den lokalen Orchestrator oder Operations Manager verwenden, um einen Fehler bei virtuellen Computern zu erkennen und dann das Failover mithilfe des SDK auszulösen.

• Weitere Informationen .
• Weitere Informationen .
• Weitere Informationen zum Ausfall von virtuellen VMware-Computern und physischen Servern

Ja, Sie können über die Wiederherstellung an einem alternativen Speicherort ein Failback auf einen anderen Host als Azure ausführen.

• Für virtuelle VMware-Computer
• Für virtuelle Hyper-V-Computer

Wenn ein Failover eines Computer vom Quellspeicherort zum Zielspeicherort ausgeführt wurde, stehen Ihnen drei Optionen zur Auswahl. Alle drei dienen unterschiedlichen Zwecken:

1. Migration abschließen bedeutet, dass Sie nicht mehr zum Quellspeicherort zurückkehren. Sie haben zu der Zielregion migriert und sind nun fertig. Durch Klicken auf „Migration abschließen“ werden intern „Commit“ und dann „Replikation deaktivieren“ ausgelöst.
2. Commit bedeutet, dass es sich hierbei nicht um das Ende des Replikationsprozesses handelt. Das Replikationselement und die gesamte Konfiguration bleiben erhalten, und Sie können zu einem späteren Zeitpunkt Erneut schützen wählen, um die Replikation ihrer Computer zurück in die Quellregion zu ermöglichen.
3. Replikation deaktivieren deaktiviert die Replikation und entfernt alle zugehörigen Konfigurationen. Dies wirkt sich nicht auf den bereits vorhandenen Computer in der Zielregion aus.

Ja. Sie können Site Recovery-Workflows mithilfe von REST-API, PowerShell oder Azure SDK automatisieren. Derzeit unterstützte Szenarien für die Bereitstellung von Site Recovery mit PowerShell:

• Replizieren von Hyper-V-VMs in VMM-Clouds in Azure PowerShell Resource Manager
• Replizieren von Hyper-V-VMs ohne VMM in Azure PowerShell Resource Manager
• Replizieren von VMware in Azure mit PowerShell Resource Manager

Nein. Die Einstellung des AzureRM-Moduls hat keine Auswirkungen auf die Funktion von automatischen Site Recovery-Updates. Für das interne Runbook sind keine Änderungen erforderlich, und die stattdessen verwendete REST-API funktioniert mit dem Automation-Konto weiterhin wie beabsichtigt.

Hier finden Sie Informationen zu neuen Updates und hier zum Rollup.

Nächste Schritte

• Lesen Sie die Site Recovery-Übersicht