# Proxmox Backup Server (PBS) – High Availability und Performance

TL;DR / Management Summary Der Proxmox Backup Server (PBS) ist die zentrale, block-basierte Backup-Lösung für Proxmox VE und andere Linux-Clients. Seine Stärke liegt in der effizienten client-seitigen Deduplizierung, der integrierten End-to-End-Verschlüsselung und robusten Integritätsprüfungen. Für den Produktionseinsatz muss PBS auf einem resilienten Dateisystem laufen – wir empfehlen ZFS, da es Checksumming und Performance-Optimierungen bietet, die für große Datenmengen unerlässlich sind. Der Hauptvorteil: Massive Reduzierung des Speicherbedarfs und der Netzwerk-Bandbreite im Vergleich zu herkömmlichen Backup-Methoden.

# 1. Einführung & Architektur

PBS ist nicht nur ein Dateiserver für Backup-Dumps. Es ist ein hochspezialisierter, block-basierter Content-Defined Chunking Service, der die Effizienz von Backups revolutioniert.

# Warum brauchen wir das?

Problemstellung aus der Praxis: Bei traditionellen, inkrementellen Backups (wie z.B. rsync oder alte vzdump Modi) werden Dateiblöcke gespeichert, selbst wenn sich nur wenige Bytes in einem 100 GB großen VM-Image geändert haben. Dies führt schnell zu exponentiellem Speicherverbrauch und hohen E/A-Anforderungen.

Lösung durch PBS: PBS zerlegt die eingehenden Datenströme in variable Blöcke (Chunks, typischerweise 4MB). Diese Chunks werden über SHA-256 gehasht. Bevor ein Chunk auf die Platte geschrieben wird, prüft PBS, ob dieser Hash bereits in der globalen Chunk-Datenbank (dem Datastore Index) existiert.

• Vorteil 1 (Deduplizierung): Nur neue, einzigartige Chunks werden gespeichert. Das spart 50% bis 90% des Speichers, insbesondere in Umgebungen mit vielen ähnlichen VMs/Containern (z.B. OS-Templates).
• Vorteil 2 (Integrität): Jedes Backup wird mit einer Liste der Chunk-Hashes gespeichert. Das ermöglicht die ‘Verification’-Jobs, die die Integrität der Daten auf Block-Ebene regelmäßig überprüfen.

# Architektur-Diagramm (Kernel- und Stack-Sicht)

In unserer Produktionsumgebung läuft PBS auf einem dedizierten Server mit ZFS als Speicher-Backend.

graph TD
    subgraph Client (Proxmox VE oder Linux)
        A[vzdump / pbs-client] --> B(Chunker/Hasher)
    end
    B --> C{Verschlüsselung (Client-Side)}
    C --> D(Netzwerk Port 8007)

    subgraph PBS Server
        D --> E[PBS Daemon (rust)]
        E --> F[PBS Datastore Service]
        F --> G{Chunk Index Check}
        G -- Neu --> H[Schreibe Chunk File (.blob)]
        G -- Existiert --> I[Referenziere Chunk im Backup-Snapshot]
        H & I --> J[ZFS Mount Point /mnt/datastore]
    end

    subgraph Storage Layer (Kernel-Sicht)
        J --> K[ZFS Filesystem]
        K --> L[ZFS ARC/L2ARC Cache]
        L --> M[Kernel Block Layer]
        M --> N[Physische Disks (RAIDZ/Mirror)]
    end

Kernel-Sicht (Deep Dive): Der PBS-Dämon ist in Rust geschrieben und extrem speichereffizient. Er interagiert primär über standardmäßige POSIX-Dateisystemaufrufe (open, write, read). Die wahre Performance und Datenintegrität kommt jedoch von der darunterliegenden ZFS-Schicht:

1. ZFS Copy-on-Write (CoW): Sichert atomare Schreibvorgänge.
2. Checksumming: ZFS prüft die Integrität jedes Blocks (Daten und Metadaten), zusätzlich zur SHA-256-Prüfung von PBS. Dies bietet eine doppelte Absicherung gegen Silent Data Corruption.
3. ARC (Adaptive Replacement Cache): PBS profitiert massiv von ZFS’s ARC, da die Metadaten (Chunk-Indizes) und oft verwendete Blöcke im RAM zwischengespeichert werden.

# 2. Installation & Grundkonfiguration (Praxis)

Wir installieren PBS auf einem minimalen Debian-System und konfigurieren ZFS für maximale Datensicherheit und Performance.

# Voraussetzungen

• OS: Debian 12 (Bookworm) minimal installiert.
• RAM: Mindestens 8 GB, besser 32 GB. Faustregel für ZFS: Plane mindestens 4 GB RAM pro TB Speicherkapazität für optimale ARC-Performance ein.
• Disks: 4+ gleiche, non-SMR Festplatten (NL-SAS oder Enterprise-SSDs). Wir konfigurieren RAIDZ-1 oder Mirror.
• Netzwerk: Dedizierte 10G-Schnittstelle empfohlen, wenn mehr als 10 PVE-Nodes bedient werden sollen.

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

# 2.1 ZFS Pool Setup (Resilienz ist König)

Wir erstellen einen ZFS Pool (backup_pool) und stellen sicher, dass die wichtigsten Performance-Parameter gesetzt sind.

# 1. Installation der ZFS-Tools
apt update && apt install -y zfsutils-linux

# 2. Prüfe die physischen Laufwerke (ersetze /dev/sd[b-e] durch die tatsächlichen Pfade)
ls -l /dev/disk/by-id/ # Immer IDs oder Pfade nutzen, niemals /dev/sdX!

# 3. ZFS Pool Erstellung (Beispiel: RAIDZ-1 über 4 Disks)
# ashift=12 ist kritisch für moderne 4K-Sektoren zur Vermeidung von Write-Amplification.
# autoexpand=on erlaubt das Hinzufügen von VDEVs später.
zpool create -f \
    -o ashift=12 \
    -o autoexpand=on \
    -o listsnaps=on \
    backup_pool raidz1 /dev/disk/by-id/ata-WDC_...1 /dev/disk/by-id/ata-WDC_...2 /dev/disk/by-id/ata-WDC_...3 /dev/disk/by-id/ata-WDC_...4

# 4. ZFS Dateisystem für den Datastore erstellen
# lz4 Kompression ist schnell und effizient für Backup-Daten.
# recordsize wird später im Deep Dive optimiert.
zfs create -o compression=lz4 -o mountpoint=/mnt/datastore backup_pool/pbs_store

# Überprüfen des Mounts
df -h /mnt/datastore

# 2.2 PBS Installation und Erste Konfiguration

# 1. Hinzufügen des Proxmox Backup Repositories
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list
wget http://download.proxmox.com/debian/proxmox-keyring.gpg -O /etc/apt/trusted.gpg.d/proxmox-keyring.gpg

# 2. PBS installieren
apt update
apt install proxmox-backup -y

# 3. Zugriff über Webinterface (https://[PBS_IP]:8007)
# Standardmäßig läuft PBS auf Port 8007.

# 4. Datastore im Webinterface erstellen (GUI-Schritt)
# Beim Erstellen des Datastores 'Datastore/Repository' wählen wir:
# Name: 'main_repo'
# Path: '/mnt/datastore' (Unser ZFS Mount Point)
# Prune Schedule: Keine (Das wird später manuell und granular verwaltet)

# 3. Deep Dive: Konfiguration für Profis

# 3.1 Performance Tuning (ZFS und PBS Interaktion)

Die Wahl des recordsize ist kritisch für Backup-Server.

Optimiertes recordsize: Während das Standard-recordsize von ZFS 128K beträgt, verwenden PBS-Clients Chunks variabler Größe, oft um die 4MB. Wenn die ZFS recordsize zu klein ist, führt dies zu mehr Metadaten-Overhead und fragmentierten Schreibvorgängen.

# 1. ZFS recordsize auf 1M setzen (guter Kompromiss für große Backup-Dateien)
# Hinweis: Dies betrifft nur *neue* Dateien. Am besten direkt bei zfs create nutzen.
zfs set recordsize=1M backup_pool/pbs_store

# 2. ARC Limitierung (Wichtig bei Shared Hosts)
# Wir limitieren den ZFS ARC auf maximal 50% des gesamten RAMs, um dem PBS-Daemon
# und dem OS genug freien Speicher zu lassen.
# Beispiel: Bei 32 GB RAM limitieren wir auf 16 GB (16 * 1024^3 Bytes).
echo "options zfs zfs_arc_max=17179869184" >> /etc/modprobe.d/zfs.conf
# Reboot ist erforderlich, um ARC Limit anzuwenden.

# 3. I/O Scheduler
# Für ZFS auf Enterprise-SSDs oder NVMe sollte der Scheduler auf 'none' (oder 'noop')
# gesetzt werden, da ZFS den I/O selbst effizient verwaltet.
# Bei Spinning Disks ist 'deadline' oder 'cfq' (je nach Kernel-Version) die bessere Wahl,
# aber ZFS übernimmt in der Regel die Optimierung.
# Überprüfe: cat /sys/block/sdX/queue/scheduler

L2ARC (Read Cache) und SLOG (ZFS Intent Log): L2ARC ist meist nur bei Read-heavy Operationen (viele gleichzeitige Restores) sinnvoll. Für reines Backup-Ingest ist RAM (ARC) wichtiger. Wenn extrem niedrige Latenz beim Ingest (synchrone Writes) gefordert ist, kann ein dediziertes, hoch-performantes NVMe-Laufwerk als SLOG (Separate ZFS Intent Log) hinzugefügt werden.

# Beispiel für Hinzufügen eines SLOG (Nur bei Bedarf!)
# Wir nutzen eine kleine, überprovisionierte, batteriegestützte NVMe.
zpool add backup_pool log /dev/disk/by-id/nvme-slog-disk

# 3.2 Hardening & Security

# API-Tokens statt Root-Passwörter

PBS unterstützt API-Tokens, die granular berechtigt werden können. Niemals das Root-Passwort des PBS Servers an PVE-Nodes verteilen.

1. Erstelle im PBS Web-UI einen User (z.B. pve@pbs).
2. Erstelle für jeden PVE-Node einen API-Token unter diesem User (z.B. pve@pbs!pve_node_01).
3. Berechtigungen: Beschränke den Token nur auf Datastore.Backup für den spezifischen Datastore.

# Verschlüsselung

PBS unterstützt client-seitige End-to-End-Verschlüsselung mit AES-256 GCM.

• Vorgehen: Das Verschlüsselungspasswort oder der Key müssen nur dem Client und dem Admin bekannt sein, niemals dem PBS Server selbst. Der PBS Server speichert lediglich die verschlüsselten Chunks.
• Wichtiger Hinweis: Wenn der Key verloren geht, sind die Daten unwiederbringlich verloren. Der Key muss im Key-Management-System (KMS) oder einem verschlüsselten Password Manager sicher abgelegt werden.

# 4. Day-2 Operations: Wartung & Alltag

Nach der erfolgreichen Installation sind die regelmäßigen PBS-Wartungsjobs entscheidend für die Stabilität und Speichereffizienz.

# 4.1 PBS Interne Prozesse

PBS benötigt drei kritische Jobs, die regelmäßig laufen müssen:

1. Pruning (Retention): Löscht Backups, die älter sind als die definierten Regeln (z.B. 7 täglich, 4 wöchentlich, 6 monatlich). Wichtig: Pruning entfernt nur die Referenzen (Index-Dateien), nicht die Chunks selbst.
2. Garbage Collection (GC): Läuft nach dem Pruning. GC durchsucht alle verbliebenen Indizes und löscht die Chunks physisch vom Datenträger, die nicht mehr von irgendeinem Backup-Snapshot referenziert werden. GC ist I/O-intensiv!
   • Empfehlung: GC nur einmal pro Woche (z.B. Sonntag früh) in der Maintenance-Phase ausführen lassen.
3. Verification (Integritätsprüfung): Prüft regelmäßig die Chunk-Hashes gegen die gespeicherten Daten. Sollte mindestens einmal im Monat laufen, um Silent Data Corruption (ZFS kann es erkennen, aber PBS verifiziert die Hash-Zuordnung) auszuschließen.

# Beispiel: Manuelle Ausführung der Garbage Collection auf 'main_repo'
# Nur zur Notfallprüfung, ansonsten über den Scheduler laufen lassen.
proxmox-backup-manager garbage-collection run main_repo

# 4.2 Migration auf neue Hardware

Das Umziehen eines ZFS-basierten PBS Datastores ist relativ einfach, dank zfs send | zfs receive.

# Auf dem ALTEN PBS Server:
zfs snapshot backup_pool/pbs_store@migration_snap

# Senden über SSH zum NEUEN PBS Server (IP 192.168.1.100).
# Die Ziel-ZFS-Partition muss auf dem neuen Host bereits existieren (z.B. new_pool).
zfs send backup_pool/pbs_store@migration_snap | ssh user@192.168.1.100 zfs receive new_pool/pbs_store -F

Nach dem Transfer muss nur der mountpoint des Datastores im PBS Web-UI angepasst werden.

# 4.3 Automatisierung (Ansible)

Ein idempotentes Playbook stellt sicher, dass Benutzer und Datastores korrekt konfiguriert sind, nachdem das ZFS-Backend eingerichtet wurde.

# Ansible Beispiel für die PBS-Konfiguration
---
- name: Configure Proxmox Backup Server
  hosts: pbs_server
  tasks:
    - name: Ensure ZFS Datastore mountpoint exists
      ansible.builtin.file:
        path: /mnt/datastore
        state: directory
        mode: '0755'

    # WICHTIG: Die ZFS-Konfiguration MUSS vorher manuell oder durch ein dediziertes Skript erfolgen.

    - name: Create PBS User for PVE
      community.general.proxmox_backup_user:
        endpoint: https://localhost:8007
        user: pve@pbs
        password: "{{ pbs_user_password }}"
        state: present
        validate_certs: false # In Prod immer auf True, wenn eigene CA genutzt wird.
      delegate_to: localhost

    - name: Ensure 'main_repo' Datastore is registered
      community.general.proxmox_backup_datastore:
        endpoint: https://localhost:8007
        name: main_repo
        path: /mnt/datastore
        state: present
      delegate_to: localhost

    - name: Configure Prune Job (7 days, 4 weeks, 12 months)
      community.general.proxmox_backup_prune_job:
        endpoint: https://localhost:8007
        datastore: main_repo
        keep_daily: 7
        keep_weekly: 4
        keep_monthly: 12
        schedule: 'Mon 04:00'
        state: present
      delegate_to: localhost

# 5. Troubleshooting & “War Stories”

# Top 3 Fehlerbilder

# 1. Symptom A: OOM Killer / Unstable Performance

• Fehlermeldung/Log-Eintrag: dmesg zeigt “Out of Memory: Kill process (pbs-datastore)”.
• Ursache: Der ZFS Adaptive Replacement Cache (ARC) hat zu viel RAM beansprucht, was bei großen Repositories schnell passieren kann, da ZFS versucht, so viel wie möglich zu cachen. Für den PBS Dämon selbst bleibt zu wenig Arbeitsspeicher.
• Lösung: Sofortige Limitierung der ZFS ARC Größe (siehe Sektion 3.1) und Reboot. Wenn dies nicht hilft, muss RAM nachgerüstet werden.

# 2. Symptom B: Backup Failed - “Datastore is Read-Only”

• Fehlermeldung: Im PVE Task-Log: datastore 'main_repo' is currently in read-only state.
• Ursache: PBS hat einen Integritätsfehler bei der Verarbeitung oder beim letzten Verifizierungs-Job festgestellt (z.B. fehlende Chunks oder Index-Korruption). PBS schaltet den Datastore präventiv auf Read-Only, um weitere Korruption zu verhindern. Auch ein voller ZFS-Pool kann dies auslösen.
• Lösung:
  1. Überprüfen Sie den ZFS Status: zpool status -v.
  2. Starten Sie den PBS-Dämon neu.
  3. Führen Sie eine manuelle, vollständige Integritätsprüfung durch: proxmox-backup-manager verify start main_repo.
  4. Wenn die Prüfung erfolgreich ist, setzen Sie den Datastore auf Read/Write zurück (via WebUI oder proxmox-backup-manager datastore update main_repo --options readonly=0).

# 3. Symptom C: Hohe Latenz beim Ingest

• Analyse: iostat -x 5 zeigt hohe await und hohe Queue-Tiefe (Q-Depth). Backups dauern viel länger als erwartet.
• Ursache: Die Deduplizierung benötigt viele zufällige I/O-Vorgänge (Random I/O) auf die Metadaten. Wenn der ZFS ARC zu klein ist oder die zugrundeliegende Hardware (z.B. SMR-Disks oder langsame RAID-Controller) dies nicht leisten kann, bricht die Performance ein.
• Lösung:
  1. Überprüfen Sie die Hardware (Ist es Enterprise-Grade?).
  2. Stellen Sie sicher, dass ZFS ARC optimiert ist (siehe 3.1).
  3. Wenn die Performance nur beim Schreiben kritisch ist: Hinzufügen eines schnellen, dedizierten SLOG-Gerätes (siehe 3.1).

# Recovery Szenarien

War Story: Metadata Corruption Recovery

Wir hatten einmal den Fall, dass durch einen Stromausfall und eine fehlerhafte USV-Konfiguration das ZFS Pool beim Neustart nicht sauber importiert werden konnte (fehlende Transaktionen im ZIL). Das zpool status zeigte DEGRADED und Metadaten-Fehler.

• Vorgehen: Da ZFS Copy-on-Write nutzt, ist die Korruption meist lokal.
  1. Zuerst versuchen, das ZFS Pool mit zpool clear backup_pool und ggf. zpool import -F backup_pool zu reparieren. Achtung: zpool import -F kann Datenverlust bedeuten, aber in diesem Kontext war es der einzige Weg.
  2. Nach erfolgreichem Import, aber bevor der PBS Dämon gestartet wird: Führen Sie einen vollständigen ZFS Scrub (zpool scrub backup_pool) durch.
  3. Sobald ZFS HEALTHY meldet, starten Sie PBS und führen einen Verification Job durch. PBS erkennt alle korrupten Chunks und markiert die betroffenen Backups als fehlerhaft.

graph TD
    A[Backup Failed] --> B{Datastore Read-Only?};
    B -- Ja --> C[Check ZFS Status];
    B -- Nein --> F[Check Disk Space];
    C -- ZFS Fehlerfrei? --> D[Run PBS Verify Job];
    C -- ZFS Fehler --> E[ZFS Scrub & Repair];
    D -- Verify OK --> G[Set Read-Only=0];
    D -- Verify Failed --> H[Identify Corrupt Backups];
    F -- Space OK --> I[Check PBS Daemon Logs (OOM?)];
    F -- Low Space --> J[Run Prune/GC];
    E --> D;

# 6. Monitoring & Alerting

Effektives Monitoring ist entscheidend, um die Effizienz der Deduplizierung und die Datenintegrität sicherzustellen.

# Metriken (Key Performance Indicators - KPIs)

# Alerting-Regeln

• PAGER (Kritisch, 24/7):
  • ZFS Pool Status wechselt zu DEGRADED oder FAULTED.
  • PBS Datastore Read-Only.
  • ZFS Pool Free Space < 5%.
• EMAIL (Warnung, Tagbetrieb):
  • Garbage Collection oder Pruning Job failed.
  • Verification Job findet Hash-Mismatches.
  • ZFS Pool Free Space < 15%.

Tools: Der Proxmox-Stack bietet einen eigenen Prometheus Exporter. Dieser kann die wichtigsten KPIs (insbesondere die Dedup-Ratio) direkt abgreifen und in Grafana visualisieren.

# 7. Fazit & Empfehlung

PBS ist die State-of-the-Art-Lösung für PVE-Backups, vorausgesetzt, die zugrundeliegende Infrastruktur ist robust. Die zentrale Stärke liegt in der Deduplizierung und der integrierten Datenintegrität.

Wann würde ich es nicht einsetzen? Wenn Sie nur eine einzige, kleine VM (< 500GB) sichern müssen und keine Deduplizierung benötigen, könnte ein einfacher NFS-Mount mit verschlüsselten vzdump Dumps überflüssig sein. Sobald jedoch mehr als drei VMs oder Enterprise-Anforderungen (Compliance, Integrität, Geschwindigkeit) ins Spiel kommen, ist PBS obligatorisch.

Ausblick: Die zukünftige Integration von CephFS oder S3-Backend-Support würde PBS noch flexibler machen, aber aktuell bleibt ZFS auf dedizierter Hardware die klar empfohlene Lösung für maximale Performance und Sicherheit.

# Anhang: Cheatsheet

# Referenzen

• Proxmox Backup Server Offizielle Dokumentation
• OpenZFS Best Practices Guide
• PBS Forum: Optimizing ZFS for Backup Loads
• Rust/PBS Source Code Repository (Chunking Logic)