Immutable Proxmox Backups Using Wasabi and S3 Object Lock with Zmanda Pro

Modern ransomware families specifically target backup infrastructure, identifying and deleting or encrypting backup repositories before triggering the production payload. If your Proxmox backup is live in a local PBS datastore accessible by the same credentials as your production environment, they’re not protected from a credential compromise. An attacker with admin access can delete them. An attacker who encrypts your network storage can reach them. Immutability is the countermeasure: backup objects that cannot be deleted, modified, or encrypted by anyone, including your own admin account, for a defined retention window.

S3 Object Lock in Compliance mode is the strongest available implementation of this principle. Combined with client-side deduplication that reduces storage consumption by up to 90%, Proxmox Backup Server Wasabi integration via Zmanda Pro’s native Object Lock support, and zero-egress pricing, you can configure genuinely ransomware-proof offsite copies of your Proxmox backups in under an hour. This post shows you exactly how.

This post covers: how S3 Object Lock works and why Compliance mode matters, step-by-step Wasabi bucket configuration for immutable Proxmox backups, Zmanda Pro configuration to target an Object Lock-enabled bucket, retention policy design for Proxmox environments, and the complete 3-2-1-1-0 architecture this enables.

Start Your Free Trial

S3 Object Lock: Governance Mode vs Compliance Mode

Object Lock is an S3-compatible feature that prevents stored objects from being deleted or overwritten for a defined retention period. Understanding the distinction between its two modes is critical before configuring it. Choosing the wrong mode either leaves your backups vulnerable to admin override (Governance) or permanently locks your bucket configuration in ways that are difficult to reverse (Compliance).

Governance Mode: Objects are protected from deletion by standard users. However, users with the s3:BypassGovernanceRetention IAM permission can override the lock and delete objects. This mode is appropriate for protecting against accidental deletion and most ransomware scenarios where the attacker doesn’t have the specific bypass permission. It can be unlocked if you need to delete objects before the retention window expires.

Compliance Mode: Objects cannot be deleted or modified by anyone, including the root account, until the retention period expires. There is no override mechanism. No IAM permission, no account privilege, no support ticket to the cloud provider unlocks Compliance mode before expiry. Even if an attacker compromises your AWS or Wasabi root account credentials, they cannot delete objects under Compliance mode retention. This is the mode that provides genuine ransomware protection.

Want to compare Wasabi, AWS S3, and Backblaze B2 as Proxmox backup destinations?
See the cloud backup for Proxmox guide.

Configuring a Wasabi Bucket for Object Lock

Before configuring Proxmox Backup Server Wasabi Object Lock, note that it must be enabled at bucket creation; it cannot be added to an existing bucket. This is a permanent bucket-level setting. Plan your bucket structure before creating it, because reversing Object Lock requires creating a new bucket and migrating data.

Step 1: Create the bucket with Object Lock enabled

In the Wasabi console, navigate to Buckets → Create Bucket. Under “Versioning and Object Lock,” enable both Bucket Versioning and Object Lock. Object Lock requires versioning; the two settings must be enabled together. Name the bucket according to your retention policy (e.g., proxmox-backup-immutable-90d). The name should make the retention intent clear for future admins.

Step 2: Set the default retention policy

After creating the bucket, navigate to bucket properties and configure the Default Retention Policy. Set the mode to COMPLIANCE and the retention period to match your policy requirement. Common retention windows for Proxmox backups:

• 30 days: Minimum retention that satisfies most operational recovery requirements. Covers most ransomware incubation periods where an infection exists undetected before triggering.
• 90 days: Appropriate for environments with compliance requirements or where post-incident forensics may require historical data access.
• 1 year: Common for regulated industries (healthcare, finance) where retention policies mandate long-term backup availability.

The default retention policy applies to all new objects written to the bucket. Individual objects can have longer retention periods set at write time. Still, the default covers the standard case: backup objects written by Zmanda Pro automatically inherit the bucket-level Compliance mode retention.

Step 3: Configure IAM credentials for write-only access

For maximum security, create a dedicated Wasabi IAM user for Zmanda Pro with write-only permissions to the immutable bucket. This user can create objects but cannot delete or modify them (Object Lock protects existing objects regardless of IAM permissions). Even if these credentials are compromised, the attacker cannot delete existing backup objects; they can only write new data.

Recommended IAM policy for the Zmanda Pro service account:

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

Notably absent: s3:DeleteObject, s3:DeleteBucket, and s3:BypassGovernanceRetention. These permissions are intentionally excluded; the service account used for backup writes has no deletion capability at all.

Need help configuring immutable backup architecture for your Proxmox environment? Book a free 30-minute consultation with a backup specialist.

Configuring Zmanda Pro to Target the Object Lock Bucket

Zmanda Pro has native support for S3 Object Lock on Wasabi and AWS S3, covering both Governance and Compliance modes. Configuration is straightforward from the Zmanda Pro console.

Step 1: Add the Wasabi storage destination

Setting up Proxmox Backup Server Wasabi as a storage destination starts in the Zmanda Pro console under Storage → Add Storage Destination. Select “S3-Compatible Storage” and enter the Wasabi endpoint details:

• Endpoint: s3.wasabisys.com (or region-specific endpoint, e.g., s3.us-east-2.wasabisys.com)
• Region: match your bucket’s region
• Access Key ID and Secret Access Key: the IAM credentials from the write-only service account created above
• Bucket: proxmox-backup-immutable-90d

Step 2: Enable Object Lock in the storage destination settings

In the storage destination configuration, enable “Object Lock” and set the retention mode to Compliance. The retention period configured here should match or be shorter than the bucket-level default retention. Zmanda Pro will set object-level retention metadata on each backup object written to the bucket.

Step 3: Configure a backup policy targeting this destination

Create or update a backup policy for your Proxmox VMs and LXC containers to target the Object Lock-enabled Wasabi destination. You can configure a tiered policy where the primary backup destination is local storage (for fast local recovery) and the Object Lock bucket is a secondary destination for the immutable offsite copy. This is the architecture that satisfies the “1” in the 3-2-1-1-0 rule, one immutable copy stored separately from your primary backup infrastructure.

The 3-2-1-1-0 Architecture for Proxmox Environments

The 3-2-1-1-0 backup rule is the current gold standard for enterprise data protection:

• 3 copies of data total
• 2 different storage media types
• 1 offsite copy
• 1 immutable (air-gapped or Object Lock) copy
• 0 errors verified at last restore test

For a Proxmox environment using Zmanda Pro, this architecture maps cleanly:

• Copy 1: Local Zmanda Pro backup to NAS (fast local recovery, primary storage)
• Copy 2: Zmanda Pro backup to a standard Wasabi bucket (offsite, mutable, lower retention cost)
• Copy 3 (immutable): Zmanda Pro backup to the Object Lock Compliance mode bucket (offsite, immutable, cannot be deleted by anyone)
• Media types: local NAS (disk) + cloud object storage = 2 media types
• 0 errors: Zmanda Pro verifies chunk integrity at write time; restore validation confirms the backup chain is recoverable

Achieving this architecture natively without Zmanda Pro requires: Proxmox Backup Server Wasabi sync via rclone, a second rclone job for the Object Lock bucket, and independent monitoring of all three paths. None of the three PBS-sourced copies has write-time integrity verification; rclone confirms file transfer, but doesn’t verify PBS chunk integrity at the destination. With Zmanda Pro, the same three-copy architecture is managed from a single console, with verified writes at each destination and a single monitoring surface for all three paths.

Zmanda Cloud Storage achieves the full 3-2-1-1-0 posture in two configuration steps with built-in immutability support. For teams that prefer using Wasabi or AWS S3 directly, the Object Lock configuration above achieves the same compliance posture with your chosen provider. See full details on Zmanda Pro’s immutable backup architecture and the ransomware protection capabilities that Object Lock enables.

Want the full framework for Proxmox backup retention, scheduling, and verification?
Read Proxmox backup and restore best practices.

Storage Cost Impact: Deduplication + Object Lock

One concern with Object Lock is the storage cost implications of retention. Objects under Object Lock cannot be deleted before the retention window expires, including objects that represent backup versions you’d normally prune. A 90-day Compliance mode retention on a 50-VM environment with daily backups accumulates 90 × daily incremental backup sets in the immutable bucket, each protected until its individual retention period expires.

Zmanda Pro’s client-side deduplication fundamentally changes this cost calculation. Because deduplication happens before transmission, only unique data chunks are written to the Object Lock bucket. Two VMs sharing a common OS image contribute only one copy of the shared chunks to the bucket, not two. Daily incremental backups for a VM with a 5% daily change rate transmit approximately 5% of the VM’s total data per day, not a full new copy. In validated production deployments, Zmanda Pro achieves a 10:1 storage reduction ratio (89% savings), meaning a 10TB Proxmox environment’s Object Lock bucket grows at approximately 1TB of unique data over time, not 10TB.

At Wasabi’s $6.99/TB/month with no egress fees, Proxmox Backup Server Wasabi storage costs are materially more manageable with client-side deduplication than without it. The storage optimization via deduplication that Zmanda Pro applies is what makes long-retention Object Lock policies financially viable for SMB and mid-market environments that can’t absorb per-GB storage costs at scale. For a full breakdown of cloud storage cost comparisons, see the Zmanda Cloud Storage page.

Enterprise backup at $5.99/workload/month. No per-GB surprises.

Start Free Trial

Operationalizing Immutable Backup: Restore Testing and Monitoring

Immutable backups that have never been verified in a restore test satisfy the “0 errors verified” requirement in name only. The “0” in 3-2-1-1-0 is earned through actual restore testing, not assumed from backup job success logs.

For Proxmox environments, restore testing from an Object Lock-protected Wasabi bucket via Zmanda Pro involves the same restore workflow as any other destination: select the point-in-time restore point, choose the target (original Proxmox host, alternate host, or cross-platform), and execute. Zmanda Pro’s chunk-level indexing means restore speed is consistent regardless of how old the recovery point is oldest and newest backups restore at identical speeds because the system assembles only the required chunks rather than replaying a backup chain.

Monitoring for the immutable copy should verify three things: that backup jobs to the Object Lock destination are completing successfully (not just that the Object Lock bucket exists), that the retention metadata on written objects matches the configured policy, and that a sample restore from the immutable copy completes successfully on a scheduled cadence. Many teams test local restores regularly but skip testing the cloud copy, which is precisely the copy you’ll need if local infrastructure is compromised. Schedule restore tests from the Object Lock destination at least quarterly and document the results for compliance evidence if your regulatory framework requires proof of backup recoverability.