Übersicht: Die moderne 3-2-1-1-0-Backup-Regel wird praktisch mit Proxmox Backup Server (PBS) umgesetzt: ZFS-basierter lokaler Datastore + Sync zu zweitem PBS + S3-kompatibler Object Storage (PBS 4.2+) + mindestens eine unveränderliche Kopie + wöchentliche Verify mit 0 Fehlern. Wichtige Einschränkung: S3 ist in PBS 4.2 stable, aber Object Lock wird noch NICHT nativ unterstützt — für echte Unveränderlichkeit Object Lock auf Bucket-Ebene auf externem S3-Bucket konfigurieren.

Was ist die 3-2-1-1-0-Strategie?

Ein ransomware-bewusstes Update der klassischen 3-2-1-Regel (3 Kopien, 2 verschiedene Medien, 1 offsite):

Zahl	Bedeutung	Umsetzung mit PBS
3	Gesamt-Datenkopien	1 prod + 1 lokales PBS + 1 remote PBS / S3
2	Verschiedene Medien / Speichertypen	NVMe (heiß) + HDD/ZFS (remote) + Object Storage (kalt)
1	Offsite-Kopie	PBS an anderem Standort oder S3-Bucket
+1	Unveränderliche / Air-Gapped-Kopie	S3 Object Lock oder Tape (LTO) oder manuell getrennt
0	Verifikationsfehler	Regelmäßiger verify-job validiert jeden Chunk via SHA-256

Der +1 unveränderliche Teil ist Ihre letzte Verteidigungslinie gegen Ransomware. Laut Sophos State of Ransomware 2024 Bericht zielen 94% der Angriffe auf Backups; bei kompromittierten Organisationen wurden 57% der Backups effektiv zerstört. Die unveränderliche Ebene schließt diesen Angriffsvektor vollständig.

Schritt 1 — Lokaler PBS-Datastore auf ZFS

# ZFS-Dataset erstellen
zfs create -o mountpoint=/mnt/datastore/backups rpool/backups
zfs set compression=lz4 rpool/backups
zfs set atime=off rpool/backups
zfs set xattr=sa rpool/backups

# PBS-Datastore erstellen
proxmox-backup-manager datastore create local-backups /mnt/datastore/backups

Schritt 2 — Retention und Prune Job

# Täglicher Prune (21:30)
proxmox-backup-manager prune-job create daily-prune 
  --store local-backups 
  --schedule "21:30" 
  --keep-last 3 
  --keep-daily 7 
  --keep-weekly 4 
  --keep-monthly 6 
  --keep-yearly 1

Schritt 3 — Garbage Collection

# Tägliches GC (22:00)
proxmox-backup-manager garbage-collection-job create daily-gc 
  --store local-backups 
  --schedule "22:00"

Ohne GC wird Festplattenplatz nie freigegeben, egal wie aggressiv das Pruning ist.

Schritt 4 — Backup Job auf PVE-Seite

pvesh create /cluster/backup 
  --id daily-backup 
  --schedule "0 2 * * *" 
  --storage pbs-local 
  --mailnotification always 
  --mailto [email protected] 
  --mode snapshot 
  --all 1 
  --compress zstd

Schritt 5 — Offsite-Sync zu zweitem PBS

# Remote PBS registrieren
proxmox-backup-manager remote add remote-dr 
  --host pbs-dr.tekur.net 
  --port 8007 
  --auth-id backup@pbs!sync-token 
  --password '<TOKEN_SECRET>'

# Sync Job (04:00, nach lokalem Backup)
proxmox-backup-manager sync-job create push-to-dr 
  --remote remote-dr 
  --remote-store dr-datastore 
  --store local-backups 
  --schedule "0 4 * * *" 
  --remove-vanished true

Schritt 6 — S3 Object Storage + unveränderliche Kopie (PBS 4.2+)

PBS 4.2 (April 2026) machte S3 Object Storage Backend stable. Allerdings unterstützt PBS S3 Integration Object Lock noch NICHT nativ. Für echte Unveränderlichkeit:

Ansatz A — S3 als PBS-Datastore (nicht unveränderlich)

proxmox-backup-manager datastore create cold-archive 
  --backend-type s3 
  --bucket tekur-pbs-cold 
  --endpoint https://s3.wasabisys.com 
  --access-key AKIAIOSFODNN7EXAMPLE 
  --secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY 
  --region us-east-1

Ansatz B — Externer S3-Bucket mit Object Lock (empfohlen)

# 1. Object Lock Bucket auf Wasabi/AWS S3 erstellen
aws s3api create-bucket --bucket tekur-pbs-immutable --region eu-central-1 
  --object-lock-enabled-for-bucket 
  --create-bucket-configuration LocationConstraint=eu-central-1

# 2. Default Retention (30 Tage COMPLIANCE Mode)
aws s3api put-object-lock-configuration --bucket tekur-pbs-immutable 
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

Im COMPLIANCE-Mode kann selbst root vor Ablauf der Retention nicht löschen. Für Produktion COMPLIANCE verwenden.

Schritt 7 — Verify Job (das 0 in 3-2-1-1-0)

# Wöchentlicher Verify (Sonntag 06:00)
proxmox-backup-manager verify-job create weekly-verify 
  --store local-backups 
  --schedule "0 6 * * 0" 
  --ignore-verified true 
  --outdated-after 30

Schritt 8 — Restore-Tests (Ihren RTO messen)

qmrestore pbs:backup/vm/100/2026-06-14T02:00:05Z 9100 
  --storage local-zfs 
  --unique true

Häufige Probleme

• “Platte voll trotz Prune.” GC nicht gelaufen. Mit proxmox-backup-manager garbage-collection list-jobs prüfen.
• “Sync Job ‘connection refused’.” Remote PBS Port 8007 zu oder Token abgelaufen.
• “S3 Backend langsam.” PBS-Chunks sind klein (4-16 MB); Object Storage-Latenz summiert sich. Wasabi/B2 günstiger als AWS S3 für diese Workload.
• “Encryption Key verloren, Backups unlesbar.” Keine Wiederherstellung. Keys in Tresor + 1Password + physisches Papier, an verschiedenen Orten.
• “Object Lock Bucket Retention=10 Jahre versehentlich gesetzt.” COMPLIANCE erlaubt keine Löschung vor Ablauf — Beweis dass Feature korrekt arbeitet. Mit 1 Tag Retention testen.

Präventive Empfehlungen

• Öffentlichen Internet-Zugriff zur PBS Web UI blockieren (Port 8007); nur via VPN oder Bastion
• Pro-PVE-Node API-Token; ein Token sollte nicht den ganzen Cluster autorisieren
• Jährliche Verschlüsselungsschlüssel-Rotation; Master-Key + Data-Keys-Hierarchie
• Object Lock Bucket verwaltet von separatem Cloud-Konto/IAM-Benutzer
• Restore-Tests im Kalender planen — Teams die “nächste Woche” sagen, haben es 6 Monate später nicht gemacht

Getestete Versionen: Proxmox VE 8.2.4 + PBS 3.2.7, PVE 8.3.1 + PBS 4.2.1. Konfigurations-Beispiele verifiziert auf AWS S3, Wasabi und Backblaze B2. Letzte Aktualisierung: 2026-06-15.