Docs

Backups with Veeam (Scale-Out Backup Repository)

This guide adds chili as an immutable Capacity Tier behind a Veeam Scale-Out Backup Repository (SOBR). You prepare a bucket with Object Lock, register it in Veeam as an S3 Compatible object storage repository, attach it to the SOBR, turn on immutability, and verify with a restore. Because chili charges no egress, restore and SureBackup tests cost nothing extra.

Prerequisites

  • Veeam Backup & Replication v12 or later (S3 Compatible immutability was introduced in v12 and is available in v12.x and v13)
  • chili access keys (access key and secret) from the portal
  • a chili bucket with both Object Lock and Versioning enabled, default retention left as None and no lifecycle rules
  • your chili S3 endpoint and the Region string your portal expects (use the values from your chili credentials; verify them in the portal)
  • an existing Veeam backup repository to use as the Performance Tier of the SOBR
  • a Mount Server reachable for restores

1. Prepare the chili bucket

chili enforces Object Lock (WORM) server-side, so the lock state lives on the bucket, not on the Veeam side. Before you register the bucket, enable both Object Lock and Versioning together. Veeam requires both to be on, and the bucket must not have default retention enabled and lifecycle rules are not supported because they can cause backup or restore failures.

  • Object Lock: enabled
  • Versioning: enabled
  • Object-lock default retention mode: leave as None (otherwise the bucket cannot be registered with Veeam)
  • Lifecycle rules: none

Veeam Backup & Replication itself applies Compliance object lock mode to each uploaded object and manages the per-object immutability timestamp automatically. Do not set a provider-side default retention period yourself, and do not rely on Governance mode for this Veeam feature.

If you want to set Object Lock and Versioning from a script rather than the portal, an S3 client pointed at chili works the same way it does for AWS. With rclone the remote looks like this:

[chili]
type = s3
provider = Other
access_key_id = AKIA...
secret_access_key = ...
endpoint = https://<ENDPOINT>

2. Add chili as an S3 Compatible object storage repository

In the Veeam console, open Backup Infrastructure > Backup Repositories > Add Repository > Object Storage > S3 Compatible (equivalently, the Object Storage Repositories node > Add Object Storage > S3 Compatible). This launches the New Object Storage Repository wizard, whose steps are:

1. Launch New Object Storage Repository Wizard
2. Specify Object Storage Name
3. Specify Object Storage Account
4. Specify Object Storage Settings
5. Specify Mount Server Settings
6. Review Components
7. Apply Settings
8. Finish Working with Wizard

On Specify Object Storage Account, add your chili keys: open the Credentials dropdown, choose Add..., and enter the S3 access key and secret. Keep these out of any scripts or screenshots you share.

3. Specify the connection and immutability

On the Specify Object Storage Settings step, fill the exact fields:

  • Service point: the chili endpoint address plus port, for example https://<your-chili-endpoint>:443. Use the value from your chili credentials; verify the exact host and port in the portal.
  • Region: the region string your chili portal expects. If you are unsure, check it in the portal rather than guessing.
  • Bucket: select the bucket you prepared in step 1 via Browse.
  • Folder: select or create a folder for backups via Browse.

To make the tier immutable, select the Make recent backups immutable for [N] days check box and enter the period. This prohibits deletion of blocks of data from object storage for the chosen number of days. A common value is 30 days, but that is your own retention guidance and not a number Veeam mandates, so set it to match your policy.

The maximum immutability period you can enter in the GUI is 90 days. For a longer period, set it from PowerShell with the Set-VBRAmazonS3CompatibleRepository cmdlet instead.

Finish the wizard: confirm the Mount Server on Specify Mount Server Settings, check the Review Components page, run Apply Settings, and close on Finish Working with Wizard.

4. Attach chili to the Scale-Out Backup Repository

Open Backup Infrastructure > Scale-out Repositories and edit (or add) the SOBR. On the Capacity Tier step, enable Extend scale-out backup repository capacity with object storage and select the chili repository as the extent. Extents can be added at any time, and the Capacity Tier step is where you define the copy and offload policy and the time windows that control when backups move to chili.

A point worth keeping in mind: the data in a bucket used as a Veeam repository must be managed solely by Veeam Backup & Replication. Do not write to or prune the chili bucket from other tools.

Verify

The cheapest way to prove the chain works end to end is a restore, since chili charges no egress and a read costs nothing. Run a restore or a SureBackup job that reads data back from the Capacity Tier:

Backup Infrastructure > Scale-out Repositories > <your SOBR>
  -> run a SureBackup job, or restore a single file from the Capacity Tier

A successful, verified restore of a backup that lives on the chili extent confirms the repository, immutability, and the SOBR are wired up correctly. You can also inspect the repository properties in Veeam and confirm the immutability period is shown for the chili extent.

Common pitfalls

  • Service point must be the full HTTPS endpoint including the scheme, for example https://<your-chili-endpoint>. Verify host and port in the chili portal.
  • Object Lock and Versioning have to be enabled together, and before you register the bucket. Turning Versioning off later breaks immutability.
  • Leave the bucket default retention as None and configure no lifecycle rules. Veeam applies Compliance mode per object itself; a provider-side default retention or a lifecycle rule can cause backup or restore failures.
  • The 90-day cap is a GUI limit only. For longer retention use Set-VBRAmazonS3CompatibleRepository from PowerShell.
  • If you are unsure of the Region string, check it in the portal rather than inventing one.

The result: an immutable, off-site Capacity Tier in Switzerland, in Zurich or Geneva and geo-redundant on request, with no egress fees, so restore and SureBackup tests cost nothing extra.