Proxmox Backup Server 4.2: S3-Objektspeicher und parallele Sync-Jobs

Proxmox Backup Server 4.2 (30. April 2026) ist auf dem Papier ein Wartungs- und Feature-Update — bringt aber zwei Neuerungen, die für die Backup-Praxis viel verändern: S3-kompatiblen Objektspeicher als Backend und parallele Sync-Jobs.

Proxmox Backup Server 4.2 — Sync-Job — Ein Sync-Job in Proxmox Backup Server 4.2: Snapshots werden zwischen Datastores repliziert — die Grundlage für Kopien an einem zweiten Standort. (Quelle: Proxmox)

S3 als Backend

Bisher lebten PBS-Datastores auf lokalem Block- oder Dateispeicher. Mit 4.2 lässt sich nun S3-kompatibler Objektspeicher offiziell als Ziel einbinden — inklusive eingebauter Bandbreitenzähler, um unerwartete Kosten-Spitzen in der Cloud früh zu erkennen. Damit wird die Offsite-Kopie flexibler: Wer keine zweite Storage-Box stellen will, kann sie in einen S3-Bucket auslagern, ohne die PBS-eigene Deduplizierung und Verschlüsselung aufzugeben.

Parallele Sync-Jobs

Die Replikation zwischen PBS-Instanzen nutzt jetzt mehrere Worker-Threads und verarbeitet mehrere Backup-Gruppen gleichzeitig. Auf grossen Datastores mit vielen VMs verkürzt das die Sync-Fenster spürbar. Dazu kommt serverseitige Verschlüsselung, die den Replikationsverkehr auch über unvertraute Netze abgesichert hält.

Weiter geputzt

Namespaces lassen sich jetzt gefahrlos umorganisieren, ohne die Katalogkonsistenz zu brechen.
Unterbau auf Debian 13.4 „Trixie" mit Kernel 7.0 als Standard und ZFS 2.4.
Aktualisierte Pakete, breitere Hardware-Unterstützung und Sicherheits-Fixes.

Wie das in die Strategie passt

PBS ist bei uns das Herzstück der 3-2-1-Backup-Strategie: lokales, dedupliziertes Backup auf dem Cluster, dazu eine unveränderliche Offsite-Kopie. Der neue S3-Backend macht genau diese Offsite-Kopie zugänglicher, ohne den bewährten Ablauf aus Verify, Prune und Garbage Collection anzutasten. Auch der TrueNAS-Fileserver hängt nach demselben Muster an der Kette.

Fazit

4.2 ist ein leises, aber gewichtiges Update: S3-Backend und parallele Syncs lösen zwei konkrete Engpässe — Offsite-Flexibilität und Sync-Dauer. Wer PBS produktiv betreibt, sollte das Update einplanen; die Migration ist unkritisch, der Nutzen unmittelbar.

Weiterführende Quellen

Fragen?

Was bringt uns das neue S3-kompatible Backend in PBS 4.2 konkret?+

Bisher lebten PBS-Datastores nur auf lokalem Block- oder Dateispeicher. Mit 4.2 lässt sich S3-kompatibler Objektspeicher offiziell als Ziel einbinden, was die Offsite-Kopie flexibler macht: Wer keine zweite Storage-Box stellen will, lagert sie in einen S3-Bucket aus. Ein eingebauter Bandbreitenzähler warnt früh vor unerwarteten Kosten-Spitzen, und PBS-eigene Deduplizierung und Verschlüsselung bleiben erhalten.

Lohnt sich das Update auf 4.2 für bestehende PBS-Installationen?+

Ja. Wer PBS produktiv betreibt, sollte das Update einplanen, da die Migration unkritisch ist und der Nutzen unmittelbar ist. Parallele Sync-Jobs nutzen mehrere Worker-Threads und verarbeiten mehrere Backup-Gruppen gleichzeitig, was die Sync-Fenster auf grossen Datastores spürbar verkürzt. Dazu kommt serverseitige Verschlüsselung der Replikation, die den Verkehr auch über unvertraute Netze absichert.

Wie passt PBS 4.2 in eine 3-2-1-Backup-Strategie?+

PBS ist bei uns das Herzstück der 3-2-1-Strategie: lokales, dedupliziertes Backup auf dem Cluster plus eine unveränderliche Offsite-Kopie. Das neue S3-Backend macht genau diese Offsite-Kopie zugänglicher, ohne den bewährten Ablauf aus Verify, Prune und Garbage Collection anzutasten. So bleibt die Strategie intakt, und die Offsite-Kopie lässt sich wahlweise statt auf einer Storage-Box auf S3 realisieren.