Mit Proxmox Backup Server 4.2 (veröffentlicht am 29. April 2026) verlässt das S3-Backend den Tech-Preview-Status und gilt offiziell als stabil. Damit lassen sich S3-kompatible Objektspeicher endlich produktionsnah als Offsite-Datastore einsetzen – ideal für Ransomware-Schutz und 3-2-1-Strategie. Allerdings steckt eine gefährliche Falle drin: S3 Object Lock und die Chunk-basierte Deduplizierung von PBS vertragen sich fundamental nicht. Wer Object Lock direkt auf dem PBS-Bucket aktiviert, bekommt einen inkonsistenten Datastore – ohne klare Fehlermeldung. Diese Anleitung zeigt den einzigen funktionierenden Weg zu wirklich unveränderlichen Offsite-Backups mit PBS 4.2, den richtigen Anbieter für dein Budget und wie du die häufigsten Fehler vermeidest.

Voraussetzungen

Proxmox Backup Server 4.2 (ISO von proxmox.com, basiert auf Debian 13 „Trixie", Kernel 7.0)
Account bei einem S3-kompatiblen Anbieter: Hetzner Cloud, Wasabi, Backblaze B2 oder selbst-gehostetes MinIO
Für den Immutabilitäts-Workaround: zweiter S3-Bucket mit S3 Object Lock + Bucket Versioning aktiviert
Dediziertes Cache-Filesystem am PBS-Host: 64–128 GB SSD/NVMe unter /var/lib/pbs-s3cache/ (separates Filesystem, nicht auf gleichem Mount wie lokaler Datastore)
Zwei getrennte IAM/API-Credentials: vollständige Rechte für PBS auf dem primären Bucket, nur PutObject/GetObject/ListBucket (kein DeleteObject) für den rclone-Sync in den Immutable-Bucket
rclone (aktuelle Version von rclone.org) oder AWS CLI v2 für den Sync-Job
Netzwerkzugang des PBS-Hosts zu den S3-Endpunkten (Port 443)

Schritt 1: S3-Anbieter auswählen – Kostenvergleich 2026

Bevor du einen Bucket erstellst, lohnt ein kurzer Blick auf die tatsächlichen Kosten. Besonders die Mindestlaufzeiten können das Bild stark verzerren:

Anbieter	Speicher/TB/Monat	Egress	API-Kosten	Mindestlaufzeit	Object Lock	DSGVO
Hetzner Object Storage	5,99 EUR	kostenlos bis 1 TB, dann 1,20 USD/TB	keine	keine	nein	ja (DE)
Wasabi	6,99 USD	kostenlos (Fair-Use)	keine	90 Tage	ja	EU-Region
Backblaze B2	6,00 USD	kostenlos bis 3× Volumen/Monat, danach 0,01 USD/GB	0,004 USD/1000 PUTs	30 Tage	ja	EU-Region
AWS S3 Standard	23,00 USD	90 USD/TB	vorhanden	keine	ja	ja

Empfehlung: Für DSGVO-pflichtiges DACH-Umfeld mit kleinen bis mittleren Volumen (1–10 TB) und häufigen Prune-Zyklen ist Hetzner Object Storage die beste Wahl – keine Mindestlaufzeit, kein Egress-Schock, deutscher Standort. Wasabi ist attraktiv für große statische Archive (> 5 TB), bei denen Daten mindestens 90 Tage liegen bleiben. Backblaze B2 ist der günstigste Einstieg mit moderaten API-Kosten. AWS S3 ist für PBS-Offsite-Setups wirtschaftlich kaum sinnvoll.

Wasabi-Kostenfalle konkret: Wenn dein Prune-Job täglich läuft und --keep-daily 7 setzt, werden Snapshots nach 7 Tagen „gelöscht" – Wasabi berechnet aber noch 83 weitere Tage. Bei 500 GB täglichem Backup-Wachstum können so schnell das 3–4-fache der erwarteten Kosten entstehen. Mehr zur richtigen Prune-Konfiguration für Wasabi in Schritt 4.

Schritt 2: S3-Datastore in PBS 4.2 einrichten

Erstelle zunächst den Cache-Mount-Point auf einem dedizierten Filesystem (mindestens 64 GB empfohlen):

mkdir -p /var/lib/pbs-s3cache/offsite

Dann den Datastore anlegen – hier am Beispiel Hetzner Object Storage (Nürnberg):

proxmox-backup-manager datastore create offsite-s3 \
  --path /var/lib/pbs-s3cache/offsite \
  --s3-bucket mein-pbs-backup-bucket \
  --s3-region eu-central-1 \
  --s3-endpoint s3.nbg1.your-objectstorage.com \
  --s3-access-key ACCESS_KEY_ID \
  --s3-secret-key SECRET_ACCESS_KEY

Alternativ direkt in /etc/proxmox-backup/datastore.cfg:

datastore: offsite-s3
  path /var/lib/pbs-s3cache/offsite
  s3-bucket mein-pbs-backup-bucket
  s3-region eu-central-1
  s3-endpoint s3.nbg1.your-objectstorage.com
  s3-access-key ACCESS_KEY_ID
  s3-secret-key SECRET_ACCESS_KEY
  # Cache-Größe auf 100 GB begrenzen (Bytes)
  chunk-cache-size 107374182400

Wichtig beim Endpunkt: PBS 4.2 erwartet den Hostnamen ohne https://-Präfix und ohne abschließenden Slash. s3.nbg1.your-objectstorage.com ist korrekt – https://s3.nbg1.your-objectstorage.com/ führt zu „SSL handshake error" oder „connection refused" ohne klare Fehlermeldung. Für Falkenstein alternativ: s3.fsn1.your-objectstorage.com.

PBS 4.2 speichert Chunks im S3-Bucket und hält Metadaten (Indexdateien, Manifeste) lokal im Cache vor. Bei zu kleinem Cache wird LRU-Eviction aggressiv und verlängert GC-Läufe erheblich. Das Cache-Verzeichnis muss auf einem separaten Filesystem liegen – nie auf demselben Mount wie ein lokaler Datastore.

Schritt 3: Warum Object Lock den Datastore zerstört – und was stattdessen funktioniert

Das ist der kritischste Teil dieser Anleitung. PBS nutzt Chunk-basierte Deduplizierung: Gleiche Datenblöcke werden nur einmal gespeichert und von mehreren Backups referenziert. S3 Object Lock sperrt einzelne Objekte (= Chunks) ab dem Upload-Zeitpunkt für eine definierte Dauer.

Das Problem: Die PBS Garbage Collection läuft in drei Phasen. Phase 1 markiert referenzierte Chunks lokal unter .chunks/[hexprefix]/[digest]. Phase 2 listet alle S3-Objekte via ListObjectsV2 (Batches à 1000) und löscht unreferenzierte Chunks. Phase 3 bereinigt lokale Marker.

Wenn Object Lock auf dem Bucket aktiv ist, passiert in Phase 2 das Folgende: Die S3-API antwortet auf DeleteObject-Anfragen für gesperrte Chunks mit „delete success" – aber das Objekt bleibt gesperrt erhalten. PBS glaubt, der Chunk sei gelöscht. Beim nächsten GC-Lauf findet PBS den Chunk wieder vor und meldet:

No such file or directory (os error 2)

Oder in Phase 3, wenn ein Chunk in einer Indexdatei referenziert ist, aber nicht im S3-Bucket gefunden wird:

Invalid string length

Der Datastore ist dann inkonsistent. Bugzilla-Issue #6780 ist seit PBS 4.0 offen; PBS-Entwickler Chris Ebner hat das Problem als „schwierig wegen Dedup-Architektur" eingestuft – eine native Object-Lock-Unterstützung ist auf absehbare Zeit nicht geplant.

Ein weiteres Problem: Alte Chunks haben einen früheren Upload-Zeitpunkt und damit eine frühere Lock-Ablaufzeit. Ein Chunk aus Backup A (30 Tage alt) kann seinen Lock verlieren, obwohl er noch von Backup B (5 Tage alt) referenziert wird – die Unveränderlichkeitsgarantie ist dann für diesen Chunk weg.

Die funktionierende Lösung: Zwei-Bucket-Ansatz

Bucket A (primär, ohne Object Lock): PBS schreibt hier. Dedup, GC, Prune laufen normal.
Bucket B (Immutable-Kopien, mit Object Lock + Versioning): rclone oder AWS CLI synchronisiert täglich von A nach B. Separate Credentials ohne s3:DeleteObject-Recht. PBS (und damit ein potenzieller Angreifer mit PBS-Zugang) kann hier nichts löschen.

Dieser Ansatz passt ideal zur 3-2-1-Backup-Strategie: lokaler PBS-Datastore (Kopie 1), primärer S3-Bucket (Kopie 2), Immutable-Bucket (Kopie 3, unveränderlich).

Schritt 4: IAM-Credentials und Bucket-Konfiguration

Erstelle zwei getrennte Zugriffsschlüssel mit Minimal-Rechten. Für AWS/Wasabi/Backblaze über die IAM-Konsole oder API:

IAM Policy – primärer PBS-Bucket (vollständige Rechte für GC):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject", "s3:PutObject", "s3:DeleteObject",
      "s3:ListBucket", "s3:GetBucketLocation"
    ],
    "Resource": [
      "arn:aws:s3:::pbs-primary-bucket",
      "arn:aws:s3:::pbs-primary-bucket/*"
    ]
  }]
}

IAM Policy – Immutable-Bucket (kein DeleteObject!):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject", "s3:PutObject",
      "s3:ListBucket", "s3:GetBucketLocation"
    ],
    "Resource": [
      "arn:aws:s3:::pbs-immutable-copies",
      "arn:aws:s3:::pbs-immutable-copies/*"
    ]
  }]
}

Object Lock kann nur bei der Bucket-Erstellung aktiviert werden (nachträglich nicht möglich). Mit AWS CLI:

# Bucket mit Object Lock erstellen (nur bei Erstellung möglich!)
aws s3api create-bucket \
  --bucket pbs-immutable-copies \
  --region eu-central-1 \
  --object-lock-enabled-for-bucket

# Default Retention: Compliance-Mode, 30 Tage
aws s3api put-object-lock-configuration \
  --bucket pbs-immutable-copies \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

Wichtig: Bucket Versioning muss zusätzlich zu Object Lock aktiviert sein. Ohne Versioning können Delete Markers gesetzt werden, die Objekte „unsichtbar" machen, auch wenn Object Lock aktiv ist.

Schritt 5: Sync-Job und rclone für Immutable-Kopien einrichten

PBS 4.2 bietet parallele Sync-Jobs (neues worker-threads-Property). Für Replikation zwischen PBS-Instanzen zunächst den Sync-Job anlegen:

proxmox-backup-manager sync-job create push-to-s3 \
  --remote hetzner-s3-remote \
  --remote-store remote-datastore \
  --store local-backups \
  --schedule '0 2 * * *' \
  --remove-vanished true \
  --worker-threads 4

Für den Sync von primärem Bucket in den Immutable-Bucket mit rclone (als Cron-Job auf dem PBS-Host):

rclone sync s3:pbs-primary-bucket s3:pbs-immutable-bucket \
  --s3-provider Wasabi \
  --s3-endpoint s3.eu-central-1.wasabisys.com \
  --s3-access-key-id WRITE_ONLY_KEY \
  --s3-secret-access-key WRITE_ONLY_SECRET \
  --transfers 8 \
  --checkers 16

Für Uplinks unter 100 Mbit/s empfehlen sich maximal 2–4 parallele Transfers. Wie du den Sync-Aufruf als Cron-Job automatisierst, erklärt die Anleitung Cron und Crontab auf Linux.

Schritt 6: Prune, Verify und Garbage Collection in der richtigen Reihenfolge

Die Reihenfolge ist bei S3-Datastores zwingend – Abweichungen führen zu Inkonsistenzen:

# 1. Prune: Alte Snapshots markieren
proxmox-backup-manager prune-job run s3-prune

# 2. Verify: IMMER vor GC – Integrität prüfen
proxmox-backup-manager verify-job run --store offsite-s3

# 3. Erst dann Garbage Collection
proxmox-backup-manager garbage-collection run offsite-s3

Verify-Job dauerhaft einrichten (wöchentlich, nur unverified und ältere Chunks):

proxmox-backup-manager verify-job create s3-verify \
  --store offsite-s3 \
  --schedule '0 6 * * 0' \
  --ignore-verified true \
  --outdated-after 30

Prune-Job für Wasabi (90-Tage-Minimum beachten – kein Snapshot darf vor Ablauf von 90 Tagen gelöscht werden):

proxmox-backup-manager prune-job create s3-prune \
  --store offsite-s3 \
  --schedule '0 3 * * *' \
  --keep-last 3 \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3

Achtung Wasabi: Mit --keep-daily 7 werden Snapshots nach 7 Tagen gelöscht – aber Wasabi berechnet noch 83 weitere Tage. Sicherer: --keep-daily 30 --keep-weekly 12. Alternativ Backblaze B2 mit nur 30 Tagen Mindestlaufzeit wählen.

Einzelne Snapshots vor Prune schützen (Protection-Flag):

proxmox-backup-client protect vm/100/2026-05-01T00:00:00Z \
  --repository backup-user@pbs:offsite-s3 \
  --protection true

Prune-Jobs überspringen geschützte Snapshots mit dem Logeintrag protected backup snapshot, skipping prune.

Für Monitoring und Alerting bei GC-Fehlern bietet sich die PBS Web-GUI unter https://[pbs-host]:8007 an – PBS 4.2 zeigt dort erstmals Request-Counter, Traffic-Statistiken und S3-Traffic-Metriken im Datastore-Summary. Tiefergehendes Monitoring lässt sich mit Grafana-Dashboards aufbauen.

Troubleshooting / Typische Fehler

„No such file or directory (os error 2)" in GC Phase 2: Lokale Cache-Marker fehlen, Chunks im S3-Bucket aber vorhanden – typisch nach Cache-Rebuild oder abgebrochenem Backup-Job. Seit PBS 4.0.22-1 behoben. Workaround auf älteren Versionen: touch /var/lib/pbs-s3cache/offsite/.chunks/000a/[chunk-hash], danach GC erneut starten. Chunk-Hash aus dem GC-Log lesen; mit strace identifizierbar.
„Invalid string length" in GC Phase 3: Chunk in Indexdatei referenziert, aber nicht im S3-Bucket vorhanden. Erzwingt vollständigen verify-job. Nach Verify GC erneut ausführen.
GC läuft durch, Datastore wird inkonsistent (Object Lock aktiviert): S3-API gibt für gesperrte Chunks „delete success" zurück – PBS denkt Chunk ist weg, er ist aber noch vorhanden. Object Lock direkt auf PBS-Bucket deaktivieren ist nicht möglich (nur bei Erstellung). Neuen Bucket ohne Object Lock erstellen, Daten migrieren, dann Zwei-Bucket-Ansatz umsetzen.
„SSL handshake error" oder „connection refused" beim Endpunkt: Endpunkt-URL mit https://-Präfix oder abschließendem Slash konfiguriert. Nur Hostname verwenden: s3.nbg1.your-objectstorage.com.
Wasabi-Kosten explodieren: Prune löscht Snapshots, die jünger als 90 Tage sind. Prune-Policy anpassen (mind. --keep-daily 30) oder zu Backblaze B2 (30 Tage Mindestlaufzeit) wechseln.
Cache-Filesystem voll: S3-Cache liegt auf demselben Mount wie lokaler Datastore. Cache auf separates Filesystem verschieben (eigene Partition oder LV).
Sync-Job zu langsam / Verbindungsabbrüche: worker-threads auf schmalbandigen WAN-Links reduzieren (2–4 Threads für < 100 Mbit/s).

Häufige Fragen

Kann ich Object Lock direkt auf meinem PBS-S3-Bucket aktivieren?

Nein. PBS unterstützt S3 Object Lock nicht (Stand PBS 4.2, Bugzilla #6780 offen). Wenn Object Lock auf dem Haupt-PBS-Bucket aktiv ist, schlägt die Garbage Collection still fehl: Die S3-API gibt keinen Fehler zurück, PBS glaubt Chunks gelöscht zu haben, sie sind aber noch gesperrt vorhanden. Der Datastore wird über Zeit inkonsistent und letztlich unbrauchbar.

Wie erreiche ich trotzdem unveränderliche Offsite-Backups mit PBS?

Zwei-Bucket-Ansatz: PBS schreibt in Bucket A ohne Object Lock (Dedup und GC funktionieren). Ein separater Sync-Job via rclone oder aws s3 sync kopiert täglich in Bucket B mit Object Lock + Versioning. Bucket B hat separate IAM-Credentials ohne s3:DeleteObject – so kann weder PBS noch ein Angreifer mit PBS-Zugang die Kopien löschen.

Welcher S3-Anbieter ist für PBS in Deutschland am sinnvollsten?

Für DSGVO-Anforderungen und kleine bis mittlere Volumen (1–10 TB): Hetzner Object Storage (5,99 EUR/TB/Monat, keine Mindestlaufzeit, kein Egress nach 1 TB inkl., deutscher Standort). Für große statische Archive (> 5 TB) mit seltenen Restores: Wasabi (6,99 USD/TB, aber 90 Tage Mindestlaufzeit beachten). Für den günstigsten Einstieg: Backblaze B2 (6 USD/TB, 30 Tage Mindestlaufzeit, geringe API-Kosten).

Was bedeutet der GC-Fehler „os error 2"?

Lokale Cache-Marker-Dateien fehlen, aber die Chunks im S3-Bucket sind vorhanden – typisch nach einem Cache-Rebuild oder abgebrochenem Job. Seit PBS 4.0.22-1 behoben. Auf älteren Versionen: fehlende Marker-Datei per touch-Befehl im Cache-Pfad anlegen, danach GC erneut ausführen.

Ist Hetzner Object Storage vollständig S3-kompatibel für PBS?

Ja, mit bekannten Einschränkungen: Hetzner unterstützt kein S3 Object Lock und kein MFA Delete. Die für PBS relevanten APIs (ListObjectsV2, PutObject, DeleteObject, DeleteObjects-Batch) werden vollständig unterstützt. Endpunkte: s3.nbg1.your-objectstorage.com (Nürnberg) und s3.fsn1.your-objectstorage.com (Falkenstein).

Wie stelle ich die Pruning-Policy ein, damit Wasabi-Kosten nicht explodieren?

Stelle sicher, dass kein Snapshot vor Ablauf von 90 Tagen gelöscht wird. Konservative Empfehlung: --keep-daily 30 --keep-weekly 12 --keep-monthly 6. Das nächstgelegene Löschdatum liegt dann bei 30 Tagen – immer noch unter 90, aber die Kostenfalle ist deutlich kleiner als bei --keep-daily 7. Alternativ: Backblaze B2 mit nur 30-Tage-Minimum wählen.

Fazit

PBS 4.2 macht S3-Datastores produktionsreif – aber „Object Lock einfach aktivieren" ist eine Falle, die deinen Datastore still und leise zerstört. Der Zwei-Bucket-Ansatz mit rclone-Sync ist kein schmutziger Workaround, sondern die derzeit einzig funktionierende Architektur für echte Unveränderlichkeit mit PBS. Für DSGVO-konforme DACH-Setups ist Hetzner Object Storage preislich und rechtlich die erste Wahl; Wasabi nur dann, wenn die 90-Tage-Mindestlaufzeit zur Backup-Strategie passt. Die Reihenfolge Prune → Verify → GC und ein ausreichend dimensionierter, separater Cache sind keine Optionen, sondern Pflicht für einen stabilen Betrieb.

Für den Schutz vor Ransomware empfiehlt sich ergänzend ein Ransomware-Notfallplan. Zur Absicherung des PBS-Hosts selbst hilft die Anleitung Linux-Server absichern mit UFW und Fail2ban.

Weiterführende Anleitungen und Quellen

Quellen: Proxmox Backup Server 4.2 Press Release (proxmox.com, April 2026) · PBS Forum: Immutable backups on S3 object storage (Thread 169404) · PBS Forum: S3 Datastore GC Phase 2 Fehler os error 2 (Thread 176567) · PBS Forum: Deduplication and Immutability (Thread 182803) · PBS S3 GC Implementation Patch (pbs-devel, C. Ebner, Juli 2025) · S3 Storage Pricing Comparison 2026 (s3compare.io) · Wasabi Pricing Pitfalls 2026 (LeanOps)