Proxmox Backup Server (PBS) 4.2 unterstützt seit April 2026 nativ S3-kompatiblen Objektspeicher als Backup-Backend — und das ändert die Kostenrechnung für Offsite-Backups grundlegend. Dieser Artikel dokumentiert die Einrichtung mit Hetzner Object Storage, inklusive aller Stolperstellen, die mir dabei begegnet sind.
Hintergrund: PBSaaS vs. S3
Wer Proxmox einsetzt und ein georedundantes Offsite-Backup benötigt, stand bisher vor der Wahl: entweder einen „Proxmox Backup Server as a Service“ (z. B. bei partimus für ~21–28 €/TB/Monat) buchen, oder mit Rclone/Restic-Skripten selbst etwas bauen und dabei die native PBS-Integration verlieren.
Mit PBS 4.2 gibt es jetzt eine dritte Option: S3-kompatibler Speicher direkt als Datastore — mit voller PBS-Deduplizierung, Komprimierung und nativer Proxmox-Integration.
Kostenvergleich für 10 TB:
| Option | Preis/Monat (netto) |
|---|---|
| PBSaaS NVMe (z. B. partimus) | ~280 € |
| PBSaaS HDD (z. B. partimus) | ~210 € |
| Hetzner Object Storage | ~50 € |
Der Haken: PBS benötigt für S3-Datastores einen lokalen Cache (empfohlen: 64–128 GB), der auf dem PBS-Host vorgehalten wird. Für ein reines Disaster-Recovery-Szenario ist das aber völlig akzeptabel.
Standortwahl: Warum Helsinki?
Hetzner bietet Object Storage in drei Standorten an: Falkenstein (FSN1), Nürnberg (NBG1) und Helsinki (HEL1). Für ein Offsite-Backup ist Helsinki die beste Wahl — nicht trotz, sondern wegen der größeren Entfernung.
Der Sinn eines Offsite-Backups ist maximale geografische und infrastrukturelle Trennung vom Primärsystem. Bei einem Brand, Stromausfall oder regulatorischen Problem, das deutsche Rechenzentren betrifft, ist Helsinki davon unabhängig. Die höhere Latenz (~23 ms vs. ~3 ms für deutsche Standorte) ist bei Backup-Workloads völlig irrelevant.
Alle drei Standorte sind ISO 27001:2022 zertifiziert und preislich identisch (~5 €/TB/Monat).
Einrichtung: Schritt für Schritt
1. Bucket in der Hetzner Cloud Console anlegen
In der Hetzner Cloud Console unter „Object Storage“ einen neuen Bucket erstellen. Wichtig: S3 Object Lock deaktiviert lassen — PBS unterstützt das nicht und eine aktivierte Object Lock kann den Datastore korrumpieren.
Anschließend unter dem Bucket S3-API-Zugangsdaten (Access Key + Secret Key) erstellen.
2. S3-Endpoint in PBS konfigurieren
In der PBS-Weboberfläche unter Configuration → S3 Endpoints → Add oder per CLI:
proxmox-backup-manager s3 endpoint create Hetzner-Helsinki \
--access-key DEIN_ACCESS_KEY \
--secret-key DEIN_SECRET_KEY \
--endpoint 'hel1.your-objectstorage.com' \
--region hel1 \
--path-style true
Achtung — die drei häufigsten Fehler hier:
Fehler 1: Falsche Region Der Standard in der PBS-GUI ist us-west-1. Das führt zu:
LocationConstraintConflict: The location constraint differs from the location you are trying to access.
→ Region muss hel1 sein.
Fehler 2: Falsches Endpoint-Format Wer den Bucket-Namen in die Endpoint-URL einbaut (z. B. pbs1-meinbucket.hel1.your-objectstorage.com) und dann im Datastore den Bucket nochmal angibt, erzeugt doppelte Bucket-Präfixe. Korrekte Endpoint-URL ist:
hel1.your-objectstorage.com
(ohne Bucket-Präfix, da Path-Style genutzt wird — siehe Fehler 3)
Fehler 3: Path-Style nicht aktiviert Ohne --path-style true schlägt jede PUT-Operation fehl:
failed to upload in-use marker for datastore: unexpected status code 404 Not Found
→ --path-style true ist für Hetzner Object Storage zwingend erforderlich.
3. Verbindung testen
# Bucket-Erreichbarkeit prüfen
proxmox-backup-manager s3 endpoint list-buckets Hetzner-Helsinki
# Vollständiger Verbindungstest inkl. Schreibzugriff
proxmox-backup-manager s3 check Hetzner-Helsinki pbs1-meinbucket
Wenn list-buckets funktioniert aber check mit LocationConstraintConflict scheitert → Region falsch. Wenn check mit InvalidBucketName scheitert → Path-Style fehlt. Wenn check mit 404 Not Found scheitert → Endpoint-URL prüfen.
4. Lokalen Cache-Ordner anlegen
PBS benötigt zwingend einen lokalen Cache für S3-Datastores. Empfehlenswert ist ein schneller lokaler Datenträger (SSD) mit 64–128 GB Platz.
Wichtig: Der Cache-Ordner darf nicht innerhalb eines bereits bestehenden PBS-Datastores liegen. Das führt zu:
parameter verification failed - 'path': nested datastores not allowed
Geeigneter Pfad (auf der Root-Partition oder einem separaten Volume):
mkdir -p /var/lib/proxmox-backup/s3-cache
Nicht geeignet (wenn /mnt/backup-primary bereits ein Datastore ist):
# ❌ Funktioniert nicht:
mkdir -p /mnt/backup-primary/s3-cache
5. Datastore anlegen
In der PBS-GUI unter Datastore → Add → S3 oder per CLI:
proxmox-backup-manager datastore create S3-Hetzner-Helsinki \
/var/lib/proxmox-backup/s3-cache \
--backend "type=s3,s3-endpoint=Hetzner-Helsinki,bucket=pbs1-meinbucket"
GC-Zeitplan und Prune-Zeitplan können auf daily belassen werden.
Troubleshooting-Übersicht
| Fehlermeldung | Ursache | Lösung |
|---|---|---|
LocationConstraintConflict | Falsche Region konfiguriert | Region auf hel1 setzen |
InvalidBucketName | Path-Style nicht aktiviert | --path-style true setzen |
404 Not Found beim Upload | Endpoint-URL falsch | URL auf hel1.your-objectstorage.com korrigieren |
nested datastores not allowed | Cache-Pfad liegt in bestehendem Datastore | Cache-Ordner außerhalb bestehender Datastores anlegen |
EEXIST: File exists beim Anlegen | Reste früherer Versuche im Cache-Ordner | rm -rf /pfad/zum/cache && mkdir -p /pfad/zum/cache |
Fazit
Die native S3-Unterstützung in PBS 4.2 ist ein echter Gamechanger für kostengünstiges Offsite-Backup in Proxmox-Umgebungen. Mit Hetzner Object Storage in Helsinki lässt sich ein ISO-27001-zertifiziertes, georedundantes Backup für einen Bruchteil der Kosten eines managed PBSaaS-Dienstes betreiben — mit voller PBS-Deduplizierung und nativer Proxmox-Integration.
Die Einrichtung ist geradlinig, sobald man die drei Stolpersteine kennt: Region hel1 setzen, Endpoint ohne Bucket-Präfix, und Path-Style aktivieren.
Getestet mit Proxmox Backup Server 4.2 und Hetzner Object Storage Helsinki (HEL1), Mai 2026.