Microsoft AZ-801: Notfallwiederherstellung und Geschäftskontinuität — Lernleitfaden

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Teil des Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Das Design für Notfallwiederherstellung (DR) und Geschäftskontinuität (BC) beginnt mit der Quantifizierung von zwei Metriken: Recovery Time Objective (RTO) und Recovery Point Objective (RPO). RTO gibt an, wie schnell ein Dienst wiederhergestellt werden muss; RPO definiert, wie viel Datenverlust (in Zeit ausgedrückt) akzeptabel ist. Diese Werte bestimmen die Wahl der Technologie, die Topologie und die Kosten. Ein niedriges RTO begünstigt Orchestrierung und Automatisierung (Azure Site Recovery-Wiederherstellungspläne, Runbooks und vorab erstellte Zielressourcen). Ein niedriges RPO begünstigt kontinuierliche Replikation (ASR) oder synchrone Commits (SQL Always On), während ein höheres RPO auf periodische Backups (Azure Backup, Windows Server Backup) zurückgreifen kann. Multi-VM-Konsistenzgruppen und anwendungskonsistente Snapshots gewährleisten die transaktionale Integrität über mehrere VMs hinweg, wenn ein striktes RPO erforderlich ist. Die Wahl des Tresors (Recovery Services-Tresor vs. Backup-Tresor), das Design der Replikationsrichtlinien und die Backup-Zeitplanung werden so gewählt, dass diese Ziele erreicht werden, ohne das Budget zu überschreiten.

Azure Site Recovery: Hyper-V, VMware, Orchestrierung und Konsistenz

Azure Site Recovery (ASR) bietet kontinuierliche Replikation und orchestriertes Failover/Failback für lokale VMware-, Hyper-V- und Azure IaaS-VMs.

Hyper-V-Schutz

Replikationsrichtlinie: Definiert den RPO-Schwellenwert, die Aufbewahrungsdauer von Wiederherstellungspunkten und die Häufigkeit von anwendungskonsistenten Snapshots. Legen Sie beispielsweise den RPO-Schwellenwert auf 15 Minuten fest, bewahren Sie Wiederherstellungspunkte für 24–72 Stunden für ein Point-in-Time-Rollback auf und erstellen Sie alle 1–4 Stunden anwendungskonsistente Snapshots. Richtlinien steuern die Drosselung der Bandbreite und die Komprimierung; Multi-VM-Konsistenz kann für zusammengehörige VMs aktiviert werden, damit deren Wiederherstellungspunkte aufeinander abgestimmt sind.
Wiederherstellungspunkte: ASR erstellt kontinuierlich absturzkonsistente Punkte und zusätzliche anwendungskonsistente Punkte, wenn das VSS-Quiescing erfolgreich ist. Die Aufbewahrung ermöglicht es Ihnen, frühere Punkte auszuwählen, um logische Beschädigungen oder Ransomware-Angriffe zu beheben.
Testfailover: Unterbrechungsfreie Übungen validieren Runbooks, die Startreihenfolge und das Networking. Verwenden Sie ein isoliertes VNet, geben Sie Test-Eingabewerte an (z. B. DNS-IPs) und stellen Sie sicher, dass die Namensauflösung isoliert ist. Die Produktionsreplikation läuft unbeeinflusst weiter, und nach der Validierung werden die Testartefakte durch eine Bereinigung entfernt. Richten Sie im Voraus ein Netzwerk-Mapping ein und testen Sie die NIC-Zuweisungen, um IP-Konflikte zu vermeiden.

VMware-Schutz

Konfigurationsserver: Die lokale Appliance, die sich beim Recovery Services-Tresor registriert, das vCenter/ESXi-Inventar erkennt, die Replikation koordiniert und Mobility Service-Agents per Push verteilt. Er ist die Steuerungsebene für den VMware-Schutz.
Prozessserver: Befindet sich anfangs normalerweise auf derselben Maschine wie der Konfigurationsserver; er führt die Änderungsnachverfolgung, Komprimierung, Verschlüsselung und Datenübertragung nach Azure durch. Scale-Out-Prozessserver werden hinzugefügt, um den Durchsatz zu erhöhen und den Dateneingang nahe an den geschützten Hosts zu positionieren, um die Latenz zu minimieren.
Masterzielserver: Wird für das Failback von Azure zu VMware verwendet. Er empfängt replizierte Änderungen während des erneuten Schutzes (Re-Protect) und bietet eine Landezone, damit Sie Workloads wieder in vSphere wiederherstellen können. Dimensionieren Sie den Speicher für die aggregierte Schreibrate während des Failbacks und stellen Sie sicher, dass der Netzwerkdurchsatz den Spitzenwerten der Re-Sync-Fenster entspricht.
Mobility Service: Wird in jeder geschützten VM installiert, um Festplattenänderungen zu erfassen. Halten Sie Anmeldeinformationen oder Push-Mechanismen auf dem neuesten Stand und überwachen Sie den Agenten-Zustand im Tresor.

Orchestrierung und Konsistenz

Wiederherstellungspläne: Deklarative Runbooks für die Notfallwiederherstellung, die Gruppierungen, die Startreihenfolge, manuelle Genehmigungsschritte und Automatisierungsaufgaben definieren. Verwenden Sie Azure Automation-Runbooks, um NSGs neu zu konfigurieren, DNS-Einträge zu aktualisieren, Anwendungs-Caches aufzuwärmen oder SQL-Skripte auszuführen. Weisen Sie logische Gruppen wie „Daten“-, „App“- und „Web“-Ebenen zu und fügen Sie Pausen zur Validierung ein.
Runbooks: Automatisieren Sie umgebungsspezifische Aufgaben wie das Umschalten von Traffic-Manager-Endpunkten, das Skalieren von PaaS-Abhängigkeiten oder das Deaktivieren der lokalen Überwachung während eines Failovers, um Fehlalarme zu reduzieren. Parametrisieren Sie sie für Test- im Vergleich zu Produktionsfailovern.
Multi-VM-Konsistenzgruppen: Aktivieren Sie diese für Ebenen, die dieselbe Schreibreihenfolge haben (z. B. App-Server und Datenbank-Logschreiber). Dies gewährleistet einen konsistenten Point-in-Time über mehrere VMs hinweg; es tauscht Durchsatz gegen Korrektheit und sollte auf wirklich voneinander abhängige VMs beschränkt werden.

Auswirkungen auf RTO/RPO

Strenges RPO: Bevorzugen Sie ASR mit aggressiver Replikation und anwendungskonsistenten Snapshots, für hohen Durchsatz dimensionierte Prozessserver und dedizierte Replikationsnetzwerke. Ziehen Sie für Datenbanken einen synchronen Commit mit Always On innerhalb einer Metropolregion in Betracht.
Strenges RTO: Erstellen Sie Ziel-VNets, Subnetze und Load Balancer im Voraus; verwenden Sie Wiederherstellungspläne mit Automatisierung, um manuelle Schritte zu eliminieren. Führen Sie regelmäßig Testfailover durch, um einen Basiswert für das erwartete RTO zu ermitteln.

Sicherung und Wiederherstellung: Azure Backup (MARS, MABS/DPM), Tresore und Windows Server-Sicherung

Azure Backup bietet zeitpunktbezogenen Schutz für lokale und Azure-Workloads. Wählen Sie den richtigen Agenten und Tresortyp basierend auf Workload und Funktionen.

MARS-Agent (Microsoft Azure Recovery Services-Agent)

Sicherungsrichtlinie: Konfigurieren Sie bis zu drei tägliche Sicherungen mit granularer Aufbewahrung (täglich/wöchentlich/monatlich/jährlich) im Recovery Services-Tresor. Wählen Sie die Speicherredundanz (LRS oder GRS) und richten Sie die Aufbewahrung an den Compliance-Anforderungen aus, während Sie das Wachstum des Tresors kontrollieren. Planen Sie die Sicherung außerhalb von Spitzen-I/O-Zeiten und aktivieren Sie bei Bedarf die Netzwerkdrosselung.
Systemstatussicherung: Wird mit MARS für Windows Server unterstützt, um AD, Registrierung, COM+ und Startdateien zu schützen. Verwenden Sie diese für die Wiederherstellung von Domänencontrollern (autoritativ/nicht autoritativ) oder zur Reparatur des Betriebssystems ohne eine vollständige Sicherung auf Image-Ebene.
Online-Wiederherstellung: Stellen Sie Dateien/Ordner über „Durchsuchen“ oder „Suchen“ wieder her. Instant Restore bindet den Wiederherstellungspunkt als Volume ein, um ein schnelles Kopieren von Dateien zu ermöglichen. Sie können an ursprünglichen oder alternativen Pfaden wiederherstellen und sogar auf einem anderen Server, indem Sie die Tresoranmeldeinformationen auf dem Ziel verwenden und sich am Tresor authentifizieren.
Passphrase-Verwaltung: Der MARS-Agent verwendet eine vom Kunden verwaltete Verschlüsselungs-Passphrase (AES-256), die lokal generiert und gespeichert wird; Microsoft hat sie zu keinem Zeitpunkt. Der Verlust der Passphrase macht eine Wiederherstellung unmöglich. Bewahren Sie sie an einem sicheren, gesicherten Ort auf (z. B. als versiegeltes, HSM-gestütztes Key Vault-Geheimnis mit RBAC). Um sie zu rotieren, beenden Sie den Schutz und schützen Sie die Daten mit einer neuen Passphrase erneut. Aktivieren Sie die Funktionen „Vorläufiges Löschen“ (Soft Delete) und „Sicherheits-PIN“ im Tresor, um sich vor böswilligem Beenden/Löschen zu schützen.

Azure Backup mit MABS/DPM und IaaS

Bare-Metal-Recovery (BMR)-Sicherung: Verwenden Sie Microsoft Azure Backup Server (MABS) oder System Center DPM, um eine BMR für Windows Server zu erstellen. Dies ermöglicht eine vollständige Neuinstallation des Servers auf neuer Hardware oder einer VM, indem von WinRE oder einem Installationsmedium gebootet und auf das BMR-Image verwiesen wird.
Wiederherstellung an einem alternativen Speicherort: Bei Datei-/Datensicherungen über MARS/MABS/DPM stellen Sie die Daten an einem alternativen Pfad oder auf einem anderen Server wieder her, um ein Überschreiben der Quelldaten zu vermeiden. Bei Sicherungen von Azure IaaS-VMs (in einem Recovery Services-Tresor) können Sie auf einer neuen VM wiederherstellen, Datenträger auf einer vorhandenen VM wiederherstellen oder Datenträger ersetzen. Wenn die regionsübergreifende Wiederherstellung (Cross-Region Restore) für den Tresor aktiviert ist, können Sie bei regionalen Ausfallszenarien in der gekoppelten Region wiederherstellen.
SQL und SAP HANA in Azure-VMs: Schützen Sie diese mit Workload-spezifischen Erweiterungen, um anwendungskonsistente Sicherungen und eine granulare Datenbankwiederherstellung zu erreichen. Richten Sie die Frequenz der Protokollsicherung am RPO (z. B. 15 Minuten) und die Aufbewahrung an den Compliance-Anforderungen aus.

Windows Server-Sicherung (WSB)

Bare-Metal-Recovery: WSB kann eine BMR (Systemvolumes und Systemstatus) erstellen. Speichern Sie diese auf einem dedizierten Datenträger oder Volume, um mehrere Wiederherstellungspunkte zu erhalten. Bei Zielen auf Netzwerkfreigaben wird nur die neueste Version beibehalten. Die Wiederherstellung erfolgt durch Booten von einem Windows-Medium in WinRE und Auswahl von „Systemabbild-Wiederherstellung“.
Systemstatussicherung: Ermöglicht eine schnelle Wiederherstellung von AD DS, Registrierung und Startdateien. Nützlich für Domänencontroller und Konfigurationsserver. Kombinieren Sie dies mit geplanten Dateisicherungen für eine breitere Abdeckung.
Zeitplanung: Verwenden Sie die WSB-MMC oder

undefined

, um tägliche/stündliche Sicherungen zu planen. Wählen Sie zwischen VSS Full und Copy, je nachdem, ob Sie Anwendungsprotokolle kürzen möchten. Stellen Sie sicher, dass die Sicherungsfenster Spitzen-I/O-Zeiten vermeiden, und überprüfen Sie die Katalogintegrität (

undefined

Tresortypen: Recovery Services-Tresor vs. Backup-Tresor

Recovery Services-Tresor (RSV): Der traditionelle Tresor für Sicherungen von Azure-VMs, MARS-Agent-Sicherungen, MABS/DPM, Azure Files-Sicherungen, SQL Server in Azure-VMs und SAP HANA in Azure-VMs. Er hostet auch ASR-Metadaten. Er unterstützt Funktionen wie vorläufiges Löschen (Soft Delete), Sicherheits-PIN und regionsübergreifende Wiederherstellung (Cross-Region Restore), sofern zutreffend.
Backup-Tresor: Der modernisierte Tresor für bestimmte Azure-native Workloads wie Azure Disks-Sicherung, Azure Blobs-Sicherung und flexible Server von Azure Database for PostgreSQL. Er verwendet Azure RBAC für die Autorisierung auf Verwaltungsebene, unterstützt kundenseitig verwaltete Schlüssel, Unveränderlichkeitsoptionen und lässt sich zum Schutz kritischer Operationen in Resource Guard integrieren. Er hostet keine ASR-Metadaten und ersetzt nach heutigem Stand den RSV nicht für MARS/MABS/DPM oder die meisten IaaS-VM-Sicherungen.

HA auf Anwendungsebene: SQL Always On und DFS Replication

Einige Workloads erfordern eine native Replikation, die das DR auf Hypervisor-Ebene je nach RTO/RPO ergänzt oder ersetzt.

Always On Availability Groups (AGs)

Synchrones vs. asynchrones Commit: Beim synchronen Commit wird gewartet, bis das sekundäre Replikat das Protokoll festgeschrieben hat, bevor die Transaktion auf dem primären Replikat committet wird. Dies führt zu einem Datenverlust von nahezu null (niedriges RPO) auf Kosten von Latenz und Durchsatz. Einsatz bei Verbindungen mit geringer Latenz (typischerweise im Metro-Bereich). Beim asynchronen Commit wird nicht auf das sekundäre Replikat gewartet, was eine höhere Leistung über WAN-Verbindungen mit potenziellem Datenverlust bei einem Failover (höheres RPO) ermöglicht.
Bedingungen für automatisches Failover: Ein automatisches Failover erfordert mindestens zwei synchrone Commit-Replikate, bei denen das automatische Failover aktiviert und die synchronisiert sind. Windows Server Failover Clustering überwacht den Zustand von Knoten/Diensten; die flexible Failover-Richtlinie von SQL Server definiert Stufen für Fehlerbedingungen (von Prozessabstürzen bis zu schwerwiegenden I/O-Problemen). Die Datenbank-Zustandserkennung kann aktiviert werden, um ein Failover zu erzwingen, wenn der Zustand der primären Datenbank fragwürdig ist. Das Quorum- und Witness-Design stellt sicher, dass ein Split-Brain-Szenario verhindert wird. Stellen Sie sicher, dass DNS- und Listener-IPs am Wiederherstellungsstandort bereit sind, um eine schnelle Wiederverbindung der Clients zu ermöglichen.

DFS Replication (DFSR)

Replikationsgruppen und Verbindungen: Eine Replikationsgruppe ist ein Satz von Servern, die einen oder mehrere replizierte Ordner replizieren. Verbindungen definieren die Topologie (Full Mesh, Hub-Spoke) sowie den Zeitplan und die Bandbreitendrosselung. Verwenden Sie Hub-Spoke für Skalierbarkeit und eine einfachere Fehlerbehebung.
Staging-Bereich: DFSR verwendet pro repliziertem Ordner einen Staging-Bereich, um Delta-Dateien für die Remote Differential Compression (RDC) zu speichern. Dimensionieren Sie den Staging-Bereich mindestens auf die Größe Ihrer größten Datei und typischerweise auf das 1- bis 2-fache des erwarteten täglichen Datenaufkommens. Eine Unterdimensionierung verursacht übermäßige Bereinigungen und Wiederholungsversuche, was sich negativ auf RPO/RTO auswirkt.
Konfliktauflösung: DFSR ist Multi-Master. Wenn gleichzeitige Bearbeitungen auftreten, verwendet DFSR Versionsvektoren und Zeitstempel; der letzte Schreibvorgang gewinnt („Last Writer Wins“) und die unterlegene Kopie wird in den Ordner „ConflictAndDeleted“ verschoben (dessen Speicherplatz durch ein Kontingent geregelt wird). Um anfängliche Konflikte während des Seedings zu vermeiden, legen Sie nur für die Erstsynchronisierung ein primäres Mitglied fest. Verwenden Sie für unidirektionale Szenarien schreibgeschützte replizierte Ordner. Überwachen Sie Rückstände (Backlogs) mit dfsrdiag und passen Sie die Zeitpläne an, um das RPO zu erfüllen.

Architekturauswirkungen von RTO/RPO und integrierten DR-Plänen

Aggressives RPO: Bevorzugen Sie synchrone Datenbankreplikation oder ASR mit hochfrequenter Änderungsverarbeitung und anwendungskonsistenten Snapshots. Isolieren Sie den Replikationsverkehr und skalieren Sie Prozessserver. Verwenden Sie Konsistenzgruppen für mehrere VMs nur sparsam für eng gekoppelte Ebenen.
Aggressives RTO: Stellen Sie Ziel-VNets, Subnetze, Route Tables und NSGs vorab bereit; skripten Sie IP-Neuzuweisungen und DNS-Updates über Wiederherstellungspläne und Runbooks. Halten Sie Golden Images und VM-Größen an SKUs mit verfügbarer Kapazität gebunden. Führen Sie Test-Failover vierteljährlich und nach wesentlichen Änderungen durch.
Schichtenweiser Datenschutz: Kombinieren Sie ASR (schnelle Dienstwiederherstellung) mit Azure Backup (Point-in-Time-Rollback), um sowohl katastrophale Ausfälle als auch logische Beschädigungen zu bewältigen. Koppeln Sie für Domänencontroller System State-Sicherungen (MARS oder WSB) mit ASR/Test-Failovern, um die USN-Rollback-sichere Wiederherstellung zu validieren. Für Dateidienste bietet DFSR standortinterne/standortübergreifende Hochverfügbarkeit, ergänzt durch Azure Backup für eine Ransomware-resistente Wiederherstellung.

Praktisches Problemszenario

Fabrikam, Inc., ein globaler Hersteller, betreibt eine gemischte Umgebung: Hyper-V für ERP-Anwendungsebenen, VMware für Legacy-Middleware, SQL Server 2019 AGs für Datenbanken und große Windows-Dateiserver, die DFS Replication verwenden. Die Geschäftsanforderungen schreiben ein RTO ≤ 1 Stunde und ein RPO ≤ 15 Minuten für das ERP-System vor; andere Workloads können ein RTO von 4 Stunden und ein RPO von 24 Stunden tolerieren.

Klassifizieren der Workloads und RTO/RPO-Ziele

ERP-Anwendungs-/Web-VMs und SQL AGs werden als Tier 1 (RTO 1h, RPO 15m) eingestuft. Middleware und Dateidienste sind Tier 2/3.
Warum: Stellt sicher, dass die strengsten Ziele die Entscheidungen für Replikation und Orchestrierung bestimmen.

Implementieren von ASR für Hyper-V-ERP-Ebenen

Installieren Sie den ASR Provider auf Hyper-V-Hosts und registrieren Sie diese bei einem Recovery Services-Tresor. Erstellen Sie eine Replikationsrichtlinie mit einem RPO-Schwellenwert von 15 Minuten, anwendungskonsistenten Snapshots im Stundentakt und einer Aufbewahrungsdauer von 48 Stunden. Aktivieren Sie eine Konsistenzgruppe für mehrere VMs über die ERP-Anwendungsserver, die Transaktionen mit dem SQL-Listener teilen.
Warum: Kontinuierliche Replikation und anwendungskonsistente Prüfpunkte erreichen das 15-Minuten-RPO und halten gleichzeitig die Ebene konsistent.

Implementieren von ASR für VMware-Middleware

Stellen Sie einen Konfigurationsserver on-premises bereit, mit einem am selben Standort befindlichen Prozessserver, der für die projizierte Änderungsrate dimensioniert ist. Fügen Sie am größten Standort einen Scale-Out-Prozessserver hinzu. Installieren Sie den Mobility Service auf den geschützten VMs. Bereiten Sie einen Master-Zielserver für ein eventuelles Failback vor.
Warum: Die ASR-Architektur für VMware bietet eine zuverlässige Erfassung von Änderungen und einen kontrollierten Pfad für das Failback, wenn der On-Premises-Standort wiederhergestellt ist.

Orchestrieren mit Wiederherstellungsplänen und Runbooks

Erstellen Sie einen Wiederherstellungsplan, der SQL (Daten), dann die ERP-Anwendungsebene und schließlich die Web-Ebenen gruppiert. Fügen Sie Azure Automation-Runbooks ein, um: NSGs neu zu konfigurieren, private DNS-Zonen so zu aktualisieren, dass sie auf Azure-IPs verweisen, und Traffic Manager-Endpunkte umzuschalten. Fügen Sie einen manuellen Validierungsschritt hinzu, bevor die Web-Ebene online geschaltet wird.
Warum: Automatisierung verkürzt das RTO und reduziert menschliche Fehler während einer Krise, indem die korrekte Startreihenfolge und der richtige Netzwerkzustand erzwungen werden.

Schützen von SQL Server mit standortspezifisch abgestimmten AGs

Halten Sie die primäre und eine sekundäre Instanz im synchronen Commit-Modus innerhalb der Metro-Region für ein RPO nahe Null; halten Sie eine entfernte sekundäre DR-Instanz im asynchronen Commit-Modus. Konfigurieren Sie ein automatisches Failover zwischen den synchronen Replikaten mit aktivierter Erkennung des Datenbankzustands. Integrieren Sie die AG-Failover-Schritte in den ASR-Wiederherstellungsplan, um eine übergreifende Transparenz zu gewährleisten.
Warum: Synchrone AGs liefern das niedrigste RPO für die Datenbankebene; ASR stellt die Orchestrierung des Standorts darum herum bereit.

Schichtenweises Sichern mit Azure Backup

Für on-premises Windows-Server, die Datei- und Systemstatusschutz erfordern, stellen Sie den MARS-Agenten bereit und konfigurieren Sie Richtlinien mit täglichen Backups und einer Aufbewahrung von 30/52/7 (täglich/wöchentlich/jährlich). Speichern und schützen Sie die Verschlüsselungs-Passphrase in Azure Key Vault (HSM-gestützt). Verwenden Sie MABS, um BMR-Images für kritische Anwendungsserver zu erfassen, um bei Bedarf einen vollständigen Neuaufbau zu ermöglichen. Aktivieren Sie Soft Delete (vorläufiges Löschen) und eine Sicherheits-PIN für den Tresor.
Warum: Die Point-in-Time-Wiederherstellung schützt vor logischer Beschädigung und Ransomware und ergänzt das schnelle Failover von ASR.

Härten von DFSR und Sichern von Dateidiensten

Überprüfen Sie die Topologie der Replikationsgruppe (Hub-and-Spoke), stellen Sie sicher, dass die Staging-Bereiche auf das 1,5-fache der täglichen Änderungsrate dimensioniert sind, und passen Sie die Zeitpläne an, um eine nahezu echtzeitnahe Replikation innerhalb der Region aufrechtzuerhalten. Schützen Sie Freigaben mit MARS/MABS für die Langzeitaufbewahrung und für Wiederherstellungstests an alternativen Standorten.
Warum: Eine korrekte Abstimmung von DFSR erfüllt die täglichen Verfügbarkeitsanforderungen, während Backups die Sicherheit eines Rollbacks bieten.

Validieren mit Test-Failovern und dokumentierten Runbooks

Führen Sie vierteljährlich ASR-Test-Failover in ein isoliertes VNet durch, validieren Sie die ERP-Funktionalität anhand maskierter Daten und messen Sie das RTO. Führen Sie Wiederherstellungsübungen durch: Wiederherstellungen an einem alternativen Speicherort mit MARS und eine vollständige BMR-Wiederherstellung aus MABS in eine Sandbox.
Warum: Regelmäßige Übungen beweisen die Funktionsfähigkeit des Plans, decken Abweichungen auf und liefern der Führungsebene einen Nachweis für die Einhaltung von RTO/RPO.

Dieses Design erfüllt die Ziele von Fabrikam: ASR liefert ein RTO von unter einer Stunde, SQL AGs im synchronen Modus minimieren das RPO für Datenbanken, und Azure Backup mit MARS/MABS bietet eine sichere Point-in-Time-Wiederherstellung sowie die Möglichkeit zum vollständigen Neuaufbau von Maschinen. Wiederherstellungspläne und Runbooks beseitigen Unklarheiten bei Vorfällen, und DFSR bleibt für die betriebliche Kontinuität zwischen den Backups optimiert.

← Hyper-V · Alle Domänen · Identitäts- und Zugriffsverwaltung für hybride Umgebungen →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →