Backups
Veeam S3-compatible repository: setup and compatibility checklist
Current Veeam Backup & Replication 13.1 documentation lists S3-compatible object storage as a repository type, but that does not make every S3 endpoint compatible with every Veeam feature. Veeam requires compatible AWS S3 operations and Signature Version 4 for S3-compatible repositories, while immutability adds Object Lock and versioning requirements. Validate the exact backend and workflow before calling the combination supported.
Start with the exact Veeam product and build
Record whether the workload uses Veeam Backup & Replication, an agent, a service-provider workflow or another product, plus the exact build. Repository and immutability requirements can differ by product, version and architecture.
For Veeam Backup & Replication, the current repository documentation explicitly includes S3-compatible object storage. Recheck the vendor documentation after upgrades because supported operations and limitations can change.
Check the S3 protocol requirements before the wizard
Veeam’s current S3-compatible limitations require an endpoint compatible with the AWS S3 operations Veeam uses and AWS Signature Version 4. Veeam also documents SHA-256 request signatures as the normal behavior for S3-compatible storage.
The repository wizard asks for the service endpoint, port, region and access credentials. A generic S3 client connecting successfully is useful evidence, but it is not a substitute for exercising the actual Veeam repository workflow.
Veeam: S3-compatible considerations and limitations | Veeam: S3-compatible account settings
Give Veeam an isolated bucket and scoped credential
Veeam’s current limitations state that data in an object-storage bucket used by the repository must be managed solely by Veeam Backup & Replication. Do not share that bucket with another application or manually reorganize its objects.
Scope the service credential to the repository’s assigned storage boundary and document its rotation process. The backup server should not need provider project-creation credentials or access to unrelated customer data.
Treat immutability as a separate compatibility test
For S3-compatible immutability, Veeam documents S3 Object Lock and Versioning as bucket prerequisites and says default Object Lock retention should be disabled. Its current setup guidance starts with a new bucket because many vendors only allow Object Lock to be enabled when the bucket is created.
Basic read, write and delete tests do not prove an immutable workflow. Confirm the exact provider supports the required Object Lock behavior, then test Veeam’s immutability path and a restore before depending on it for ransomware protection.
Size the repository for retention, not source size alone
Repository use depends on source data, change rate, retention, compression, backup-chain design and the Veeam feature using object storage. A one-terabyte source does not imply a one-terabyte repository.
Monitor the storage provider’s authoritative used bytes and leave operational headroom below the service quota. Capacity planning should include the retention behavior you will actually run, not only the first full backup.
Prove backup and restore before calling the backend compatible
Create a controlled backup through the intended Veeam repository, restore representative data and record the Veeam build, endpoint, repository type, settings and result. Include negative tests for any security feature you intend to rely on, such as immutability.
That evidence belongs in the compatibility matrix. Until it exists for the exact backend, describe the integration as pending validation until a real backup and restore has passed.