# Veeam Replication Disaster Recovery – Die Königsdisziplin der Business Continuity

TL;DR / Management Summary Veeam Replication ist die primäre Strategie für geschäftskritische Anwendungen (Tier 0/Tier 1), die einen RTO im Minutenbereich erfordern. Im Gegensatz zu herkömmlichen Backups, die Daten nur wiederherstellen, hält die Replikation eine Live-Kopie (Replica VM) in einem Standby-Zustand auf einem Remote-Standort bereit. Der sofortige Failover-Mechanismus eliminiert zeitaufwendige Wiederherstellungsprozesse. Ein korrekt konfiguriertes Replikations-Setup hängt von der optimalen Platzierung von Proxies und der strikten Einhaltung der Transportmodi ab, insbesondere wenn WAN Accelerators im Spiel sind.

# 1. Einführung & Architektur

Veeam Backup & Replication unterscheidet klar zwischen Backup (Langzeitarchivierung, GFS-Retention) und Replication (Near-Real-Time DR). Der Fokus der Replikation liegt auf Geschwindigkeit und der Fähigkeit, eine komplette VM am Zielort in einem konsistenten, bootfähigen Zustand zu halten.

# Warum brauchen wir das?

• Problemstellung aus der Praxis: Im Falle eines Standortausfalls (Brand, Stromausfall, Ransomware-Vorfall) zählt jede Minute. Ein Restore einer 10 TB SQL-VM von einem Backup-Repository kann Stunden dauern (hoher RTO).
• Replication als Lösung: Veeam verwendet Changed Block Tracking (CBT) von VMware oder Hyper-V, um nach dem initialen Seeding nur die geänderten Blöcke inkrementell zum DR-Standort zu übertragen. Der Failover-Prozess ist lediglich das Hochfahren der bereits vorhandenen und konsistenten Replica VM.

# Vergleich mit Alternativen

# Architektur-Diagramm (Kernel-Sicht & Komponenten)

Die Replikations-Pipeline ist komplex und involviert mehrere Komponenten. Die Leistung steht und fällt mit der Lokalität der Proxies zum jeweiligen Datastore.

graph TD
    subgraph Quellstandort (Production)
        A[vSphere Host] --> B(Quell-VM/Datastore)
        C(Veeam Proxy Source) --> D(CBT/Snapshot Engine)
        D --> E[Veeam Backup Server - Orchestrierung]
    end

    subgraph WAN
        E --> F{WAN Accelerator - Source Side}
        F --> G[WAN]
        G --> H{WAN Accelerator - Target Side}
    end

    subgraph Zielstandort (DR Site)
        H --> I(Veeam Proxy Target)
        I --> J[vSphere Host DR]
        J --> K(Replica VM/Datastore)
    end

    C --> |Transport Mode| D
    I --> |Restore/Write| K

    style A fill:#f9f,stroke:#333
    style J fill:#f9f,stroke:#333
    style E fill:#ccf,stroke:#333

Kernel-Sicht (vSphere): Veeam startet mit einem Snapshot der Quell-VM. Der Veeam Proxy (im bevorzugten Transportmodus Direct SAN Access oder Virtual Appliance Mode) greift direkt auf die VMDK-Blöcke zu. Das Kernel-Modul vmkctl (oder Hyper-V VSS-Writer) liefert die Information über geänderte Blöcke (CBT). Diese geänderten Blöcke werden dann an den Ziel-Proxy übertragen, der sie über den ESXi-Host auf den Ziel-Datastore schreibt. Dies ist ein hochoptimierter I/O-Prozess, der den Gast-OS-Layer umgeht.

# 2. Installation & Grundkonfiguration (Praxis)

Wir richten ein robustes Replikations-Setup ein, das auf Performance und Skalierbarkeit ausgelegt ist.

# Voraussetzungen

1. Lizenzierung: Stellen Sie sicher, dass Ihre Veeam Edition (Standard, Enterprise, Enterprise Plus) die gewünschten Funktionen (z.B. WAN Accelerator, CDP) unterstützt.
2. Netzwerk: Latenz zwischen Standorten < 100ms empfohlen. Dedicated VLANs für Replikationstraffic. Firewall-Regeln für Ports 2500-5000 (Data Mover).
3. Ressourcen: Proxies sollten genug vCPUs (min. 4) und RAM (min. 8 GB) haben, besonders wenn Komprimierung/Deduplizierung auf dem Proxy läuft.

# Schritt-für-Schritt Setup (Der “Happy Path”)

Der Fokus liegt hier auf der Auswahl der richtigen Transport-Architektur.

# A. Proxy-Konfiguration und Transport-Optimierung

Der häufigste Fehler in großen Umgebungen ist die Verwendung des Network (NBD) Transportmodus, was die ESXi-Management-Netzwerke überlastet. Wir erzwingen effizientere Modi:

# 1. Konfiguration auf dem Quell-Proxy (Windows/Linux)
# Wir stellen sicher, dass der Proxy die VDDK-Verbindungen optimal nutzt.
# Wichtig: Der Proxy MUSS Zugriff auf die SAN LUNs oder den NFS-Mount des Quell-Datastores haben.

# PowerShell (auf dem VBR Server oder Proxy, wenn Veeam PowerShell Modul geladen ist)
# Wir setzen den Proxy auf 'Direct SAN Access' bevorzugt und verbieten NBD für kritische Jobs.
# (Dies erfordert, dass die Proxy VM sich auf einem Host befindet, der die LUNs sieht,
# ODER dass der physische Proxy über FC/iSCSI mit dem SAN verbunden ist.)

$proxy = Get-VBRServer | Where-Object {$_.Name -eq "VBR-Proxy-Source-01"}
Set-VBRProxy -Proxy $proxy -TransportMode 'DirectSAN'
Set-VBRProxy -Proxy $proxy -FailoverToNetwork $false 
# ACHTUNG: Das Erzwingen des Modus stoppt den Job, wenn SAN Access nicht möglich ist. Besser in großen Umgebungen!

# B. Seeding und Mapping (Initialisierung großer VMs)

Bei VMs > 500 GB und einer WAN-Bandbreite < 100 Mbps ist Initial Seeding zwingend erforderlich, um die erste vollständige Replikation zu beschleunigen.

1. Führen Sie eine einmalige Backup-Kopie der Quell-VM auf einen externen Datenträger (Exabeam, USB-Disk) durch.
2. Transportieren Sie das Laufwerk physisch zum DR-Standort.
3. Importieren Sie das Backup am DR-Standort in ein temporäres Repository.
4. Erstellen Sie den Replikations-Job und wählen Sie im Schritt Seeding die Option “Map replicas to existing backups”.

Dies stellt sicher, dass die erste vollständige Kopie nicht über die WAN-Leitung, sondern lokal vom DR-Repository geschrieben wird, wodurch der RTO drastisch sinkt und die WAN-Belastung auf die Deltas reduziert wird.

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning

# 3.1 Transport-Optimierung (Der I/O-Engpass)

Der primäre Engpass ist meist nicht die WAN-Leitung, sondern die Fähigkeit des Proxys, Daten schnell vom Quell-Datastore zu lesen oder auf den Ziel-Datastore zu schreiben.

• Direct SAN Access (FC/iSCSI): Beste Wahl. Der Proxy liest Blöcke direkt vom SAN. Entlastet den ESXi-Host vollständig vom Lese-Overhead.
• Virtual Appliance (HotAdd): Gute Wahl. Die Proxy-VM mountet die VMDKs der Quell-VM. Benötigt jedoch, dass die Proxy-VM auf einem der ESXi-Hosts läuft, die das Volume sehen.
• Network (NBD): Sollte nur für unwichtige VMs oder als Fallback genutzt werden. Daten laufen über das Management-Netzwerk des ESXi-Hosts, was dessen Ressourcen stark belastet.

# 3.2 WAN Accelerator Caching und Sizing

Der WAN Accelerator ist kein einfacher Kompressor; er ist ein globaler, blockbasierter Cache, der Daten-Fingerabdrücke speichert.

• Cache Sizing: Standardempfehlung ist 10% der zu replizierenden Gesamtgröße aller Quell-VMs. Für 20 TB Daten sollten Sie einen 2 TB Cache vorsehen.
• Deduplizierungseffizienz: Die Effizienz hängt stark von der Homogenität der Daten ab. Server-OS-Images (z.B. 50 Windows Server) profitieren enorm (Deduplizierungsrate > 90%). Datenbank- oder verschlüsselte Daten profitieren kaum.

# 3.3 CDP (Continuous Data Protection)

Für RPOs im Sekundenbereich ist Veeam CDP die Lösung. Dies erfordert jedoch eine strikte Einhaltung der vSphere-Anforderungen (vSphere 7.0+ und das VAIO-Framework).

• Flow: CDP arbeitet nicht mit Snapshots, sondern nutzt den I/O Filter (VAIO) im Kernel des ESXi-Hosts, um jeden Write-Vorgang asynchron zum Ziel-Host zu spiegeln.
• Latenz-Grenzwert: CDP-Policies erfordern oft eine extrem niedrige Latenz zwischen Quell- und Ziel-Hosts (< 5 ms). CDP ist in der Regel auf Standorte mit Fibre-Channel-Verbindungen oder sehr schnelle Metro-Ethernet-Verbindungen beschränkt.

# Hardening & Security

• Least Privilege: Verwenden Sie separate dedizierte Service Accounts für Veeam in vCenter/Hyper-V mit den absolut minimal notwendigen Berechtigungen (Details in der Veeam User Guide). Nutzen Sie keine administrator@vsphere.local Accounts für Jobs.
• Traffic Encryption: Stellen Sie sicher, dass die Option “Encrypt network traffic” im Job-Wizard aktiviert ist, insbesondere wenn Sie über ungesicherte WAN-Verbindungen replizieren. (Performance-Impact ist messbar, aber inakzeptabel gering im Vergleich zum Sicherheitsrisiko).
• Replica Permissions: Beschränken Sie streng, wer die Replica VMs auf dem DR-Standort sehen/starten darf, um versehentliches Starten der VM außerhalb des Failover-Prozesses zu verhindern (siehe “Zombie Replica” in Abschnitt 5).

# 4. Day-2 Operations: Wartung & Alltag

# Typische Tasks

# Online-Vergrößerung des Ziel-Datenträgers

Während ein Backup-Repository einfach auf eine größere LUN umziehen kann, erfordert die Replikation Vorsicht.

1. Stop Job: Deaktivieren Sie den Replikations-Job.
2. Target Volume Resize: Erweitern Sie den Datastore auf dem DR-Standort im vCenter.
3. Veeam Rescan: Führen Sie einen Rescan der Infrastruktur-Komponenten in Veeam durch.
4. Job Edit: Im Replikations-Job unter Virtual Machines > Target Datastore prüfen, ob die neue Kapazität korrekt erkannt wird.
5. Restart Job: Reaktivieren Sie den Job. Der nächste Lauf wird die Replica VM erkennen und die Metadaten anpassen.

# Migration der Replica auf neue Hardware (Quick Migration)

Wenn Sie den DR-Standort von älteren Hosts auf neue, leistungsstärkere ESXi-Hosts migrieren:

• Verwenden Sie Veeams Quick Migration Tool.
• Dies ermöglicht die Migration der bereits existierenden Replica VM auf einen neuen Host/Datastore im DR-Standort, ohne den Replikations-Job neu seeden zu müssen. Der Job erkennt beim nächsten Lauf, dass sich der Speicherort der Replica geändert hat.

# Automatisierung (PowerShell & Runbooks)

Der kritischste Aspekt der Day-2 Ops ist der orchestrated Failover und Failback. Dies wird selten manuell gemacht, sondern über ein DR-Runbook in Veeam (DR Orchestrator) oder über PowerShell/Ansible angetriggert.

# Beispiel: Auslesen des Zustands aller Replikations-Jobs
# Wichtig für Monitoring und automatisierte Alerts

# Veeam PowerShell Modul muss geladen sein
$ReplicationJobs = Get-VBRJob | Where-Object {$_.JobType -eq "Replica"}

foreach ($Job in $ReplicationJobs) {
    $Status = $Job.GetLastResult()
    Write-Host "Job: $($Job.Name) - Status: $($Status) - Last Run: $($Job.GetLastRun())"

    # Prüfen, ob eine Failover-Session aktiv ist
    $FailoverSessions = Get-VBRFailoverSession | Where-Object {$_.JobName -eq $Job.Name -and $_.Status -eq "InProgress"}
    if ($FailoverSessions.Count -gt 0) {
        Write-Host "!!! ACHTUNG: Aktive Failover-Session für Job $($Job.Name) erkannt. System läuft im DR-Modus." -ForegroundColor Yellow
    }
}

# 5. Troubleshooting & “War Stories”

In der Hitze des Gefechts entscheiden die richtigen Analysetools.

# Top 3 Fehlerbilder

# 1. Symptom A: Replication Job Failt mit “Cannot track changes”

• Fehlermeldung: Failed to process VM. Error: Failed to track changes. CBT is not enabled or corrupt.
• Ursache: Das Changed Block Tracking (CBT) des Hypervisors ist inkonsistent, oft nach einem abrupten Host-Neustart oder einem manuellen vMotion der Quell-VM.
• Lösung:
  1. Deaktivieren Sie den Replikations-Job in Veeam.
  2. Löschen Sie manuell den Snapshot, den Veeam zur inkrementellen Erfassung nutzt (falls vorhanden).
  3. Setzen Sie CBT über die vSphere-API oder das Veeam GUI (Rechtsklick auf VM > Disable CBT) zurück.
  4. Aktivieren Sie den Job. Der nächste Lauf ist ein Full-Rescan (aber nicht zwingend ein Full-Copy, da Veeam die Blöcke vergleicht).

# 2. Symptom B: Katastrophale Performance nach Failover-Test

• Symptom: Der Failover-Test auf dem DR-Standort führt zu extrem schlechter I/O-Leistung auf der Replica-VM.
• Ursache: Die Replica-VM läuft auf den Replica Restore Points. Diese sind Snapshots der Replika. Wenn Sie die VM in diesem Zustand im Betrieb lassen, schreibt sie auf die Delta-Disks der Snapshots, was zu Performance-Einbrüchen führt (Snapshot-Tax).
• Lösung: Stellen Sie sicher, dass nach einem erfolgreichen Test/Failover entweder ein Commit Replica (Finalisierung des Failover) oder ein Undo Failover (zurück zum Ursprungszustand) durchgeführt wird, um die Snapshot-Kette auf der Replica zu konsolidieren.

# 3. Symptom C: Failback schlägt fehl wegen Divergenz (Die Zombie Replica)

• Anekdote (War Story): Wir hatten den Fall, dass ein Junior-Admin während einer Standortwartung die Replica-VM auf dem DR-Standort manuell im vCenter gestartet hat (“Nur um zu sehen, ob sie bootet”). Nach der Wartung wurde sie wieder heruntergefahren.
• Folge: Die Replica-VM war jetzt dirty und hatte Datenänderungen, die Veeam nicht nachverfolgt hat (Divergenz). Beim Versuch des Failbacks erkannte Veeam die Inkonsistenz und verweigerte den Failback, da es keine sichere Delta-Erstellung mehr garantieren konnte.
• Lösung: Wenn Divergenz eintritt und kein vollständiges Re-Seeding möglich ist: Manuelles Re-Seeding der Quell-VM zum DR-Standort und Neubeginn des Replikations-Jobs. Prävention ist alles: Strikte Berechtigungen, die den manuellen Start der Replica-VMs verhindern, sind obligatorisch.

# Troubleshooting Flow für Replication-Performance

graph TD
    A[Replikations Job ist langsam] --> B{Transport Modus Direct SAN?};
    B -- Nein --> C[Upgrade auf Direct SAN oder HotAdd erzwingen.];
    B -- Ja --> D{Proxy Auslastung hoch? (CPU > 80%)};
    D -- Ja --> E[Fügen Sie dem Proxy mehr vCPUs hinzu ODER verteilen Sie Jobs auf zusätzliche Proxies.];
    D -- Nein --> F{WAN Accelerator Effizienz niedrig?};
    F -- Ja --> G[WAN Accelerator Cache prüfen/vergrößern ODER Komprimierung/Deduplizierungseinstellungen prüfen.];
    F -- Nein --> H{Storage Latenz am Quell-Host hoch?};
    H -- Ja --> I[Prüfen Sie `esxtop` auf Disk Latency (`DAVG`/`KAVG`). Storage-Probleme beheben.];
    H -- Nein --> J[Prüfen Sie die vSphere CBT Integrität. Gegebenenfalls CBT resetten (Symptom A).];

# 6. Monitoring & Alerting

Replikation muss kontinuierlich überwacht werden, da ein schleichender Fehler im DR-Standort erst im Ernstfall auffällt.

# Metriken (Key Performance Indicators)

1. Replica RPO Actual vs. Target: Die wichtigste Metrik. Wie alt ist der letzte konsistente Wiederherstellungspunkt? (Wenn CDP läuft: Die Zeit zwischen dem letzten I/O-Spiegel und der aktuellen Zeit).
2. Latency (WAN Accel): Die gemessene Latenz und der Durchsatz des Replizierens. Ein drastischer Abfall des Durchsatzes deutet auf eine WAN-Leitungsüberlastung hin.
3. Target Datastore Free Space: Replicas benötigen Platz für die Basis-VM und die gewünschte Anzahl an Restore Points (Snapshots).
4. Restore Point Retention: Überwachen Sie, ob die gewünschte Anzahl an Wiederherstellungspunkten (z.B. 7 Tage) konsistent gehalten wird.

# Alerting-Regeln

# Tools

• Veeam ONE: Das bevorzugte Tool. Bietet dedizierte Dashboards für RPO-Verletzungen und Capacity Planning für DR-Repositories.
• Prometheus Exporter/Checkmk: Veeam bietet native APIs zur Integration. Ein wichtiger Checkmk-Check wäre veeam_job_status gefiltert auf JobType = Replica.

# 7. Fazit & Empfehlung

Veeam Replication ist die notwendige Investition für jede Enterprise-Umgebung, die ihre geschäftskritischen Systeme gegen Standortausfälle absichern muss. Es bietet die Flexibilität, zwischen VSS-konsistenten Point-in-Times (Replication) und Near-Zero RPO (CDP) zu wählen, basierend auf der Kritikalität der Anwendung.

Wann würde ich es NICHT einsetzen?

• Langzeit-Archivierung: Replication ist teuer in Bezug auf Festplattenplatz. Langzeit-Retention (Jahre) sollte über kostengünstigeres Backup-Storage (z.B. Capacity Tier in der Cloud) erfolgen, nicht über Replikation.
• Nicht-kritische Systeme: Für VMs, die einen RTO von > 4 Stunden tolerieren, ist eine schnellere Wiederherstellung von einem Backup-Repository (Instant VM Recovery) oft ausreichend und günstiger.

Ausblick: Die Zukunft liegt in CDP und der weiteren Integration mit dem VAIO-Framework von vSphere. Wir werden sehen, dass die Lücke zwischen traditioneller Replikation (Snapshot-basiert) und echter Continuous Data Protection weiter schrumpft.

# Anhang: Cheatsheet

# Referenzen

• Veeam Help Center: Replication Architecture and Processes
• Veeam Best Practices Guide: Proxy Sizing and Placement
• VMware vSphere API for I/O Filtering (VAIO) Documentation
• CBT Reset Procedure for VMware VMs