# Veeam Backup & Replication – Architektur und Betrieb im Enterprise-Umfeld

TL;DR / Management Summary Veeam Backup & Replication (VBR) ist die führende Lösung für VM-basierte Datensicherung. Für Enterprise-Tauglichkeit muss die Architektur korrekt verteilt werden: Trennen Sie die VBR-Serverrolle von den Data Movers (Proxies) und Speichern (Repositories). Nutzen Sie stets dedizierte Service Accounts, und implementieren Sie ReFS (Windows) oder XFS (Linux) Repositories zur Aktivierung der Fast-Clone-Technologie. Dies reduziert den Speicherplatzbedarf drastisch und beschleunigt Synthetic Full Backups von Stunden auf Minuten.

# 1. Einführung & Architektur

Als Senior DevOps Engineer betrachten wir Veeam nicht als einfache Anwendung, sondern als kritisch verteilte Infrastrukturkomponente. Die primäre Herausforderung ist die Bewältigung exponentiell wachsender Datenmengen bei gleichzeitiger Einhaltung strenger RTOs (Recovery Time Objectives).

# Warum brauchen wir das?

• Problemstellung aus der Praxis: Standard-Backup-Lösungen basieren oft auf traditionellen File-Level-Backups, die bei virtualisierten Workloads ineffizient sind (hohe I/O-Last auf den Hypervisoren, langsame Wiederherstellung). Zudem führen wöchentliche Full-Backups zu hohem Storage-Verbrauch und unnötigem Netzwerkverkehr.
• Veeam’s Lösung: VBR arbeitet auf dem Block-Layer des Hypervisors. Es nutzt Changed Block Tracking (CBT) – sei es VMWare’s CBT oder Hyper-V’s Resilient Change Tracking (RCT) – um nur die tatsächlich veränderten Blöcke zu sichern. Das zentrale Feature für den Enterprise-Einsatz ist die Scale-out Backup Repository (SOBR) Architektur, die das Abstrahieren der Speicherebenen und das Hinzufügen von Cloud-Tiering erlaubt.
• Vergleich mit Alternativen: Im Gegensatz zu reinen Agent-basierten Lösungen bietet Veeam: Application-Aware Processing (konsistente Backups für DBs/Exchange), Instant VM Recovery (RTOs in Minuten), und die zentrale Orchestrierung des gesamten DR-Prozesses.

# Architektur-Diagramm: Die 4 Säulen

Die Performance und Resilienz einer VBR-Installation hängt davon ab, wie die Rollen verteilt sind. Wir betreiben niemals alle Rollen auf einem einzelnen Server in einer Produktionsumgebung.

# 1. Backup Server (VBR)

Das Management-Herzstück. Steuert Jobs, verwaltet Metadaten (SQL DB), übernimmt Lizenzierung und Reporting.

# 2. Backup Proxy

Der Data Mover. Er zieht die Daten vom Hypervisor, komprimiert, dedupliziert und verschlüsselt sie. Dies ist die CPU-hungrigste Rolle.

# 3. Backup Repository

Das Speicherziel. Es speichert die Backup-Dateien und führt Tasks wie Synthetic Fulls und Daten-Integrity-Checks durch. Dies ist die I/O- und Speicherkapazitäts-hungrigste Rolle.

# 4. Optional: WAN Accelerator

Optimiert den Datentransfer zwischen zwei geografisch getrennten Standorten.

graph LR
    subgraph HQ-Site
        A[Hypervisor Cluster (VMware/Hyper-V)] -->|CBT/VADP| B(Backup Proxy)
        B -->|LAN/Optimized Data Transfer| C(Backup Repository - ReFS/XFS)
        D(VBR Management Server) -->|SQL Metadata/Job Control| E[SQL Database Server]
        D -->|Control Flow| B
        D -->|Control Flow| C
    end

    subgraph DR-Site
        F(WAN Accelerator Target)
        G(Repository DR)
    end

    C -->|WAN Accelerated Replication| F --> G

    style D fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#add8e6,stroke:#333,stroke-width:1px
    style C fill:#90ee90,stroke:#333,stroke-width:1px

# Kernel-Sicht (Windows Server)

Veeam Proxies, die im HotAdd-Modus (häufigste und schnellste Methode für VM-Proxies) arbeiten, nutzen den Windows Block Layer, um die VMDKs/VHDX des zu sichernden Gastsystems direkt in den Proxy-Host einzuhängen. Dies umgeht den Netzwerkpfad (NBD) und führt zu deutlich höherem Durchsatz, da die Daten direkt vom SAN (oder lokalem Storage) gelesen werden.

# 2. Installation & Grundkonfiguration (Praxis)

Wir installieren VBR Version 12 (oder höher) und konfigurieren die Komponenten verteilter, als es der Standard-Wizard vorgibt.

# Voraussetzungen

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

# 2.1. Vorbereitung der Service Accounts (Active Directory)

Verwenden Sie niemals Domain-Admins für den Veeam Service.

1. Erstellen Sie svc_veeam_engine (Wird für den VBR-Dienst verwendet) und svc_veeam_backup (Wird für Job-Credentials verwendet, die auf Hypervisoren und Repositories zugreifen).
2. Geben Sie svc_veeam_engine lokale Administratorrechte auf dem VBR-Server.

# 2.2. VBR Installation und SQL-Anbindung

Wir nutzen eine externe, dedizierte SQL-Instanz.

# Auf dem VBR-Server, während der Installationsassistent läuft:

# 1. SQL-Instanz wählen: 
# NICHT 'Install PostgreSQL automatically'. Stattdessen 'Use existing instance'.
# Servername: SQL-VBR-01\VEEAM_INSTANCE
# Authentifizierung: Empfehlung: Windows Authentication (Service Account svc_veeam_engine)

# 2. Service Account Setup:
# Verwenden Sie den dedizierten svc_veeam_engine Account für den Veeam Backup Service.
# Dies gewährleistet, dass der Dienst auch nach einem Passwort-Update weiterläuft, 
# und vermeidet die Verwendung des lokalen Systemkontos, das schwieriger zu auditieren ist.

# 3. Standard-Ports überprüfen:
# TCP 9392 (Management Konsole)
# TCP 2500-5000 (Data Mover Range) - Standardbereich, muss in der Firewall offen sein!

# 2.3. Hinzufügen des Backup Repository (Crucial Step)

Dies ist der wichtigste Performance-Flaschenhals. Wir nutzen Windows Server mit ReFS für VBR und aktivieren Fast-Cloning.

1. Repository Server (Windows) Vorbereitung:
   • Installieren Sie das Volume mit ReFS (Resilient File System).
   • Wichtig: Nutzen Sie große Cluster-Größen (64 KB).

# Auf dem Repository Server (Windows):
# Formatieren des dedizierten Backup-Volumes mit der korrekten Cluster-Größe für ReFS
Format-Volume -DriveLetter E -FileSystem ReFS -AllocationUnitSize 64KB -Force -NewFileSystemLabel "Veeam_Repo_ReFS"

2. VBR Konfiguration:
   • Fügen Sie das Volume als “Hardened Repository” hinzu, um die Immutability (Unveränderlichkeit) zu nutzen (siehe Abschnitt 3.3).
   • Stellen Sie unter “Advanced Settings” sicher, dass “Use per-VM backup files” aktiviert ist. Dies ist zwingend erforderlich, um Fast-Cloning (Block Cloning) von ReFS/XFS effizient zu nutzen.

# 3. Deep Dive: Konfiguration für Profis

Hier optimieren wir die Infrastruktur, um die I/O-Last zu minimieren und die RTOs zu verbessern.

# 3.1. Performance Tuning: Proxies und Transport-Modi

Proxies müssen richtig dimensioniert sein, basierend auf der Anzahl der gleichzeitigen Tasks.

# Proxy Dimensionierung (Regel N+1)

Die Faustregel lautet: Für jede gleichzeitig laufende Task benötigt Veeam 1 Core und 2 GB RAM.

# Beispiel: Ein Proxy mit 8 Cores und 16 GB RAM
# Maximale gleichzeitige Tasks: 
# (8 Cores / 2) + 1 = 5 Tasks (Da 1 Core/Task oft überdimensioniert ist, ist 4+1 ein guter Startwert.)
# Setzen Sie den Wert im Proxy-Einstellungsfenster auf 5.

# Transport-Modus Auswahl

Expertentipp: Überprüfen Sie regelmäßig im Job-Log, welchen Transport-Modus Veeam tatsächlich nutzt. Ein unerwarteter Fallback auf NBD bedeutet oft, dass die HotAdd-Funktionalität (z.B. SCSI-Controller-Shared-Access) nicht korrekt konfiguriert ist oder der Proxy keinen Zugriff auf den Datastore hat.

# 3.2. Repository Performance (Fast Cloning)

Wenn Sie Windows (ReFS) oder Linux (XFS) nutzen, sind Synthetic Full Backups keine I/O-hungrigen Kopierprozesse mehr. Veeam erstellt lediglich neue Metadaten-Pointer auf die existierenden Blöcke.

graph LR
    A[Full Backup 1. Mai] -->|Pointer| B(Block 1)
    A -->|Pointer| C(Block 2)
    A -->|Pointer| D(Block 3)
    
    subgraph Synthetic Full 8. Mai (Fast Clone)
        E[Metadata File 8. Mai]
        E -->|Pointer Reuse| B
        E -->|Pointer Reuse| C
        E -->|New Pointer| F(New Block 4)
    end
    
    style E fill:#ffc,stroke:#333
    
    E --> F
    
    Note: Die Daten (B, C) werden nicht kopiert. Nur Metadaten werden neu geschrieben.

# 3.3. Hardening & Security (Immutable Backups)

Die wichtigste Maßnahme gegen Ransomware ist die Unveränderlichkeit (Immutability) der Backups.

1. Dedizierte Linux Hardened Repository (Empfohlen):

   • Installieren Sie ein Linux-System (z.B. Ubuntu Server oder RHEL) ohne SSH-Passwort-Login (nur Key-basiert).
   • Der Veeam Data Mover läuft als nicht-privilegierter Benutzer (veeam_repo_user).
   • Wenn Veeam die Backup-Dateien schreibt, setzt es das Immutable Flag (Linux Extent Attributes). Der veeam_repo_user hat danach keine Rechte mehr, diese Blöcke innerhalb der definierten Frist zu löschen – selbst wenn der Account kompromittiert wird.

2. Principle of Least Privilege (PoLP):

   • Der VBR Service Account (svc_veeam_engine) sollte nur die notwendigen Rechte in der AD und auf den Hypervisoren haben. Verwenden Sie die Veeam Best Practice Guide für die minimal notwendigen Permissions.

# 4. Day-2 Operations: Wartung & Alltag

Ein gut laufendes Backup-System braucht kontinuierliche Wartung, besonders die SQL-Datenbank und die Speicherkapazitäten.

# Typische Tasks

• SQL DB Maintenance: Die Veeam-Datenbank (standardmäßig VeeamBackup) kann stark fragmentiert werden. Wir automatisieren die Index-Reorganisation wöchentlich.
• Updates/Patches: Veeam-Updates sollten immer zuerst auf den Proxies und Repositories getestet werden, bevor der zentrale VBR-Server gepatcht wird. VBR-Updates erfordern meist eine koordinierte Downtime des VBR-Dienstes.
• Storage Migration (SOBR): Wenn ein Extent (physisches Volume) im SOBR voll ist, kann man ein neues hinzufügen. Um die Daten von einem alten, langsamen Extent auf das neue, schnelle zu verschieben, nutzen Sie das PowerShell-Cmdlet Move-VBRViBackup.

# Beispiel: Verschiebe alle Backups der VM 'ProdDB01' auf das neue Extent 'NewFastRepo'
$vm = Get-VBRBackup -Name "ProdDB01"
$targetRepo = Get-VBRRepository -Name "NewFastRepo"

# Startet den Migrationsjob. '-Wait' hält die PowerShell-Session blockiert, bis der Job fertig ist.
Move-VBRViBackup -Backup $vm -Repository $targetRepo -Wait

# Automatisierung (PowerShell & IaC)

Die Verwaltung von Jobs, Hinzufügen von VMs oder Ändern von Retention Policies sollte über das Veeam PowerShell Modul (Veeam.Backup.PowerShell) erfolgen, um Idempotenz zu gewährleisten.

# Ansible Beispiel: Sicherstellen, dass ein Backup Job existiert und konfiguriert ist
# Achtung: Veeam hat keine nativen Ansible-Module. Wir verwenden 'win_powershell'
# oder 'community.windows.win_shell' um das VBR PowerShell Modul zu nutzen.

- name: Ensure Veeam Job for Critical VMs is configured
  ansible.windows.win_powershell:
    script: |
      # Modul importieren, falls nicht geladen
      Import-Module Veeam.Backup.PowerShell

      $JobName = "Critical_VMs_Daily"
      $RepositoryName = "Hardened_Repo_01"
      $VMs = @("PROD-WEB-01", "PROD-DB-01")

      $repo = Get-VBRRepository -Name $RepositoryName
      
      # Prüfen, ob der Job existiert. Falls nicht, neu erstellen.
      if (-not (Get-VBRJob -Name $JobName -ErrorAction SilentlyContinue)) {
          New-VBRJob -Name $JobName -Backup -Repository $repo -AutoSelectProxy
          Write-Host "Veeam Job '$JobName' created."
      }

      # Job-Objekt abrufen
      $job = Get-VBRJob -Name $JobName
      
      # VMs zur Selektion hinzufügen
      foreach ($vmName in $VMs) {
          $vmObj = Find-VBRViEntity -Name $vmName | Select-Object -First 1
          if ($vmObj) {
              Add-VBRJobObject -Job $job -Object $vmObj -Confirm:$false
          }
      }
      
      # Sicherstellen der Retention Policy (7 Restore Points)
      Set-VBRJobOptions -Job $job -RetentionPolicy 7 -Confirm:$false

  register: job_config_result
  changed_when: "'created' in job_config_result.stdout or 'Added' in job_config_result.stdout"

# 5. Troubleshooting & “War Stories”

Wenn das Backup in der Nacht um 03:00 Uhr fehlschlägt, müssen Sie schnell wissen, wo Sie suchen müssen.

# Top 3 Fehlerbilder

# 1. Symptom A: “Failed to create processing task for VM.”

• Fehlermeldung (Log-Eintrag): Cannot connect to host/proxy. Failed to open listening port [6160].
• Ursache: Klassischerweise eine Firewall-Regel. Der VBR-Server oder der Proxy kann keine Verbindung zum Hypervisor-Host oder zum Repository-Server über die erforderlichen Data Mover Ports (2500-5000 oder spezifisch konfigurierte Ports) aufbauen.
• Lösung: Verifizieren Sie die Netzwerkverbindung und prüfen Sie die Windows Firewall oder Hardware-Firewalls zwischen den Komponenten. Nutzen Sie Test-NetConnection -Port <Veeam Port> auf den beteiligten Maschinen.

# 2. Symptom B: Performance-Einbruch bei Synthetic Full Backups.

• Symptom: Wöchentliche Synthetic Full Backups dauern plötzlich 8 Stunden statt 30 Minuten.
• Analyse:
  • Prüfen Sie den Repository-Typ. Läuft er auf NTFS statt ReFS/XFS? Falls ja, muss die gesamte Chain neu erstellt oder migriert werden.
  • Tools: Nutzen Sie Windows Performance Monitor (perfmon) auf dem Repository Server, um die Disk Latency (PhysicalDisk\Avg. Disk sec/Transfer) zu messen. Werte über 10ms sind problematisch.
• Lösung: Stellen Sie sicher, dass das Volume mit der korrekten 64KB ReFS-Allokation formatiert wurde und dass die Fast-Cloning-Funktion in den Repository-Einstellungen aktiviert ist (“Enable inline data reduction” muss aktiv sein).

# 3. Symptom C: Proxy läuft auf NBD (Network Mode), obwohl HotAdd konfiguriert ist.

• Ursache:
  • Der Proxy hat keinen Zugriff auf den Datastore des zu sichernden Gastsystems (fehlende LUN-Präsentation oder falsches Zoning).
  • Der Proxy ist ein Generation 2 Hyper-V VM oder nutzt den falschen SCSI-Controller-Typ, was HotAdd verhindern kann.
• Lösung: Prüfen Sie die Host-Logfiles (vmkernel.log bei VMware) auf Zugriffsverweigerungen. Stellen Sie sicher, dass die Proxy VM und die zu sichernden VMs denselben Storage-Layer erreichen können.

# Recovery Szenarien

# War Story: SQL Metadata Corruption

Ich hatte den Fall, dass die VM, die die SQL-DB für VBR beherbergte, einen Storage-Fehler erlitt. Ohne die VBR-Datenbank weiß Veeam nicht, welche Sicherungen wo liegen.

• Der Notfallplan: Die Configuration Backup Funktion von VBR ist lebensrettend. Veeam erstellt regelmäßig ein verschlüsseltes Backup der gesamten SQL-Metadaten.
• Wiederherstellung: Installieren Sie den VBR-Server neu auf einem sauberen OS, starten Sie den Installer und wählen Sie die Option Restore. Zeigen Sie auf das letzte gültige Konfigurations-Backup (das außerhalb der primären Umgebung gespeichert sein MUSS).

graph TD
    A[Backup Job Failed/Infrastructure Down] --> B{SQL Metadata Lost?};
    B -- Ja --> C[New VBR Server Install];
    C --> D[Run Veeam Installer: 'Restore'];
    D --> E[Point to Configuration Backup File (.Veeam)];
    E --> F[VBR Server Restored, Jobs/History Intact];
    
    B -- Nein --> G[Check Data Mover Communication];
    G --> H{Firewall/Ports OK?};
    H -- Nein --> I[Open TCP Ports 2500-5000];
    H -- Ja --> J[Check Proxy/Repo/Host Name Resolution];

# 6. Monitoring & Alerting

Ein passives Backup-System ist ein Ticking Time Bomb. Wir müssen proaktiv Metriken überwachen.

# Metriken (KPIs)

# Alerting-Regeln

• Alert 1 (Critical): “Repository Free Space < 15%.”
• Alert 2 (Warning): “Veeam Job ‘Critical’ failed for 2 consecutive runs.”
• Alert 3 (Information): “Veeam SQL Transaction Log file > 50 GB” (Initiiert manuelles Log-Shrinking und Überprüfung des Recovery Models).

# Tools

Wir nutzen den Veeam ONE Reporter für Business-Level-Reporting und Kapazitätsplanung. Für die Integration in zentrale Monitoring-Tools (Prometheus, Checkmk) nutzen wir:

• PowerShell / Custom Scripting: Veeam bietet umfangreiche Cmdlets. Ein Cronjob/Scheduled Task kann diese abfragen und als Metriken in einen Prometheus Exporter pushen.
• Veeam Enterprise Manager REST API: Für hochfrequentes Polling von Job-Status und Infrastruktur-Komponenten.

# 7. Fazit & Empfehlung

Veeam ist eine leistungsstarke und flexible Lösung, die jedoch nur mit einer verteilten, auf Fast-Cloning optimierten Architektur ihre volle Stärke entfaltet.

Wann würde ich VBR nicht einsetzen?

1. Tiny Environments: Wenn Sie nur 3-5 VMs sichern müssen, ist VBR möglicherweise Overkill. Agent-basierte Lösungen (oder die kostenlose Veeam Agent Version) reichen oft aus, da der Overhead für die Management-Infrastruktur (VBR, SQL DB) unverhältnismäßig hoch ist.
2. Legacy/Mainframe: Für AS/400, Großrechner oder spezifische Non-x86-Systeme ist VBR ungeeignet, da es primär auf Hypervisor-APIs basiert. Hier müssen spezialisierte Lösungen oder Agenten genutzt werden.

Ausblick: Der Trend geht zu Immutable Cloud Storage (S3 Object Lock). Veeam’s Capacity Tier und Archive Tier, die mit Azure Blob oder AWS S3 kommunizieren, sind der Standard für die 3-2-1-Regel, da sie die teuren lokalen Tape-Bibliotheken obsolet machen.

# Anhang: Cheatsheet

# Referenzen

• Veeam Help Center: User Guide (Aktuelle Version)
• Veeam Community Forums (Offizielles Forum für Deep-Dive Fragen)
• Veeam Best Practices Guide for Service Accounts and Permissions (PoLP)
• Microsoft Documentation: ReFS Performance and Fast Clone Technology