Veeam Backup & Replication

Exaba is Certified for Veeam Ready as an object storage repository for Veeam Backup & Replication 12 and 13. The same certification also covers Veeam Backup for Microsoft 365 v8 and the Veeam Agents for Windows, Linux, and Mac.

The same Veeam S3 plug-in that targets any S3-compatible repository targets Exaba: there is no Exaba-specific plug-in and no behavioral quirk to work around. If your Veeam team has ever configured an S3 object storage repository, they have everything they need to point it at Exaba.

Why Veeam Ready matters for ransomware posture

Veeam uses S3 Object Lock (Compliance mode) to make backups immutable while a retention period is in effect. An attacker who compromises the Veeam server cannot delete or alter locked backups during the retention window, because immutability is enforced at the storage layer, not by Veeam’s policy engine.

Exaba implements Object Lock at parity with the published S3 API. The Veeam Ready certification covers exactly this configuration: Veeam writes its backups to an Exaba bucket with Object Lock enabled, and the backups stay immutable for the configured retention regardless of what happens to the Veeam server or the network it sits on. That is what buyers mean by a ransomware-resistant backup target.

What you can do with Exaba and Veeam

Capability	Status	Notes
Direct-to-object backup	Supported	Veeam 12+ can use an Exaba bucket directly as a backup job target.
Capacity Tier	Supported	Exaba bucket targets the Capacity Tier of a Scale-Out Backup Repository.
Performance Tier	Supported	For latency-sensitive restore workloads.
Smart Object Storage API (SOSAPI)	Supported	Lets Veeam discover storage capacity and capabilities automatically.
Object Lock (Compliance mode)	Supported	Veeam’s immutability flow uses Compliance mode: strict immutability that cannot be cleared early.
Object Lock (Governance mode)	Supported	Available on Exaba, though Veeam immutability uses Compliance mode.
Versioning	Supported	Required by Veeam’s immutability flow.
Legal Hold	Supported	Independent of retention.

Prerequisites

Veeam Backup & Replication 12 or 13.
Network reach to the Exaba S3 endpoint over HTTPS (port 443). Veeam requires TLS for object storage; have the endpoint’s certificate trusted by the Veeam server.

The certification was validated against a defined reference configuration. See the Veeam Ready listing for the tested hardware and the full set of certified Veeam products.

Step 1: Create the bucket

Create a bucket dedicated to Veeam, with Object Lock enabled at creation time. Object Lock cannot be enabled on an existing bucket (a protocol-level constraint, the same as AWS S3).
Ensure versioning is enabled (Object Lock requires it).
Do not set a bucket-level default retention. Veeam applies retention per object; a bucket default can cause unpredictable behavior and data loss.

Step 2: Create an IAM user for Veeam

Create an Exaba IAM user for Veeam in the account that owns the Veeam bucket. Issue an access key and secret, and hand them to your Veeam administrator.
Give the user a user policy scoped to the Veeam bucket only. A new user has no user policies, so it cannot reach the bucket without one. Exaba uses AWS-style JSON policy documents, but each Resource is a bucket name or a bucket/key pattern, without the arn:aws:s3::: prefix. The policy below mirrors Veeam’s documented permission set for an immutable S3 object storage repository (Veeam KB3151). Replace veeam-backups with your bucket name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VeeamBucketAndObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetBucketVersioning",
        "s3:GetBucketObjectLockConfiguration",
        "s3:ListBucket",
        "s3:ListBucketVersions",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:GetObjectRetention",
        "s3:GetObjectLegalHold",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold"
      ],
      "Resource": [
        "veeam-backups",
        "veeam-backups/*"
      ]
    },
    {
      "Sid": "VeeamListBuckets",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    }
  ]
}

s3:ListAllMyBuckets is necessary only if your Veeam administrator browses for the bucket. From Veeam 11a onward, you can leave it out if you type the bucket name.

To set the policy, save it as veeam.json and run iam policy set --username <user_id> --files veeam.json. See User policies.

If the user policy or the bucket policy permits a request, the object store permits it. If either one has a Deny that matches, the object store refuses it. Roles have no effect on S3 requests, so a bucket policy with the same Allow scope adds no protection. The account owner always has the root user policy, so the owner can also reach the Veeam bucket. So can every other user whose user policy permits it. For defense in depth, keep the Veeam bucket in an account of its own. See the IAM Walkthrough.

Step 3: Add the repository in Veeam

In Veeam, go to Backup Infrastructure → Backup Repositories → Add Repository → Object storage → S3 Compatible, then:

Name: a name for the repository.
Service point: the Exaba S3 endpoint as an HTTPS URL, for example https://s3.example.com.
Region: any non-empty string (i.e. exaba).
Credentials: the access key and secret from Step 2.
Bucket: browse and select the Veeam bucket. Leave “create new buckets automatically” unchecked and select an existing folder (or create one) inside the bucket.
Make recent backups immutable: enable it and set the period in Compliance mode. Veeam caps the period at 90 days in the UI; set it at least as long as your shortest retention and align it with your GFS policy.

Step 4: Attach it

Choose the model that fits your environment:

Direct-to-object (Veeam 12+): use the Exaba repository directly as the target of a backup job.
Scale-Out Backup Repository: attach the Exaba repository as the Capacity Tier (or Performance Tier) of an existing SOBR.

On the backup job, Local target (large blocks) storage optimization is recommended for object-storage uploads.

That is the entire configuration. There are no Exaba-specific flags, no headers to set, and no plug-ins to install.

Step 5: Run and verify a backup

Run a backup job, then complete the procurement-grade verification before declaring the migration done:

Confirm immutability is applied. Backup objects in the Exaba bucket carry an Object Lock retention attribute.
Attempt to delete a locked object before retention expiry. Confirm the delete is rejected with 403. This is the ransomware-resistance assertion.
Attempt to lower the retention on a locked object before its retention has expired (Compliance mode). Confirm it is rejected.
Run a restore. Confirm restore latency and throughput match your DR runbook expectations.
Run the S3-compatibility harness against both an existing S3-compatible target and the Exaba cluster, and diff the result logs. The Veeam Ready certification covers this configuration; running the harness gives you an audit-grade artifact for your file.

Exaba is one layer in your data-protection strategy

Important: Exaba provides a durable, immutable backup target, but it is one layer in a broader data-protection strategy, not a complete one. Follow established practice: keep multiple copies, in independent locations, and verify them regularly. Customers are responsible for configuring and operating Exaba appropriately for their environment.

Where to go for help

Veeam-side configuration questions: your Veeam support contact. Exaba is a certified target, so Veeam’s normal support channel covers the integration.
Exaba-side bucket, IAM, and Object Lock questions: see Production Installation, IAM, and the User Manual PDF shipped with your release.
Performance tuning for the backup window: see Hardware Sizing. Backup throughput is often the deciding factor in the cluster spec for backup-target deployments.