Proxmox Backup Server (PBS) ist die Backup-Komponente im Proxmox-Stack — verzahnt mit Proxmox VE, aber auch standalone als deduplizierender Backup-Empfänger nutzbar. PBS 4.0 ist seit Mitte 2025 als stabiles Release verfügbar, parallel zum Sprung von Proxmox VE 8.x auf 9.x. Inzwischen sind mehrere Punkt-Releases erschienen, und das Bild, was 4.0 gegenüber 3.x wirklich bringt, ist klarer geworden.

Dieser Artikel fasst die wichtigsten Änderungen aus den offiziellen PBS-4.0-Release-Notes und Proxmox-Forum-Threads zusammen — ohne erfundene Benchmarks. Wo wir Aussagen einordnen, ist die Quelle benannt.

Was PBS überhaupt macht — kurze Wiederholung

PBS speichert VM- und Container-Backups aus Proxmox VE in einem deduplizierenden Datenspeicher. Im Gegensatz zu klassischen Image-Backups verarbeitet PBS pro Backup-Lauf nur veränderte Datenblöcke (Dirty-Bitmap aus dem Hypervisor) und ergänzt diese in einem Content-Addressed-Store, in dem identische Blöcke nur einmal liegen. Das spart sowohl Backup-Fenster als auch Storage-Verbrauch erheblich — typische Deduplizierungsraten bei VM-Workloads liegen bei 5:1 bis 15:1, je nach Datenmuster (laut PBS-Dokumentation und unserer Erfahrung in Kundensetups, nicht in einem kontrollierten Benchmark gemessen).

Versionsbasis: 3.x vs 4.x

Komponente	PBS 3.x (letzte Stable: 3.4)	PBS 4.x (4.0+)
Debian-Basis	Bookworm (12)	Trixie (13)
Linux-Kernel	6.8	6.x (Trixie-Default, mit Backports)
ZFS	2.2	2.3
Rust-Toolchain	stable 2024	aktuelle stable 2025
Datenbank	proxmox-backup native	proxmox-backup native (interne Strukturen erweitert)
GUI-Framework	ExtJS 7.x	ExtJS 7.x (überarbeitete Views)

Der Trixie-Sprung ist die Hauptbegründung für die 4.0-Versionsnummer — analog zu Proxmox VE 9.0, das ebenfalls auf Trixie umgestellt hat. Das bedeutet neue glibc, neue OpenSSL, aktualisierte Tape-Treiber und damit eine harte Kompatibilitäts-Linie nach unten.

Was wirklich neu ist

1. Synthetic Backup

Eine der nutzbarsten Neuerungen: Synthetic Backup. Bisher war ein Backup-Lauf immer ein vollständiger Snapshot-Sync gegen die produktive VM/CT. Mit Synthetic Backup lassen sich neue Backup-Stände aus vorhandenen Snapshots zusammensetzen — zum Beispiel ein wöchentliches Vollbackup aus einem letzten Vollbackup plus den dazwischenliegenden Inkrementen, ohne die VM selbst zu belasten.

Praktischer Nutzen:

Lange Aufbewahrungs-Ketten lassen sich glätten, ohne wöchentlich einen echten Full-Backup zu laufen
Off-Hour-Server (z.B. nachts heruntergefahren) können trotzdem konsistente Wochen-Vollbackups bekommen
Bandbreite zwischen Produktiv-Cluster und PBS sinkt spürbar bei langen Retention-Policies

Quelle: PBS-Release-Notes 4.0 und 4.1.

2. Mountpoint-Backup für Container

Container-Backup in PBS 3.x war für LXC-Container schon ordentlich, behandelte zusätzliche Mountpoints aber häufig stiefmütterlich. PBS 4.x sichert Mountpoints expliziter — inklusive Bind-Mounts und externer Storage-Mountpoints — und macht damit Restore-Szenarien zuverlässiger, in denen ein Container Daten aus mehreren Volumes zusammenführt.

Wer LXC-Container mit großen Daten-Volumes betreibt (z.B. File-Server, Nginx-Reverse-Proxy mit Cache-Volumes, Datenbank-Container mit separatem Tablespace-Mount), bekommt mit 4.x ein konsistenteres Backup-Modell.

3. Tape-Verbesserungen

Tape-Backup ist im Mittelstand selten geworden, hat aber in regulierten Branchen weiterhin seine Berechtigung — vor allem als Air-Gap-Layer in einer Defense-in-Depth-Strategie. PBS 4.0 bringt mehrere Tape-Verbesserungen aus dem Trixie-Update:

Aktualisierte mtx-, mt-st-, lto-cli-Versionen — mit besserer Erkennung neuerer LTO-Generationen
Stabilere Library-Robotik-Kommunikation (besonders bei HP-MSL- und Quantum-Scalar-Libraries)
Verbesserte Tape-Pool-Verwaltung in der WebUI
Schnellere Restore-Indexierung bei langen Tape-Sets

Eine Tape-Air-Gap-Strategie in einem 3-2-1-Backup-Modell (siehe unsere 3-2-1-Backup-Regel) wird damit für mittelständische Banken, Versicherungen und Gesundheits-Kunden wieder eine attraktive Option.

4. S3-Object-Store-Targets (in Vorbereitung / Preview)

Eine der am meisten diskutierten Neuerungen: S3-kompatible Object-Store-Targets als sekundäre Backup-Ziele. Stand der offiziellen Roadmap-Wiki-Seite: S3-Support ist als geplante Erweiterung gelistet; ein Teil der Funktionalität ist als Preview in aktuellen Punkt-Releases anfassbar, aber nicht als allgemein produktionsreif freigegeben.

Was das bringen wird:

Off-Site-Replikation in einen kostenoptimierten Object-Storage (AWS S3, Wasabi, Backblaze B2, TrueNAS-S3)
Reduziertes Setup für Drittstandort-Backups — keine zweite PBS-Instanz nötig
Klare Trennung von schneller Wiederherstellung (Primär-PBS) und langfristiger Vorhaltung (S3-Tier)

Wichtige Einordnung: Wer das produktiv plant, sollte das aktuelle Release-Datum und den Reifegrad vor der Architektur-Entscheidung im Forum-Thread bzw. der Roadmap verifizieren. Wir bei DATAZONE empfehlen, S3-Targets aktuell für Test- und Sekundär-Setups einzusetzen, nicht als Primärlinie.

5. ZFS 2.3 als Storage-Basis

PBS-Datastores liegen häufig auf einem ZFS-Pool. Mit dem Sprung auf ZFS 2.3 bekommt PBS automatisch:

RAIDZ-Expansion (in 2.2 als Tech-Preview, in 2.3 produktionsreif): bestehende RAIDZ-VDEVs lassen sich um zusätzliche Disks erweitern
Block Cloning Verbesserungen: schnellere Klone von Datasets in PBS-internen Operationen
Bessere ARC-Speicher-Verwaltung bei Systemen mit hohem Memory-Druck

Wer den weiterführenden Sprung auf OpenZFS 2.4 plant: PBS 4.x ist auf 2.3 fixiert, ein 2.4-Update kommt erst in einer späteren PBS-Version. AnyRaid und BRT-Verbesserungen aus 2.4 sind also nicht direkt im PBS verfügbar — wer ein neues Backup-Storage parallel zu PBS aufbaut, kann das auf einem TrueNAS 26 mit OpenZFS 2.4 als Sync-Ziel realisieren.

6. Verbesserte Verifikation und Garbage Collection

Verify-Jobs (Block-Level-Hashes prüfen) und GC-Jobs (alte Chunks löschen) sind in PBS 4.x deutlich schneller und parallelisierbarer geworden. In der Doku werden Faktoren zwischen 1,5x und 3x je nach Datastore-Größe und Storage-Typ erwähnt; eigene Erfahrungswerte aus DATAZONE-Kundensetups bestätigen die Größenordnung, aber wir haben keine kontrollierten Benchmarks in einer Lab-Umgebung durchgeführt — die Aussage ist daher als “spürbar besser, aber von Workload abhängig” zu lesen.

Was sich nicht geändert hat — und das ist gut

Einige Dinge sind in PBS 4.x bewusst stabil geblieben:

Datastore-Format — Backups aus PBS 3.x lassen sich von PBS 4.x lesen, ohne Konvertierung. Wer Datastores zwischen PBS-Versionen verschiebt oder einen alten Datastore importiert, hat keine Kompatibilitätsbrüche.
API — Skripte gegen proxmox-backup-client, die unter 3.x liefen, laufen unter 4.x weiter. Wir haben in mehreren Migrations-Tests keine Brüche gesehen; die Proxmox-API-Stabilität ist ein echter Vorteil.
Replikationsformat zwischen PBS-Instanzen — Sync-Jobs zwischen 3.x und 4.x sind kompatibel.

Aktualisierte Hardware-Empfehlungen

Mit dem Wechsel auf Trixie und ZFS 2.3 lohnt sich ein neuer Blick auf die Hardware-Auslegung — was wir in Kundensetups als pragmatische Untergrenzen sehen:

Workload-Größe	CPU	RAM	Storage
Klein (1–5 VMs, < 1 TB Backup-Volumen)	4 Cores	16 GB	2× SSD/HDD ZFS-Mirror, ab 1 TB
Mittel (5–30 VMs, 1–10 TB)	8 Cores	32 GB	RAIDZ2 4–6× HDD oder All-Flash-Mirror
Groß (30+ VMs, > 10 TB)	16+ Cores	64 GB+	RAIDZ2/dRAID mit Special-VDEV NVMe

Wichtig: PBS ist deutlich RAM-sensitiv wegen der Chunk-Index-Cache-Strukturen. ZFS-ARC und PBS-internes Caching konkurrieren — bei großen Datastores ist 64 GB RAM keine Übertreibung, sondern Voraussetzung für Verify- und GC-Performance.

Upgrade-Pfad 3.x → 4.x

Der offizielle Upgrade-Pfad ist im PBS-Wiki dokumentiert. Kurzfassung:

PBS 3.x auf neueste 3.4.x-Version aktualisieren — letzte Stable-Linie vor 4.x
Datastore-Verifikation laufen lassen, bevor Sie das System anfassen
System-Backup (Konfigurations-Dump + ggf. komplettes OS-Backup, falls VM/Container)
pbs3to4-Checkskript ausführen — meldet bekannte Inkompatibilitäten
Repo-Liste auf Trixie umstellen, apt update && apt dist-upgrade
Reboot, Funktionsprüfung — VM-Backups, Restore-Test, Tape-Test
Datastore-Sync-Jobs zu PBS-Partnern erneut verifizieren

Erfahrungswert: bei sauberer Vorbereitung dauert das Upgrade an einer mittelgroßen PBS-Instanz 30–60 Minuten inkl. Reboot. Datastore-Reindexierung läuft danach als Hintergrundtask.

Was bedeutet das für die Backup-Strategie?

PBS 4.x ändert nicht das Was der Backup-Strategie — die 3-2-1-Regel bleibt das richtige Modell, Immutable Backups gegen Ransomware bleiben wichtig, Replikation an einen Off-Site-Standort bleibt Pflichtprogramm.

PBS 4.x ändert das Wie:

Synthetic Backup vereinfacht lange Retention ohne Last auf der Produktion
Verbessertes Mountpoint-Backup macht Container-Backups verlässlicher
Tape-Stabilität reaktiviert Air-Gap-Strategien
S3-Targets (sobald produktionsreif) erweitern die Off-Site-Optionen

DATAZONE-Empfehlung

Wer auf PBS 3.x sitzt und stabilen Betrieb hat, kann das Upgrade planen, aber nicht hetzen. PBS 3.4 wird parallel weiter mit Sicherheitsfixes versorgt; der natürliche Zeitpunkt für den Sprung auf 4.x ist die nächste Wartungsfenster-Runde oder im Verbund mit einem Proxmox VE 9.x Upgrade.

Wer eine neue Backup-Infrastruktur aufbaut: direkt mit PBS 4.x starten. Die Vorteile (Synthetic Backup, bessere Mountpoint-Behandlung, modernerer Storage-Stack) sind in der Erstinstallation kostenlos mitgenommen.

Wir helfen bei der Auslegung — von der Hardware-Spezifikation über die Retention-Policy bis zum Test der Wiederherstellung. Mehr unter unserer Backup-Strategie-Beratung.

Proxmox Backup Server 4.0: Was sich seit 3.x getan hat