Veeam Backup & Replication with RustFS

Prepare the bucket and credentialsCopy Anchor Link

Create a dedicated bucket with versioning and Object Lock enabled. Versioning is a prerequisite for the Object Lock that Veeam immutability relies on:

rc bucket create <your-alias>/veeam-repo --with-lock
rc bucket version info <your-alias>/veeam-repo

Use the following bucket-scoped starting policy and validate it with your selected Veeam mode. Bucket operations and object operations use separate resource scopes. The policy omits s3:CreateBucket because the bucket already exists. This is not a proven minimum-permission policy: the lab policy includes legal-hold management and governance-retention bypass. Review whether those permissions are required and remove unnecessary privileges before production use. In particular, s3:BypassGovernanceRetention permits bypassing governance-mode protection; do not assume this credential cannot delete protected versions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject","s3:PutObject","s3:DeleteObject",
                 "s3:GetObjectVersion","s3:DeleteObjectVersion",
                 "s3:AbortMultipartUpload","s3:ListMultipartUploadParts",
                 "s3:PutObjectRetention","s3:GetObjectRetention",
                 "s3:PutObjectLegalHold","s3:GetObjectLegalHold",
                 "s3:BypassGovernanceRetention"],
      "Resource": ["arn:aws:s3:::veeam-repo/*"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket","s3:ListBucketVersions","s3:GetBucketLocation",
                 "s3:GetBucketVersioning","s3:GetBucketObjectLockConfiguration",
                 "s3:ListBucketMultipartUploads"],
      "Resource": ["arn:aws:s3:::veeam-repo"]
    }
  ]
}

rc admin policy create <your-alias> veeam-repo-rw <path-to-policy-file>
rc admin user add <your-alias> veeam <your-secret-key>
rc admin policy attach <your-alias> veeam-repo-rw --user veeam

Veeam requires HTTPS for S3-compatible object storage. You can terminate TLS in front of RustFS with Traefik or Nginx. Use a certificate whose SAN covers the endpoint hostname and whose chain is trusted by the VBR server and the Agent or gateway that transfers data. For a private CA, install its root CA certificate in the appropriate trusted-root stores; do not import an arbitrary endpoint certificate as a trusted CA or disable verification.

Keep lifecycle expiration and transition rules off this dedicated backup bucket; let Veeam manage backup retention. See Veeam Agent object storage limitations.

Add the RustFS repository in VBRCopy Anchor Link

In the VBR console, go to Backup Infrastructure → Backup Repositories → Add Repository → Object storage → S3 Compatible:

1. Service point: your RustFS HTTPS endpoint, Region: us-east-1.
2. Credentials: the veeam access key and secret key. Select Direct for the illustrated data path; choose a gateway when direct access is unsuitable.
3. Bucket: veeam-repo, Folder: veeam.
4. Before selecting Folder, create an object under veeam/ with an S3 client if the fresh bucket has no prefixes, then use Browse.
5. If testing immutable backups, enable Make backups immutable and validate object retention separately. Enabling Object Lock on a bucket alone does not make every backup immutable.

When Veeam reports that automatic bucket provisioning fails with Access Denied, choose Yes to disable it and proceed — the bucket exists and the IAM user intentionally cannot create buckets.

For Agent backups, explicitly configure Set Access Permissions → Security as described in Veeam's S3-compatible repository access instructions. Provided by the backup server uses a gateway or mount server, even when the repository says Direct. True Direct access requires a compatible IAM/STS configuration or Agents share credentials to object storage repository. The latter exposes the repository credentials to protected machines and is less secure; use it only in an isolated POC if needed. Generic IAM/STS support is not proof that Veeam's credential workflow is compatible; validate the selected mode before production use.

The lab report does not record the Security selection, so it does not independently confirm that data bypassed a gateway.

On success, the repository is listed as S3-compatible. Used Space is Veeam's reported usage, not an independent measurement of RustFS capacity:

Enroll the protected computerCopy Anchor Link

The backup job alone does not install the Veeam agent. Use a protection group:

1. Inventory → Physical and Cloud Infrastructure → Add protection group…
2. Type Individual computers, add the machine with its real hostname and local administrator credentials in HOSTNAME\user form.
3. Keep Install Veeam Backup & Replication Agent enabled, then Apply.

Run the backup jobCopy Anchor Link

1. Home → Backup Job → Windows computer…
2. Computers: From protection group, Backup Mode: Entire computer.
3. Storage: Backup repository = RustFS, retention as needed.
4. Finish, then right-click the job and select Start.

After the job completes, the job list shows Last Result: Success and the restore point appears under Home → Backups → Object Storage → RustFS Veeam Backup:

Verify the objects in RustFS:

rc object find <your-alias>/veeam-repo/ | tail -1

The test observed data objects under Veeam/Backup/veeam/Clients/{agent-id}/…. Listing an object alone does not verify backup completeness, a restore point, or immutable retention.

Restore filesCopy Anchor Link

1. Home → Backups → Object Storage → RustFS Veeam Backup → .
2. Right-click the restore point → Restore guest files… → Browse.
3. Pick a file in the Backup Browser, restore it to a target folder, and verify its content.

A successful restore with matching file content validates the backup-to-file-recovery workflow for that file. It does not prove every restore point is recoverable. For an immutable-backup POC, also inspect retention mode and expiry and verify that protected versions cannot be deleted during retention using controlled test data; do not run destructive checks against production backups.