# Hyper-V Replica: Disaster Recovery für Zweigstellen & Cloud

TL;DR / Management Summary Während Live Migration (Artikel 508) auf Hochverfügbarkeit im lokalen Cluster zielt, fokussiert Hyper-V Replica auf das Disaster Recovery (DR) über weite Strecken. Es spiegelt VM-Änderungen asynchron (alle 30s, 5m oder 15m) auf einen entfernten Host oder Cluster. Ein Senior Admin nutzt Hyper-V Replica als günstige Alternative zu SAN-Replikation, um kritische Workloads an einen Zweitstandort zu sichern – ganz ohne Shared-Storage-Zwang.


# 1. Einführung & Architektur

Die asynchrone Spiegelung.

Hyper-V Replica erstellt eine identische Kopie der VHDX-Dateien am Zielort und sendet kontinuierlich die Änderungen (Log-Files).

# Schlüsselmerkmale

# Architektur-Übersicht (Mermaid)

graph LR
    subgraph "Primary Site"
    VM_PROD[VM Active] -->|Change Tracking| LOG[HRL - Hyper-V Replica Log]
    end

    subgraph "DR Site"
    VM_REPL[VM Standby]
    end

    LOG -->|HTTPS / WAN| VM_REPL

# 2. Einrichtung in der Praxis

Vom Host zum Replikationspartner.

# Schritt 1: Replica am Ziel-Host aktivieren

Set-VMReplicationServer -ReplicationEnabled $true `
    -AllowedAuthenticationType Certificate `
    -CertificateThumbprint "ABCD123..." `
    -DefaultStorageLocation "D:\ReplicaStorage"

# Schritt 2: Replikation für eine VM starten

Enable-VMReplication -VMName "SRV-ERP-01" `
    -ReplicaServerName "HV-DR-01.firma.local" `
    -ReplicaServerPort 443 `
    -AuthenticationType Certificate `
    -CompressionEnabled $true `
    -RecoveryHistory 24 # Hält 24 Stunden History vor

# 3. Deep Dive: Failover-Typen

Was passiert im Ernstfall?

  1. Test Failover: Erstellt eine temporäre VM am Zielort zum Testen (Netzwerk isoliert!). Beeinflusst die Produktion nicht.
  2. Planned Failover: Geplanter Wechsel (z.B. Wartung am Hauptstandort). Die VM wird am Quellort sauber heruntergefahren, letzte Änderungen übertragen und am Ziel gestartet.
  3. Unplanned Failover: Der Ernstfall. Datenverlust ist möglich (RPO bis zu 15 Min).

# 4. Day-2 Operations: Netzwerk-Injektion

Andere IP am DR-Standort.

Wenn die DR-Site ein anderes Subnetz hat, würde die VM nach dem Starten nicht erreichbar sein.


# 5. Troubleshooting & “War Stories”

Wenn der Sync-Strom versiegt.

# Top 3 Fehlerbilder

  1. Symptom: “Replication is critical” (Sync steht).

    • Ursache: Zu viele Änderungen innerhalb der VM (z.B. Defragmentierung oder Database-Reindex), die die WAN-Bandbreite sprengen.
    • Lösung: Replikationsintervall vergrößern oder Bandbreite erhöhen.
  2. Symptom: Zertifikats-Fehler.

    • Ursache: Das Zertifikat auf dem Replica-Server ist abgelaufen oder die Root-CA wird nicht vertraut.
    • Lösung: Zertifikat erneuern und via PowerShell neu zuweisen.
  3. Symptom: Snapshots (Checkpoints) innerhalb der VM verhindern die Replikation.

    • Lösung: Hyper-V Replica und Standard-Snapshots beißen sich oft. Nutzen Sie lieber die integrierte History von Replica.

# “War Story”: Der “Double-Zero” Hero

Ein mittelständischer Kunde hatte einen Totalausfall seines Haupt-Serverraums (Wasserschaden). Die Rettung: Alle 10 Kern-VMs wurden via Hyper-V Replica alle 5 Minuten an eine kleine Zweigstelle (verbunden via VDSL) repliziert. Das Ergebnis: Innerhalb von 30 Minuten konnten die Mitarbeiter via RDP auf den Ersatz-Knoten in der Zweigstelle weiterarbeiten. Der Datenverlust betrug weniger als 5 Minuten. Kosten: Null Euro Zusatz-Lizenz, da Windows Server Datacenter bereits vorhanden war.


# 6. Monitoring & Reporting

Dashboard der Sicherheit.

# PowerShell Health Report

# Zeigt den Status aller replizierten VMs
Get-VM | Get-VMReplication | Select-Object Name, State, Health, LReplTime, Mode

# 7. Fazit & Empfehlung

Hyper-V Replica ist das beste “kostenlose” DR-Feature für Windows Admins.


# Anhang: Cheatsheet

Aufgabe Befehl
Status prüfen Measure-VMReplication
Test Failover Start-VMFailover -AsTest
Sync manuell triggern Resume-VMReplication
Statistik Reset Reset-VMReplicationStatistics

# Referenzen