# Veeam Backup Jobs: Optimales RPO/RTO durch granulare Steuerung

TL;DR / Management Summary Veeam Backup Jobs sind die primäre Orchestrierungsebene zur Einhaltung von RPO (Recovery Point Objective) und RTO (Recovery Time Objective). Die Effizienz und Performance eines Jobs hängt kritisch von der korrekten Zuweisung und Dimensionierung der verteilten Komponenten ab: Backup Proxies und Repositories. Für den Enterprise-Einsatz sind ‘Application-Aware Processing’ zur Transaktionssicherheit, sowie die Nutzung von ‘Scale-Out Backup Repositories (SOBR)’ für immutablen Speicher und Kapazitäts-Tiering obligatorisch.

# 1. Einführung & Architektur

Im modernen Enterprise-DR-Szenario reicht es nicht aus, eine VM zu kopieren. Wir müssen gewährleisten, dass geschäftskritische Anwendungen (wie MS SQL, Exchange, Oracle) in einem konsistenten, wiederherstellbaren Zustand gesichert werden.

# Warum brauchen wir das?

• Problemstellung aus der Praxis: Das Sichern einer laufenden VM per Snapshot ohne Anwendungskonsistenz führt oft zu inkonsistenten Datenbanken, die nach dem Restore nicht starten oder manuelle Recovery-Schritte erfordern (hohes RTO).
• Veeam-Lösung: Veeam nutzt ‘Application-Aware Processing’ (VAAIP) in Verbindung mit Microsoft VSS (Volume Shadow Copy Service), um Datenbanktransaktionen vor dem Snapshot zu quiesen und nach der Sicherung wieder freizugeben. Dies gewährleistet atomare Konsistenz.

# Architektur-Diagramm (Kernel-Sicht & Datenfluss)

Veeam operiert auf einem komplexen, verteilten Modell. Der Job selbst ist nur die Konfigurations-Schablone; die eigentliche Arbeit wird durch die Data Mover erledigt.

Der Kernel-Sicht-Einstieg (VMware/Hyper-V):

1. Orchestrierung (VBR Server): Sendet den Befehl, eine VM zu sichern.
2. Quiescing (VM Guest OS/VSS): Veeam injiziert temporäre Prozesse in das Guest OS, um VSS aufzurufen. VSS interagiert direkt mit dem Windows Kernel I/O Stack, um schreibintensive Operationen anzuhalten und den Zustand des Dateisystems einzufrieren.
3. Snapshot (Hypervisor Layer): Nach erfolgreichem Quiescing wird ein Hypervisor-Snapshot erstellt, der die Blöcke sperrt.
4. Datenübertragung (Proxy Layer): Der Proxy-Dienst (Veeam Data Mover) liest die Datenblöcke aus dem Speicher oder SAN.

graph TD
    A[VBR Server] --> B(Job Scheduling & Orchestration);
    B --> C{Backup Proxy};
    C --> D[Hypervisor Host];
    D --> E(VM Guest OS/VSS Quiescing);
    D --> F(VM Snapshot Creation);
    C --> G[Data Transport Layer];
    G --> H{Backup Repository};
    H --> I(Storage Target: SOBR / Disk);

    subgraph "Data Path (Read -> Write)"
        G -- Block-Level Data --> H;
    end

    subgraph "Control Path (API)"
        A --> C;
        A --> D;
        A --> H;
    end

Transport Modes (Der Flaschenhals):

Die Wahl des Transportmodus im Proxy ist essenziell für die Performance:

Empfehlung: Immer HotAdd priorisieren. Stellen Sie sicher, dass Proxies genügend SCSI-Slots und CPU/RAM haben.

# 2. Installation & Grundkonfiguration (Praxis)

Wir konfigurieren einen Job für eine geschäftskritische Datenbank-VM (Tier 1).

# Voraussetzungen

1. Rollen-Platzierung: Proxies und Repositories müssen dimensioniert und auf der Infrastruktur verteilt sein, um I/O zu parallelisieren. Faustregel: 1 Core und 2 GB RAM pro paralleler Aufgabe auf dem Proxy.
2. Netzwerk: Dediziertes Backup-Netzwerk (10 GbE) zwischen Proxies und Repositories.
3. Credentials: Service Account mit minimalen Rechten für das Guest OS für App-Aware Processing.

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

Der Job-Setup im Veeam B&R Konsole muss folgende Deep-Dive-Einstellungen berücksichtigen:

# A. Storage Optimization (Der richtige Block Size)

# Beispiel für Job-Erstellung mit optimalen Storage-Einstellungen

# 1. Blockgröße wählen:
# Für die meisten Enterprise-Umgebungen und SOBR ist "Local Target (4MB)" Standard.
# Nur bei sehr kleinen VMs (unter 50GB) oder WAN-Replizierung sollte 'LAN Target (1MB)' gewählt werden.
# KEIN 'WAN Target (256KB)' wählen, es sei denn, Sie replizieren über extrem langsame Leitungen, da dies die Deduplizierung verschlechtert.

# 2. Komprimierung und Deduplizierung:
# Empfehlung: Compression 'Optimal' und Deduplication 'Enabled' (Standard).
# 'Extreme' Compression erhöht die CPU-Last auf dem Proxy drastisch, die Einsparungen sind meist minimal.

# B. Application-Aware Processing (Konsistenz)

Dies ist obligatorisch für Datenbanken und DCs.

# Konfiguration der App-Aware Settings (simulierte GUI-Logik):

# Aktivieren Sie 'Enable application-aware processing'
# Guest OS Credentials: Nutzen Sie den Least-Privilege Service Account
# Transaction Log Handling (SQL/Exchange):
# Methode: 'Process logs periodically' ODER 'Truncate logs at successful backup'

# Bei Oracle/Postgres: Sichern Sie die Transaktionslogs NICHT über Veeam, 
# sondern nutzen Sie das native Backup-Tool (RMAN/pg_dump) in Kombination mit Veeam, 
# um Log-Konsistenz über die gesamte Zeitachse zu gewährleisten.

Achtung: Stellen Sie sicher, dass der VSS Writer (z.B. SQL Writer, Exchange Writer) im Guest OS stabil ist, bevor der Job läuft.

# C. GFS Retention Policy (Compliance)

Nutzen Sie die Grandfather-Father-Son (GFS) Retention, um langfristige Compliance zu gewährleisten, ohne ständig Active Fulls erstellen zu müssen.

# Beispiel GFS Policy:
# - Daily Backups: 14 Restore Points (Son)
# - Weekly Full: 8 Weeks (Father)
# - Monthly Full: 12 Months (Grandfather)
# - Yearly Full: 7 Years (Grandfather)

# Vorteil: Veeam erstellt synthetische Full-Backups basierend auf den vorhandenen Inkrementellen, 
# was I/O-Spitzen stark reduziert.

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning

# A. Proxy Concurrency und Load Control

Der Proxy ist der kritischste Engpass.

• Max Concurrent Tasks: Standardmäßig 2 Tasks pro CPU-Core. In Umgebungen mit schnellem SAN/NVMe kann dieser Wert auf 3 oder 4 Tasks pro Core erhöht werden, um die Latenz zu kompensieren. Überlastung führt jedoch zu iowait.
• Throttle I/O: Nutzen Sie die Option ‘Limit maximum allowed network traffic’ nur, wenn das Backup-Netzwerk mit anderen geschäftskritischen Diensten geteilt wird. Ansonsten sollte diese Beschränkung im dedizierten Backup-Netzwerk vermieden werden.
• Optimale Task-Verteilung: Weisen Sie spezifische Proxies spezifischen Jobs zu, um sicherzustellen, dass kritische Tier-1-Systeme immer schnelle, dedizierte Ressourcen erhalten.

# B. Scale-Out Backup Repository (SOBR) – Der Weg zur Immutability

Ein Veeam Job sollte fast immer auf ein SOBR abzielen, nicht auf ein einzelnes Repository.

1. Performance Tier: Definiert die schnellen Speicher (Block oder NFS).
2. Capacity Tier: Cloud-Speicher (S3, Azure Blob) oder Object Storage.
3. Archive Tier: Tiefen-Archivierung (Amazon Glacier, Azure Archive).

Hardening Detail: Konfigurieren Sie im SOBR das S3-kompatible Repository als Immutable Repository (Object Lock). Dies schützt Ihre Backups für die definierte Zeitspanne vor Ransomware und versehentlichem Löschen durch Admins. Dies ist die Single-Most-Important-Security-Einstellung für Backups.

# Hardening & Security

• Least Privilege Principle: Proxies sollten nur die notwendigen Rechte auf dem Hypervisor (z.B. vSphere Read/Write/Snapshot-Rechte) und Guest OS (VSS-Interaktion) besitzen. Niemals einen Domain Admin Account für alle Veeam-Interaktionen verwenden.
• Verschlüsselung: Aktivieren Sie die AES-256 Verschlüsselung auf Job-Ebene. Dies schützt die Daten ‘at rest’. Warnung: Das Passwort muss extrem sicher verwaltet werden (z.B. in einem Vault), da ohne dieses Passwort der gesamte Datensatz nutzlos ist.

# 4. Day-2 Operations: Wartung & Alltag

# Typische Tasks

• Retention Health Check: Überprüfen Sie regelmäßig (monatlich), ob die Retention Policy tatsächlich die beabsichtigte Anzahl von Wiederherstellungspunkten bereitstellt. Oftmals scheitert die Policy, weil das Repository plötzlich voll ist und der älteste Full nicht gelöscht werden kann.
• SureBackup / SureReplica: Dies ist keine optionale Funktion, sondern Teil des RTO-Nachweises. Konfigurieren Sie regelmäßige, automatisierte Tests (mindestens wöchentlich), bei denen Veeam die VMs in einem isolierten Lab startet, Boot-Tests durchführt und Anwendungsdienste (z.B. SQL-Query, HTTP-Response) überprüft.

# PowerShell Befehl zur Überprüfung des Job-Status der letzten 7 Tage
Get-VBRJob | Get-VBRJobSession -Last $true | Where-Object {$_.Result -ne "Success"} | Select-Object JobName, Result, EndTime

# Automatisierung (PowerShell / IaC)

Obwohl Veeam stark GUI-basiert ist, wird das Management großer Umgebungen über PowerShell (mit dem Veeam Snap-in) automatisiert.

# PowerShell Snippet: Erstellen eines neuen Backup Jobs basierend auf einer kritischen VM-Gruppe
$Repo = Get-VBRBackupRepository -Name "SOBR_Prod_Immune"
$Proxy = Get-VBRBackupProxy -Name "Proxy03_HotAdd"
$VMs = Get-VBRVirtualMachine -Name "SQL01"

# Neue Backup Job Einstellungen
$JobOptions = New-VBRJobOptions -EnableApplicationAwareProcessing -EnableVss -EnableVeeamAgent
$Schedule = New-VBRJobScheduleOptions -Daily -At "23:00" -RetryCount 3

# Erstellen des Jobs (Idempotent: Prüft Existenz vor Erstellung)
Add-VBRJob -Name "SQL01_Tier1_Backup" `
    -BackupRepository $Repo `
    -Proxy $Proxy `
    -Entity $VMs `
    -JobOptions $JobOptions `
    -ScheduleOptions $Schedule `
    -RetentionPolicy (New-VBRJobRetentionOptions -RetentionDays 14)

Write-Host "Veeam Job SQL01_Tier1_Backup erstellt und dem immutablen Repository zugewiesen."

# 5. Troubleshooting & “War Stories”

Veeam-Troubleshooting beginnt immer mit der Bottleneck-Analyse im Job-Log. Die Lese-/Schreibgeschwindigkeit wird dem langsamsten Glied zugeschrieben: Source (Hypervisor/Storage), Proxy (CPU/RAM), Network (Bandbreite), Target (Repository I/O).

# Top 3 Fehlerbilder

# 1. Symptom A: VSS Snapshot Failure (Failed to create VSS snapshot error 0x80042306)

• Fehlermeldung: VSS-Fehler (Writer Timeouts, Schattenkopie-Anbieterfehler).
• Ursache: Oftmals zu hohe I/O-Last auf dem Guest OS während des Quiescing, oder inkonsistente/defekte VSS Writer (z.B. wegen fehlgeschlagener Windows Updates).
• Lösung: Im Guest OS vssadmin list writers überprüfen. Starten Sie defekte Writer neu. Reduzieren Sie die Anzahl paralleler Aufgaben auf dem Proxy, um die Last auf das Guest OS zu reduzieren. Deep Fix: Deaktivieren Sie VSS-Shadow Copies (System Protection) im Guest OS, da diese mit Veeam kollidieren können.

# 2. Symptom B: Job Performance Einbruch (Bottleneck: Proxy)

• Symptom: Backup-Geschwindigkeit fällt von 500 MB/s auf 50 MB/s. Bottleneck-Anzeige springt auf “Proxy”.
• Ursache: Der Proxy ist überlastet, weil zu viele parallele Tasks laufen. Oder HotAdd ist fehlgeschlagen und der Proxy greift automatisch auf den langsameren NBD-Modus zurück.
• Analyse: Überprüfen Sie die Task-Limits auf dem Proxy. Prüfen Sie in den Logs, ob der Transportmodus NBD anstatt HotAdd/Direct SAN verwendet wurde.

# 3. Symptom C: Repository Space Full (Retention Failure)

• Symptom: Job schlägt mit ‘Target Free Space Low’ fehl.
• Ursache: Die Retentionsbereinigung (Retention job) konnte ältere Full-Backups nicht löschen, weil sie von neueren Inkrementellen referenziert werden. Oft liegt dies an temporären Sperren oder an einer fehlerhaften GFS-Konfiguration.
• Lösung: Manuelle Prüfung der Chain-Integrität. Führen Sie einen manuellen ‘Active Full’ durch, um eine neue, saubere Backup-Kette zu starten. Überprüfen Sie die Kapazitäts-Limits des SOBR.

# Recovery Szenarien

Metadata Corruption: Wenn das Konfigurations-Datenbank-Backup beschädigt ist.

1. Stoppen Sie alle Veeam Dienste.
2. Stellen Sie die letzte bekannte gute Configuration Backup Datei (.bak) aus Ihrem Disaster Recovery Share bereit.
3. Nutzen Sie das Werkzeug Veeam.Backup.Configuration.Restore.exe (im Installationspfad), um die Datenbank wiederherzustellen. Wichtig: Verwenden Sie die Option ‘Restore to new database’ als Fallback.

graph TD
    A[Job Failed/Slow?] --> B{Check Job Log: Bottleneck?};
    B -- Target/Network --> C{Check Repository/Network Health};
    B -- Proxy --> D{Check Proxy Load/Transport Mode};
    B -- Source --> E{Check Hypervisor Storage Latency/VSS Status};

    E -- VSS Error? --> E1(Check Guest OS Writers: vssadmin list writers);
    E -- Storage Slow? --> E2(iostat/esxtop: Überprüfe Latenz);

    D -- NBD instead of HotAdd? --> D1(Check Proxy SCSI Slots / Datastore Access);
    D -- Proxy Load High? --> D2(Reduziere Max Concurrent Tasks);

    C -- Target Full? --> C1(Prüfe Retention Chain Integrität & SOBR Capacity Tier);

Anekdote (The HotAdd Trap): Wir hatten den Fall, dass alle HotAdd-Backups auf einem großen Cluster scheiterten. Ursache: Die Proxies waren in einem Ressource Pool, der versehentlich den Zugriff auf das primäre SAN des Clusters verlor. Veeam schaltete lautlos auf NBD um. Die Backup-Zeiten explodierten. Die Lektion: Vertraue nicht nur dem grünen Haken im Job-Log. Prüfe den verwendeten Transportmodus im Job Summary!

# 6. Monitoring & Alerting

Effektives Veeam Monitoring basiert auf der Überwachung von Zeit und Kapazität, nicht nur auf Status.

# Metriken

• Job Success Rate/Duration (KPI): Die kritischste Metrik. Die Zeit, die ein Job benötigt, sollte innerhalb einer definierten Toleranz (z.B. +/- 10%) der historischen Baseline liegen.
• Repository Free Space: Nicht die absolute Größe, sondern die Free Space vs. Required Space for Retention.
• Bottleneck Stat (Source/Proxy/Target): Exportieren Sie die Veeam Statistik (über PowerShell oder REST API) in Ihr Monitoring-System, um langfristige Performance-Trends zu erkennen.
• SureBackup Status: Status der Recovery-Verification.

# Alerting-Regeln

• P1 Alert: Job Failure (Result = Error) oder SureBackup Failure.
• P2 Alert (Performance): Job Duration > 120% der historischen Baseline. Dies deutet auf einen beginnenden Proxy- oder Speicherdruck hin, der behoben werden muss, bevor ein P1-Fehler auftritt.
• P3 Alert (Capacity): Repository Free Space < 10% und Job Retention Time wird nicht eingehalten.

Tools Integration: Veeam bietet einen dedizierten PowerShell RESTful API Exporter an. Nutzen Sie diesen, um Metriken wie VBRJobSession.PerformanceData in Prometheus oder Grafana zu integrieren.

# 7. Fazit & Empfehlung

Die Konfiguration von Veeam Backup Jobs ist mehr als das Setzen eines Zeitplans. Es ist die strategische Verteilung von I/O-Last, die Gewährleistung der Anwendungskonsistenz (VSS/App-Aware) und die Absicherung der Datenkette (SOBR/Immutability).

Wann würde ich Veeam nicht einsetzen?

Veeam ist exzellent für VM- und Cloud-Workloads. Für extrem latenzkritische Datenbanken (z.B. Tausende Transaktionen pro Sekunde) kann das blockierende Verhalten des VSS-Quiescing während des Snapshots dennoch zu Engpässen führen. In solchen Fällen ist oft die native, asynchrone Datenbank-Replikation (z.B. Always On, Oracle Data Guard) in Kombination mit Log-Shipping-Backups die bessere DR-Strategie, wobei Veeam die Orchestrierung übernehmen kann.

Ausblick: Mit der zunehmenden Nutzung von Cloud-nativem Object Storage wird die korrekte Konfiguration der SOBR-Tiering-Regeln (Move Policy vs. Copy Policy) und die Nutzung der Immutability-Funktionen der Schlüssel zur Erfüllung moderner 3-2-1-0 Backup-Regeln sein.

# Anhang: Cheatsheet

Die 10 wichtigsten PowerShell Befehle für Veeam Admin:

# Referenzen

• Veeam Help Center: Bottleneck Analysis
• Veeam Best Practices Guide (Offiziell)
• Microsoft VSS Writer Stability Troubleshooting
• Veeam PowerShell Reference