TL;DR: The modern 3-2-1-1-0 backup rule is practically implemented with Proxmox Backup Server (PBS): ZFS-based local datastore + sync to a second PBS + S3-compatible object storage (PBS 4.2+) + at least one immutable copy + weekly verify with 0 errors. Critical caveat: S3 is stable in PBS 4.2 but Object Lock is NOT natively supported yet — for true immutability you must configure bucket-level Object Lock on an external S3 bucket.

What is the 3-2-1-1-0 strategy?

A ransomware-aware update of the classic 3-2-1 rule (3 copies, 2 different media, 1 offsite):

Number	Meaning	How to implement with PBS
3	Total data copies	1 prod + 1 local PBS + 1 remote PBS / S3
2	Different media / storage types	NVMe (hot) + HDD/ZFS (remote) + Object Storage (cold)
1	Offsite copy	PBS in another location or S3 bucket
+1	Immutable / air-gapped copy	S3 Object Lock or tape (LTO) or manually detached
0	Verification errors	Regular verify-job validates every chunk via SHA-256

The +1 immutable part is your last line of defense against ransomware. According to the Sophos State of Ransomware 2024 report, 94% of attacks target backups; among compromised organizations, 57% had their backups effectively destroyed. The immutable layer fully closes this attack vector.

Step 1 — Local PBS datastore on ZFS

# Create ZFS dataset
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

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

Step 2 — Retention and prune job

# Daily 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

Step 3 — Garbage Collection

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

Without GC, disk space is never reclaimed, no matter how aggressive prune is.

Step 4 — PVE-side backup job

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

Step 5 — Offsite sync to second PBS

# Register remote PBS
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, after local 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

Step 6 — S3 Object Storage + Immutable Copy (PBS 4.2+)

PBS 4.2 (April 2026) made S3 object storage backend stable. However, PBS S3 integration does NOT natively support Object Lock. For true immutability:

Approach A — S3 as PBS datastore (not immutable)

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

Approach B — External S3 bucket with Object Lock (recommended)

# 1. Create Object Lock bucket on Wasabi/AWS S3
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 days COMPLIANCE mode)
aws s3api put-object-lock-configuration --bucket tekur-pbs-immutable 
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

In COMPLIANCE mode, even root cannot delete before retention expires. For production, use COMPLIANCE.

Step 7 — Verify job (the 0 in 3-2-1-1-0)

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

Step 8 — Restore testing (measure your RTO)

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

Common issues

• “Disk full, but I pruned.” GC didn’t run. Check with proxmox-backup-manager garbage-collection list-jobs.
• “Sync job ‘connection refused’.” Remote PBS port 8007 closed or token expired.
• “S3 backend is slow.” PBS chunks are small (4-16 MB); object storage latency adds up. Wasabi/B2 cheaper than AWS S3 for this workload.
• “Lost encryption key, backups unreadable.” No recovery. Store keys in vault + 1Password + physical paper, in different locations.
• “Object Lock bucket retention=10 years by mistake.” COMPLIANCE doesn’t allow deletion before expiration — proof the feature works correctly. Test with 1 day retention.

Preventive recommendations

• Block public internet to PBS web UI (port 8007); access only via VPN or bastion
• Per-PVE-node API token; one token shouldn’t authorize the whole cluster
• Annual encryption key rotation; use master-key + data-keys hierarchy
• Object Lock bucket managed by separate cloud account/IAM user
• Schedule restore tests on the calendar — teams that say “we’ll do it next week” still haven’t done it after 6 months

Tested versions: Proxmox VE 8.2.4 + PBS 3.2.7, PVE 8.3.1 + PBS 4.2.1. Configuration examples verified on AWS S3, Wasabi, and Backblaze B2. Last updated: 2026-06-15.