S3 als Backup-Ziel im PBS — was seit 4.2 wirklich trägt

/01Was das S3-Backend ist — und was es nicht ist

Der Proxmox Backup Server (PBS) sichert Virtualisierungshosts, Container und Dateien üblicherweise auf einen lokalen ZFS-Datastore. Seit Version 4.0 kann dieser Datastore stattdessen — genauer: zusätzlich zu einem lokalen Cache — auf einem S3-kompatiblen Objektspeicher liegen. Gemeint ist damit nicht zwingend Amazons S3, sondern jeder Dienst, der dessen API-Vertrag bedient: AWS S3 selbst, ein selbst betriebener Ceph Rados Gateway, Cloudflare R2 oder ein deutscher Anbieter mit S3-kompatibler Schnittstelle.

Was das S3-Backend ist: ein zusätzliches Ziel für Backup-Metadaten und -Chunks, das PBS über eine gewöhnliche HTTPS-API anspricht, statt Blockgeräte direkt zu beschreiben. Was es nicht ist: ein Tape-Ersatz mit garantierter Unveränderbarkeit, ein Ersatz für den lokalen Datastore oder ein Freibrief, das zweite Rechenzentrum ersatzlos zu streichen. Die Einschränkung, die am häufigsten übersehen wird, steht in der Dokumentation ziemlich trocken: „Proxmox Backup Server does not handle bucket creation and access control" — Bucket anlegen, Berechtigungen vergeben, Lebenszyklus-Regeln setzen bleibt Aufgabe des Betreibers, nicht des Backup-Servers.

/02Von Tech Preview zu offiziell: der Weg über 4.0, 4.1, 4.2

Proxmox hat das S3-Backend nicht in einem Schritt freigegeben, sondern über drei Hauptversionen gereift. Mit PBS 4.0 (06.08.2025) kam die Anbindung als Technology Preview: „Proxmox Backup Server can now connect to object stores that provide an S3-compatible API." PBS 4.1 (26.11.2025) blieb explizit auf demselben Stand — „S3 Backend (Technology Preview)" — und ergänzte vor allem eine Bandbreitenbegrenzung für S3-Endpunkte. Erst mit PBS 4.2, veröffentlicht am 29.04.2026, wechselt der Status: „Using S3-compatible object stores as a backup storage backend has graduated from the technology preview phase and is now officially supported."

Der Unterschied zwischen Tech Preview und offiziellem Status ist keine Formsache. Ein Tech-Preview-Feature kann sich in einem Minor-Release noch in Verhalten und Datenformat ändern, Proxmox rät ausdrücklich von produktivem Einsatz ab. Mit 4.2 gilt das S3-Backend als tragfähig genug für den regulären Betrieb — Proxmox selbst nennt in derselben Version zusätzlich neue Zähler für S3-Anfragen und Traffic, die im Datastore-Überblick sichtbar werden, ein Zeichen dafür, dass die Funktion jetzt auch überwacht werden soll wie jede andere Produktivkomponente.

Mitgeliefert wird PBS 4.2 auf Debian 13 „Trixie" (Punktstand 13.4) mit Linux-Kernel 7.0 als neuem Standard und ZFS 2.4. Wer noch auf 4.0 oder 4.1 läuft und S3 einsetzt, sollte den Wechsel auf 4.2 in die nächste Wartungsplanung aufnehmen — nicht wegen eines akuten Fehlers, sondern weil der offizielle Support-Status an die aktuelle Version gebunden ist.

/03Konfiguration: Endpoint, Datastore, lokaler Cache

Die Einrichtung läuft über zwei Objekte: einen S3-Endpunkt mit Zugangsdaten und einen Datastore, der diesen Endpunkt als Backend referenziert. Ein Endpunkt fasst Zugriffsschlüssel, Region und Adressierung zusammen und lässt sich mehrfach wiederverwenden, falls mehrere Datastores auf denselben Anbieter zeigen.

# S3-Endpunkt anlegen (Beispiel AWS S3, vhost-style)
proxmox-backup-manager s3 endpoint create my-s3-ep \
  --access-key 'XXX' --secret-key 'XXX' \
  --endpoint '{{bucket}}.s3.{{region}}.amazonaws.com' \
  --region eu-central-1

# Datastore mit S3-Backend anlegen — Pfad ist der lokale Cache, nicht die Nutzdaten
proxmox-backup-manager datastore create my-s3-store \
  /mnt/datastore/my-s3-store-cache \
  --backend type=s3,client=my-s3-ep,bucket=pbs-s3-bucket

# Bestand pruefen
proxmox-backup-manager datastore list

Die Dokumentation nennt neben AWS S3 zwei weitere Konfigurationsbeispiele: einen selbst betriebenen Ceph Rados Gateway und Cloudflare R2, beide im Path-Style adressiert statt im vhost-Style von AWS. Für den Zugriff verlangt PBS vier S3-Berechtigungen auf dem Bucket — Lesen, Schreiben, Auflisten und Löschen. Ohne Löschrecht laufen spätere Aufräumarbeiten (Snapshot-Rotation, Garbage Collection) ins Leere, ohne dass das beim Anlegen sofort auffällt.

/04Warum ein lokaler Cache trotzdem Pflicht bleibt

Der naheliegende Gedanke — „S3 ersetzt den lokalen Datastore vollständig" — trifft nicht zu. Die Dokumentation ist hier eindeutig: „the datastore requires nevertheless a local persistent cache, used to increase performance and reduce the number of requests to the backend." Empfohlen werden 64 bis 128 GiB Cache-Größe.

Der Grund liegt im Charakter der Deduplizierung. Jeder eingehende Snapshot muss gegen bereits vorhandene Chunks abgeglichen werden, um zu entscheiden, was neu übertragen werden muss und was schon existiert. Ohne Cache würde jeder dieser Abgleiche eine S3-Anfrage auslösen — bei Millionen Chunks in einem gewachsenen Datastore ein Kostentreiber und ein Geschwindigkeitsproblem zugleich, weil jede Anfrage Latenz zum Objektspeicher kostet, selbst wenn der Chunk am Ende gar nicht übertragen werden muss. Der Cache hält die Metadaten und häufig genutzten Chunks lokal vor und reduziert damit sowohl die Zahl der Anfragen als auch deren Kosten, denn S3-Anbieter berechnen in der Regel auch Lese- und Listenoperationen, nicht nur gespeicherte Daten.

Eine zweite Einschränkung betrifft die Exklusivität: „A datastore cannot be shared between multiple Proxmox Backup Server instances, only one instance can operate on the datastore at a time." Wer mehrere PBS-Server betreibt, kann also nicht denselben Bucket als gemeinsames Ziel nutzen — jeder Server braucht seinen eigenen Bucket oder zumindest sein eigenes Datastore-Präfix.

/05Deduplizierung und Chunking — was über die Leitung geht

Um zu verstehen, wie viel Datenverkehr ein S3-Backend erzeugt, hilft ein Blick auf das Speicherformat selbst — es ändert sich durch S3 nicht, wird aber durch die Netzanbindung stärker spürbar. PBS zerlegt Backups in Chunks und identifiziert jeden über eine SHA-256-Prüfsumme: „A chunk is some (possibly encrypted) data with a CRC-32 checksum at the end and a type marker at the beginning. It is identified by the SHA-256 checksum of its content." Für Dateien nutzt PBS Content-defined Chunking mit einem Buzhash-Verfahren über das intern erzeugte pxar-Archiv, für blockbasierte Sicherungen wie VM-Images kommen feste Chunk-Größen zum Einsatz — typischerweise 4 MiB pro Chunk.

Erkennt PBS beim nächsten Lauf einen bereits vorhandenen Chunk, überträgt es nur die Prüfsumme statt der vollen Daten — der eigentliche Mechanismus der Deduplizierung. Für Dateibackups kommt der sogenannte Metadata-Modus hinzu: Ändert sich an einer Datei nur der Zeitstempel oder die Berechtigung, nicht aber der Inhalt, erkennt PBS das über Dateigröße, -typ, Eigentümer, Rechte, ACLs und die mtime — und liest die Datei gar nicht erst neu ein, sondern übernimmt die vorhandenen Chunk-Referenzen aus dem letzten Snapshot.

Für ein S3-Backend heißt das: Ein voller Erstlauf überträgt tatsächlich alle Chunks in den Objektspeicher, jeder Folgelauf im Regelfall nur die Differenz. Genau diese Differenz-Logik ist auch der Grund, warum Object Lock auf Chunk-Ebene technisch unangenehm ist — dazu Abschnitt 7.

/06Die dritte Kopie: 3-2-1 ohne zweites Rechenzentrum

Die 3-2-1-Regel verlangt drei Kopien der Daten auf zwei verschiedenen Medien, eine davon extern. HostSpezial deckt die zweite Kopie über den Ausweichstandort Neustadt (SWN) neben dem primären Rechenzentrum in Coburg (SÜC) ab — eine Georedundanz, die bewusst regional bleibt, nicht über mehrere hundert Kilometer verteilt ist. Ein S3-Ziel bei einem externen Anbieter liefert dazu eine dritte, unabhängige Kopie, ohne dass ein zweites eigenes Rechenzentrum nötig wäre.

Das ist der eigentliche Wert des S3-Backends für den Mittelstand: Es macht die dritte Kopie budgetierbar. Statt Racks, Klimatisierung und eine zweite Netzanbindung zu kalkulieren, wird die dritte Kopie zu einer laufenden Position im S3-Vertrag. Zwei Anbieterbeispiele mit vollständig einsehbaren Preisen: Backblaze B2 nennt „Starts at $6.95 / TB / mo" bei kostenlosem Egress bis zum Dreifachen des gespeicherten Volumens; Wasabi wirbt mit „Starting at $7.99 TB/month" und „No fees for egress or API requests" (beide Preisseiten abgerufen am 31.08.2026). Die Differenz zwischen beiden liegt weniger im Grundpreis als in der Egress-Politik — wer im Ernstfall tatsächlich zurückspielen muss, zahlt bei manchen Anbietern für genau diesen Moment extra, bei anderen nicht.

Wichtig für die Kalkulation: Diese Zahlen sind Speicherkosten, keine Wiederherstellungskosten. Die Dokumentation weist selbst darauf hin, dass der Betrieb eines S3-Backends zusätzliche Kosten verursachen kann, etwa durch Bandbreitengebühren — wie stark, hängt vom Anbieter und vom Umfang der Rücksicherungen ab und lässt sich nicht pauschal beziffern.

/07Object Lock: der offene Punkt bei der Unveränderbarkeit

Ein Objektspeicher ist nicht automatisch ein unveränderlicher Speicher. Unveränderbarkeit im S3-Umfeld heißt konkret Object Lock — eine Bucket-Funktion, die verhindert, dass ein Objekt vor Ablauf einer Frist gelöscht oder überschrieben wird, selbst mit gültigen Zugangsdaten. Genau das ist der Baustein, der einen Objektspeicher gegen Ransomware und gegen kompromittierte Zugangsdaten absichern würde.

Für das S3-Backend des Proxmox Backup Server gilt Stand heute: Object Lock wird nicht unterstützt. Auf die direkte Frage im Proxmox-Forum antwortet ein Proxmox-Mitarbeiter unmissverständlich: „object locking is currently not part of the PBS S3 implementation feature set." Der Grund liegt in der Deduplizierung aus Abschnitt 5: Chunks werden von mehreren Snapshots gemeinsam referenziert. Ein Community-Nutzer bringt das Problem auf den Punkt — würde man Object Lock naiv auf einzelne Chunks anwenden, könnten „old chunks from earlier backup have their object lock expire and can be deleted even if still required in newer backups": Ein Chunk, dessen Sperre nach der Aufbewahrungsfrist des ältesten Snapshots ausläuft, kann verschwinden, obwohl ein neuerer Snapshot ihn noch referenziert.

Der Proxmox-Mitarbeiter deutet an, dass eine Lösung technisch möglich wäre, wenn man Object Lock gezielt auf Manifest-, Index- und Referenz-Chunks anwendet statt pauschal auf alle Chunks — das ist aber Zukunftsmusik, kein aktueller Funktionsumfang. Im Bugzilla-Tracker von Proxmox ist die Anforderung unter der Nummer 6780 erfasst, Status „ASSIGNED", mit ausdrücklichem Verweis auf Ransomware-Schutz und die Konkurrenzfähigkeit zu Veeam, das Object Lock in seinen S3-Zielen bereits unterstützt. Ein Termin für die Umsetzung steht dort nicht.

/08Wo es hakt

Kein Object Lock, siehe oben

Der wichtigste Punkt steht bereits in Abschnitt 7 und wird hier bewusst wiederholt, weil er in Verkaufsgesprächen am häufigsten unterschlagen wird: Unveränderbarkeit ist bei PBS-S3 aktuell Aufgabe der Zugriffskontrolle, nicht des Objektspeichers selbst.

Wiederherstellung ist ein eigenes Thema

Ein Restore über S3 liest Chunks über die Netzwerk-API statt vom lokalen Block-Gerät. Wie schnell das im Ernstfall geht, hängt von der Bandbreite zum Anbieter, dessen Antwortzeiten und der Größe des wiederherzustellenden Datenbestands ab — belastbare Zahlen liefert nur ein Restore-Test in der eigenen Umgebung, jede pauschale Angabe wäre geraten. Wer S3 als alleiniges Backup-Ziel plant, sollte die Restore-Zeit vor dem produktiven Einsatz einmal real messen, nicht erst im Ernstfall.

Speicherausfall bricht Aufräumarbeiten ab

Läuft der Objektspeicher während einer Schreiboperation voll, warnt die Dokumentation ausdrücklich vor Folgefehlern: Aufräumvorgänge wie Garbage Collection können dann fehlschlagen. Ein Kontingent-Alarm beim S3-Anbieter gehört deshalb zur Grundausstattung, nicht zur Kür.

Bucket-Verwaltung bleibt beim Betreiber

PBS legt keinen Bucket an und verwaltet keine Zugriffsrechte darauf. Wer den Bucket zu offen konfiguriert oder Lebenszyklus-Regeln vergisst, die Objekte vorzeitig löschen, verliert Daten, ohne dass PBS davon etwas merkt.

Kosten laufen weiter, auch ohne Restore

Speicherkosten fallen unabhängig davon an, ob je wiederhergestellt wird. Bei wachsendem Datenbestand und mehrjähriger Aufbewahrung — wie sie NIS2-Betroffene oder ISO/IEC 27001-zertifizierte Betriebe oft vorhalten — summiert sich das über Jahre, ohne dass ein einziger Ernstfall eingetreten sein muss.

/09Wann sich das lohnt — und wann nicht

Dafür spricht

• Die dritte Kopie fehlt bislang: Lokaler Datastore und Ausweichstandort sind vorhanden, eine unabhängige, wirklich externe Kopie nicht. S3 schließt genau diese Lücke, ohne ein drittes Rechenzentrum zu erfordern.
• Die Aufbewahrungsfristen sind lang: Wer Backups über Jahre vorhalten muss, profitiert vom nutzungsabhängigen Preismodell eines Objektspeichers gegenüber dem Kauf zusätzlicher lokaler Kapazität.
• PBS läuft bereits auf 4.2 oder neuer: Nur ab dieser Version gilt S3 als offiziell unterstützt statt als Tech Preview — ein Umstieg auf einer älteren Version wäre ein Griff nach einer Funktion, die Proxmox selbst noch nicht für produktiv erklärt hat.

Dagegen spricht

• Unveränderbarkeit ist die zentrale Anforderung: Wer Object Lock für Ransomware-Schutz oder eine Versicherungsauflage zwingend braucht, findet das bei PBS-S3 aktuell nicht. Dann bleibt entweder ein Backup-Produkt mit vorhandener Object-Lock-Unterstützung oder eine Kombination aus getrennten Zugangsdaten und Offline-Kopie die tragfähigere Wahl.
• Die Restore-Zeit ist kritisch: Bei sehr kurzen RTO-Vorgaben ist ein lokaler oder replizierter Datastore in aller Regel schneller zurückgespielt als ein S3-Ziel über das Internet.
• Es gibt noch keinen lokalen Datastore: S3 ersetzt den lokalen Cache nicht — ohne funktionierenden Datastore mit ausreichend lokalem Speicher lässt sich das S3-Backend gar nicht sinnvoll betreiben.
• Die Bandbreite zum Objektspeicher ist knapp: Bei begrenzter Internetanbindung dauert schon der Erstlauf mit vollständiger Chunk-Übertragung entsprechend lange, und jede spätere Rücksicherung konkurriert mit dem laufenden Betrieb um dieselbe Leitung.

In der Praxis ist das selten ein Entweder-oder. Der naheliegende Aufbau bleibt: lokaler Datastore für schnelle Restores, Ausweichstandort für die zweite Kopie, S3 für die dritte, wirklich externe Kopie mit langer Aufbewahrung — und ein Verzicht auf das Versprechen der Unveränderbarkeit, solange PBS Object Lock nicht unterstützt.

/10Häufige Fragen