S3-Compatible Storage for Veeam Immutability: Provider Matrix

Can any S3-compatible provider protect Veeam backups?

S3 compatibility alone does not establish Veeam immutability support. Check the required API operations, consistency model, bucket setup and the tested product/build combination. Amazon S3, Backblaze B2, Wasabi and MinIO document Object Lock; Cloudflare R2's bucket locks use a different interface. A passing API check still does not prove a complete backup and restore workflow.

What Veeam actually requires from an "S3-compatible" endpoint

The Veeam behavior below is pinned to Veeam Backup & Replication 13 build 13.1.1.18. Provider qualifications have their own tested builds, listed separately in the matrix; a v13 badge is not evidence that this exact build was tested.

The baseline contract. Veeam requires compatible AWS S3 operations and Signature Version 4, and does not support eventual-consistency storage. The Veeam page also describes S3UseMd5ContentHash as an MD5 compatibility setting for endpoints that cannot handle its SHA-256 requirement. On Linux the setting lives in /etc/VeeamAgentConfig; on Windows it is a registry value, and it affects all S3-compatible targets on that backup server. Signature Version 4 still uses HMAC-SHA256; do not describe this setting as switching the authentication algorithm to MD5. Review the server-wide impact before changing it.

The immutability contract. Veeam's Enabling Immutability page gives four requirements for an S3 bucket, and all four have to be true at once:

1. Object Lock enabled on the bucket. Veeam adds the warning that matters: "most vendors allow enabling Object Lock only at the moment of creating the bucket."
2. Default retention disabled. This is a requirement, not a nice-to-have. The failure modes below show why.
3. Versioning enabled on the bucket.
4. The immutability option ticked at the Bucket step of the New Object Storage Repository wizard.

For Amazon S3, Veeam explicitly documents Compliance mode. Do not universalize that statement to every S3-compatible integration: the qualification pages can distinguish Governance support, and effective behavior must be checked for the provider and build. AWS Governance protects against ordinary identities but permits authorized bypass with the required permission and header; Compliance removes that bypass for a protected version.

The Veeam permissions page lists the required IAM actions, not a one-to-one inventory of S3 API operation names. For the single-bucket, immutable S3-compatible case it includes object reads/writes/deletes, version listing and reads, retention and legal-hold reads/writes, and version deletion. Use the current policy for the exact scenario; S3-compatible multiple-bucket mode additionally requires bucket creation and deletion permissions.

Veeam needs s3:DeleteObjectVersion for supported cleanup; denying all deletion is not a substitute for Object Lock. s3:GetBucketObjectLockConfiguration appears even in the non-immutable policy. A missing permission can prevent discovery, but its precise error is not guaranteed to match an unimplemented provider API. Scope permissions to approved resources using the provider's guidance; do not paste a wildcard policy into production merely to see whether an error disappears. Backblaze maps S3 operations to application-key capabilities, including separate retention read/write capabilities and bypassGovernance. Check those capabilities when using a bucket-restricted B2 key; an AWS IAM action list is not a B2 key configuration.

Budget for Block Generation and the selected retention mode. Defaults are 10 days for most types and 30 for Amazon S3, IBM Cloud, Google Cloud and 11:11. A 30-day minimum plus a 10-day generation explains a 40-day generation-start lock in Veeam's example; it is not a universal 40-day billing window for every object.

Provider matrix, checked 24 September 2026

The table covers six selected options. Provider documentation describes the Object Lock behavior; Veeam Ready records show which build, region and configuration Veeam tested. Check both before treating a row as applicable to your deployment.

A cloud provider can change its API without changing a Veeam Ready entry. For software you run yourself, compare the installed release and hardware with the listed test, alongside the Veeam build.

Read the qualification by topology. The Capacity Target category describes a secondary object-storage target. VBR 13 also supports object repositories as direct job targets and performance-tier extents. A Capacity Target entry does not by itself document a test of your direct-to-object or performance-tier path. Validate the topology you will deploy.

Wasabi uses Compliance in two ways. Wasabi's bucket-level Compliance feature and S3 Object Lock are mutually exclusive. Compliance mode within Object Lock is a different setting. For Veeam's Object Lock integration, create an Object Lock bucket and leave default bucket retention off, as Veeam requires.

Absence of v13 in an opened entry means that entry does not substantiate v13 qualification. It is not proof that the vendor has no other listing. Keep qualification category, attributes, tested build, region and hardware together when documenting a selection.

Cloudflare R2: bucket locks are not S3 Object Lock

R2 has an S3-compatible endpoint, so it often appears in storage comparisons. Veeam immutability also needs versioning and retention on individual object versions; ordinary object reads and writes do not cover those operations.

Cloudflare's S3 compatibility table marks the relevant versioning and Object Lock APIs unsupported. Its bucket locks are retention rules managed through Cloudflare's own control plane. They are not Veeam-managed per-version S3 Object Lock. That mismatch is enough to reject R2 for the immutable Veeam target discussed here; it does not establish support for every non-immutable workflow.

Applying an external retention rule underneath a backup application can also prevent that application's cleanup. Veeam requires repository data to be managed by Veeam itself. Treat cloud-native lock rules as a separate integration question rather than as a workaround for a missing Object Lock API.

Inspect the endpoint before a controlled acceptance test

Start with read-only inspection using Bash and AWS CLI v2. Configure an inspection profile and the exact region, HTTPS endpoint, bucket and known Veeam data prefix. These commands do not create a bucket, alter retention or delete data. They sample existing versions; they do not certify the provider.

# Bash + AWS CLI v2. Set these to the approved read-only target first.
(
  set -eu
  : "${S3_PROFILE:?Set the inspection profile}"
  : "${S3_REGION:?Set the provider region}"
  : "${S3_ENDPOINT:?Set the HTTPS S3 endpoint}"
  : "${S3_BUCKET:?Set the bucket}"
  : "${S3_PREFIX:?Set a known Veeam data prefix}"
  case "$S3_ENDPOINT" in https://*) ;; *) exit 1 ;; esac
  aws --profile "$S3_PROFILE" --region "$S3_REGION" \
    --endpoint-url "$S3_ENDPOINT" s3api get-bucket-versioning --bucket "$S3_BUCKET"
  aws --profile "$S3_PROFILE" --region "$S3_REGION" \
    --endpoint-url "$S3_ENDPOINT" s3api get-object-lock-configuration --bucket "$S3_BUCKET"
  aws --profile "$S3_PROFILE" --region "$S3_REGION" \
    --endpoint-url "$S3_ENDPOINT" s3api list-object-versions \
    --bucket "$S3_BUCKET" --prefix "$S3_PREFIX" --max-items 20 --page-size 20
)

Check Status: Enabled, ObjectLockEnabled: Enabled and the absence of Rule.DefaultRetention. The version list is a limited sample, not a latest-object selection: use a known backup data object under Versions, not a DeleteMarkers entry or mutable metadata. If there is no matching data version, stop and resolve the prefix and backup state; do not infer that immutability is broken.

# Select Key and VersionId from the same Versions entry, not DeleteMarkers.
(
  set -u
  : "${S3_PROFILE:?}" "${S3_REGION:?}" "${S3_ENDPOINT:?}" "${S3_BUCKET:?}"
  : "${S3_KEY:?Set the exact data-object key}"
  : "${S3_VERSION_ID:?Set its exact VersionId}"
  case "$S3_ENDPOINT" in https://*) ;; *) exit 1 ;; esac
  case "$S3_VERSION_ID" in None|null|NULL|\<*) exit 1 ;; esac
  # Query both independently: a missing retention answer must not skip the legal-hold check.
  for op in get-object-retention get-object-legal-hold; do
    aws --profile "$S3_PROFILE" --region "$S3_REGION" \
      --endpoint-url "$S3_ENDPOINT" s3api "$op" \
      --bucket "$S3_BUCKET" --key "$S3_KEY" --version-id "$S3_VERSION_ID" \
      || echo "$op: no answer; record it as unresolved"
  done
)

Command references: get-bucket-versioning, get-object-lock-configuration, list-object-versions, get-object-retention and get-object-legal-hold. Retention and legal hold are independent: record the mode, RetainUntilDate and hold status for the same version. A missing retention response does not rule out legal hold. Missing permission, wrong version or an unsupported API can make inspection fail; classify the result as unresolved, not as a passed lock test.

For destructive acceptance testing, commission a separate non-production bucket and dedicated credentials that cannot reach production. Test only versions created by that test, retain a target manifest, reject empty/None/null version IDs, and establish positive permission controls: the same identity must delete an unlocked version and successfully extend retention on a separate control version before a denied locked deletion or shortening is interpreted. Review explicit policies and legal holds that could also cause denial. A simple delete without a version ID adds a delete marker on AWS and does not test removal of the protected version. Compliance test objects can remain billable and undeletable until expiry; legal hold can extend that further. A denied request alone is not proof, and a failed setup alone is not proof the provider lacks support.

Finish with actual Veeam backup, retention cleanup and restore tests for the intended build and topology. API behavior alone cannot establish that the full Veeam workflow succeeds on the selected build and topology. Veeam also forbids using one object storage repository across multiple VBR servers, warning of unpredictable behavior and data loss. Assign each repository to one backup server before testing a multi-server design.

Diagnose an Object Lock support error

Separate configuration, authorization and API compatibility before replacing a provider. These are checks, not a frequency-ranked list:

1. Bucket setup: Object Lock and versioning must be prepared before adding the bucket to Veeam. AWS and Backblaze can enable Object Lock on existing buckets, but Veeam warns that enabling or disabling Object Lock or versioning on a bucket already in its infrastructure can lead to unpredictable behavior and data loss. A provider capability is not a safe retrofit procedure for a Veeam repository.
2. Default retention/lifecycle: Veeam requires default retention off and does not support S3 lifecycle rules managing its backup data.
3. Permissions: compare the exact scenario with Veeam's published permissions. Obtain request/error evidence; an access-denied response is not an unimplemented API response.
4. Endpoint/API: verify region, signature compatibility, required operations and consistency. The special instruction to enable versioning and Object Lock simultaneously for old backups is specifically about 9.5 Update 4 buckets, not a general retrofit procedure.

What this matrix does not tell you

This table was checked on 24 September 2026. Before production use, recheck the Veeam Ready entry and provider documentation for the region and release you will deploy.

Read-only retention metadata proves only what that endpoint reports for those sampled versions. A controlled API rejection tests one identity and operation. Neither proves that provider administrators cannot interfere below the API, that every backup object is protected, or that encryption keys and account access will survive. Obtain the provider's documented trust boundary and test recovery independently.

Veeam Ready is useful evidence of the listed test scope. It is not a substitute for supported configuration, current vendor support or your own restore and cleanup tests. Qualification and API acceptance answer different questions.

How BackupSec approaches this

ZeroVault is our managed S3-compatible object storage with Object Lock support for Veeam Backup & Replication. There is no Veeam Ready entry under the BackupSec name, and our word is not a substitute for one. Ask us which Object Lock mode and retention apply in your region, then run the read-only checks above against an actual object version, exactly as you would with any other provider.

ZeroMON reads the repository immutability setting from Veeam and alerts on changes. It does not query retention on each stored object. Pair those alerts with the object-level checks above.