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 behavioural 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

CapabilityStatusNotes
Direct-to-object backupSupportedVeeam 12+ can use an Exaba bucket directly as a backup job target.
Capacity TierSupportedExaba bucket targets the Capacity Tier of a Scale-Out Backup Repository.
Performance TierSupportedFor latency-sensitive restore workloads.
Smart Object Storage API (SOSAPI)SupportedLets Veeam discover storage capacity and capabilities automatically.
Object Lock (Compliance mode)SupportedVeeam’s immutability flow uses Compliance mode: strict immutability that cannot be cleared early.
Object Lock (Governance mode)SupportedAvailable on Exaba, though Veeam immutability uses Compliance mode.
VersioningSupportedRequired by Veeam’s immutability flow.
Legal HoldSupportedIndependent 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

  1. 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).
  2. Ensure versioning is enabled (Object Lock requires it).
  3. Do not set a bucket-level default retention. Veeam applies retention per object; a bucket default can cause unpredictable behaviour and data loss.

Step 2: Create an IAM user for Veeam

  1. Create an Exaba IAM user for Veeam, then issue an access key and secret and hand them to your Veeam administrator.
  2. Grant the user a role scoped to the Veeam bucket only. Exaba uses AWS-style JSON policy documents; 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:ListBucketVersions",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:GetObjectRetention",
        "s3:GetObjectLegalHold",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold"
      ],
      "Resource": [
        "arn:aws:s3:::veeam-backups",
        "arn:aws:s3:::veeam-backups/*"
      ]
    },
    {
      "Sid": "VeeamListBuckets",
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::*"
    }
  ]
}

s3:ListAllMyBuckets is only needed if your Veeam administrator browses for the bucket; from Veeam 11a onward it can be omitted when the bucket name is entered manually. For defence in depth, attach the same scope as a per-bucket policy as well: Exaba evaluates RBAC and the bucket policy together, so both must permit an operation. 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 optimisation 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:

  1. Confirm immutability is applied. Backup objects in the Exaba bucket carry an Object Lock retention attribute.
  2. Attempt to delete a locked object before retention expiry. Confirm the delete is rejected with 403. This is the ransomware-resistance assertion.
  3. Attempt to lower the retention on a locked object before its retention has expired (Compliance mode). Confirm it is rejected.
  4. Run a restore. Confirm restore latency and throughput match your DR runbook expectations.
  5. 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 artefact 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.

See also