Veeam v13: Object First Ootbi Setup, SOSAPI, and Zero Trust Storage Architecture

Veeam v13 Series | Component: VBR v13, Object First Ootbi | Audience: Enterprise Architects, Hands-on Sysadmins, Security and Compliance Teams

Most conversations about immutable backup storage start with the Veeam Hardened Repository, a Linux box running XFS with immutable file attributes. It's a solid choice. But it has a constraint most people don't talk about: it's still a Linux server. Getting the OS deployment right, keeping it patched, making sure no one has added an SSH key it shouldn't have, making sure root access is actually restricted the way it needs to be. There's ongoing operational overhead that comes with that choice.

Object First's Ootbi appliance takes a different approach. It's purpose built hardware (or a VSA for labs and smaller environments) that exposes S3 object storage with Object Lock immutability baked in at the platform level. You never touch the OS. There's no SSH. There's no Linux to harden. The attack surface doesn't exist because the OS isn't accessible. And because it implements Veeam's Smart Object Storage API (SOSAPI), VBR treats it as more than a generic S3 bucket. It gets real capacity reporting, intelligent load balancing across nodes, and tighter integration than you get from any standard S3 compatible repository.

This article covers what Ootbi is, how SOSAPI works and what it actually changes, deploying and configuring Ootbi end to end, and where it fits in your overall Veeam architecture.

1. What Ootbi Actually Is

Ootbi stands for Out-of-the-Box Immutability. The name is accurate. You rack it, power it on, run through a short network configuration TUI, and you have an immutable S3 object storage target. Object First's founders include the team behind Veeam's original development, so the integration depth reflects that history.

Key architecture facts you need to understand before you deploy:

• Zero OS access. There's no SSH, no root shell, no exposed management plane beyond the web UI. The hardened appliance design means an attacker who compromises your VBR server still can't touch the Ootbi OS or its data directly.
• S3 Object Lock for immutability. Ootbi uses S3 Object Lock (versioning required) to enforce immutability. Backup files written with a configured retention period can't be deleted or modified for that duration, enforced at the object storage layer.
• Physical and virtual form factors. The physical appliance ships with two 10GBase-T ports onboard and two SFP+ 10Gb ports, with two ports active at a time, and both must use the same interface type: either Base-T or SFP+. Usable capacity per node runs from 64 TB to 192 TB depending on the model. You can cluster up to four nodes for 768 TB usable on a single cluster, and scale beyond 7 PB of usable immutable storage by using multiple Ootbi clusters as extents in a Veeam Scale Out Backup Repository (requires Veeam 12.1.2 or later). The VSA is available as a free download for lab use and smaller deployments.
• SOSAPI native. Ootbi was one of the two inaugural SOSAPI partners when Veeam launched the API in v12. The integration isn't a bolt-on. It's in the product from the start.
• 3 IPs required for a single node. Two physical interface IPs and one virtual IP (vIP) for the S3 endpoint. The vIP is what VBR connects to. The physical IPs handle the underlying node traffic. This is the minimum network planning you need to do before powering the appliance on.

2. SOSAPI: What It Does and Why It Matters

Standard S3 compatible storage and Veeam work fine together. You connect a bucket, VBR writes backups, it works. But standard S3 doesn't give Veeam any information about the storage platform itself. How much space is left? How should data be distributed across nodes? Is this bucket healthy? VBR is flying blind and making decisions without that context.

SOSAPI fixes that. It's a set of XML files that a SOSAPI capable storage platform maintains at the root of the bucket. VBR polls those files every few minutes. From them, it learns the total capacity and free space of the repository (the CapacityInfo feature), the current health state of the storage, and whether the platform supports Smart Entity load balancing. No additional ports, no plugins, no custom agents. It's layered on top of the existing S3 API using standard S3 operations. The storage platform is responsible for keeping those files accurate. VBR is responsible for reading and acting on them.

The Two Integration Levels You'll See in VBR

When you look at your backup repositories in VBR, you'll see two different representations for S3 object storage. The icon and the Type column tell you which level of integration is active:

You don't configure SOSAPI explicitly. When you add an Ootbi repository to VBR, VBR detects the SOSAPI XML files in the bucket and automatically upgrades the integration to S3 Integrated. If you see a green bucket icon after adding Ootbi, the files aren't in place or versioning isn't enabled. Both of those are configuration issues on the Ootbi side, covered in Section 3.

Smart Entity: How Load Balancing Actually Works

This is the SOSAPI feature that makes the biggest operational difference in multi node Ootbi clusters, and it's worth understanding mechanically.

When VBR is about to write a backup for a specific VM, it tells Ootbi through the SOSAPI: "I'm about to send you a backup for VM-1, and it's going to be approximately X GB." Ootbi evaluates which node in the cluster has the best capacity to receive that stream right now and responds to VBR with the specific node IP to send the data to. VBR then writes directly to that node instead of going through the vIP. The vIP is only used for the initial handshake and metadata operations. Actual backup data goes node to node.

The result is that in a three node cluster running six simultaneous backup jobs, those streams get distributed across the nodes intelligently instead of all hammering the same node through the vIP. You get better throughput and more even storage utilization without doing anything in Veeam to achieve it.

3. Deploying and Configuring Ootbi

Physical Appliance: Initial Network Setup

When you power on a physical Ootbi node for the first time, it boots into a text UI (TUI) for initial configuration. You'll need your three IPs ready before you start: two interface IPs and the vIP.

1. Connect to the appliance via IPMI or directly on console. The TUI launches automatically on first boot. The default IPMI credentials are on the service tag of the appliance.
2. Configure the first network interface: IP address, subnet mask, default gateway, primary and alternate DNS. This interface handles S3 data traffic.
3. Configure the second network interface with its IP. If you're only using one network interface initially (single connected interface), uncheck the second interface configuration and proceed with just the one.
4. Enter the hostname for the node and press Enter.
5. The appliance checks for and applies available firmware and software updates at this stage. Let it complete. Updates can take several minutes.
6. After updates complete, the TUI shows you the web UI access URL. Note it and proceed to the web UI for the rest of configuration.

VSA Deployment

Download the Ootbi VSA OVA from objectfirst.com. Deploy it in vCenter the same way you'd deploy any OVA: Deploy OVF Template, select the OVA file, choose your cluster and datastore, map the networks, and configure the VM settings. The VSA supports the same web UI configuration as the physical appliance once it boots.

The VSA is ideal for lab environments and for testing your Veeam integration before committing to physical hardware. Keep in mind that VSA performance is limited by your underlying vSphere infrastructure, not by Ootbi's storage engine. Production environments should use the physical appliance.

Web UI Initial Configuration

The Ootbi web UI walks you through the remaining configuration via a wizard on first login. The default username is objectfirst with the password you set during the TUI phase.

1. Log in to the web UI at https://your-ootbi-vip. You'll be prompted through the setup wizard immediately.
2. The first step is creating S3 Keys. The wizard generates an Access Key and Secret Key for your user account. Copy both immediately. The Secret Key is only shown once. Store both in your enterprise password manager before proceeding.
3. If you want a dedicated Veeam service account (recommended), create a new user first, log out, log in as that user, and generate its S3 Keys. Using a dedicated account means you can rotate or revoke credentials without affecting any other Ootbi integrations.
4. Next, create the S3 Bucket. Name it clearly: something like veeam-primary-prod. The most critical option on this screen is Enable versioning. This is required for immutability. Without versioning enabled, Object Lock doesn't work, and the bucket won't support the immutability configuration you'll set in VBR. Enable it. Don't skip it.
5. Set the vIP in the cluster settings if you haven't already. The vIP is the endpoint address VBR will use to connect to Ootbi. It should be a static IP in the same subnet as your interface IPs but separate from them.

Note the Service Point

Before you leave the Ootbi dashboard, copy the Service Point value from the dashboard. It's in the format https://your-ootbi-vip. This is what you paste into VBR when adding the repository. You can find it under the main dashboard overview or in the S3 configuration settings.

4. Adding Ootbi as a Repository in Veeam v13

This is the VBR side of the configuration. You're adding Ootbi as a direct S3 compatible object storage repository, not as a capacity tier. The distinction matters: Ootbi as a primary repository means your backup jobs write directly to it. You're using it as your landing zone, not just as offsite archive storage.

1. In the VBR console, go to Backup Infrastructure, right click Backup Repositories, and select Add Backup Repository.
2. Select Object Storage as the repository type.
3. Select S3 Compatible as the object storage type. Don't select any of the named cloud providers. Ootbi connects as S3 Compatible.
4. Give the repository a clear name. Include Ootbi in the name so it's identifiable in job configurations and reports.
5. On the Account step, paste the Service Point URL you copied from the Ootbi dashboard into the Service point field. Set the Region to the value shown in the Ootbi dashboard (typically "default" for on-premises Ootbi deployments, or a custom region string if you configured one).
6. Click Add to enter your credentials. Enter the Access Key and Secret Key from the Ootbi S3 Keys you created. Click OK.
7. VBR will attempt to connect to Ootbi and verify the credentials. If it shows a certificate warning about a self-signed certificate, click Continue to accept. Ootbi ships with a self-signed certificate by default. You can replace it with a trusted certificate later via the Ootbi web UI if your environment requires it.
8. On the Bucket step, click Browse and select the bucket you created in Ootbi. Click New Folder and create a folder for your backups (for example, veeam-backups). Don't write directly to the bucket root.
9. On the Immutability step, enable "Make recent backups immutable for." In v13, you have two choices here: a fixed number of days, or protect the entire backup chain for the duration of the retention policy. The retention policy option is new in v13 and the better default for most environments. It ensures the immutability window always covers your retention, regardless of how long individual jobs run.
10. Complete the remaining wizard steps (Mount Server, Review, Apply). After the repository is created, check the Type column in the Backup Repositories list. If it shows S3 Integrated with the blue bucket icon, SOSAPI is active and Ootbi is communicating capacity and health data to VBR. If it shows S3 Compatible, versioning isn't enabled on the bucket. Go back to Ootbi, confirm versioning is on, and rescan the repository in VBR.

5. Immutability Settings: What to Actually Configure

You have two levers for immutability: the setting in VBR when you configure the repository, and the Object Lock settings on the Ootbi bucket itself.

The VBR setting controls how long each backup object is immutable from the moment it's written. The bucket versioning setting in Ootbi is a prerequisite. These two work together, but they're separate things. VBR applies the Object Lock retention via the S3 Object Lock API when it writes each object. Ootbi enforces it at the storage layer. Even if someone gained access to VBR and tried to delete the backup job or the restore points in the VBR database, the actual objects in Ootbi can't be deleted until their Object Lock retention expires.

Fixed Days vs Retention Policy Mode

Fixed days is straightforward: every backup object written is immutable for exactly that many days from creation. Simple to reason about. The downside is that if you run a job for 30 days but your retention is 14 restore points, older objects may still be immutable when VBR tries to prune them. VBR will flag them as locked and skip deletion until the immutability period expires. That's correct behavior, not an error, but you need to size your storage with this in mind.

Retention policy mode (new in v13 for S3 repositories) protects the entire backup chain for the duration of your configured retention. VBR calculates the immutability window based on how long the chain is supposed to live and applies that to each object. When the retention period ends for a restore point, the immutability also expires. It's more dynamic and usually the better choice because it aligns immutability with actual retention intent rather than requiring you to manually tune the two independently.

6. Using Ootbi as a SOBR Extent

You don't have to use Ootbi as a standalone repository. It works as an extent in a Scale Out Backup Repository, which is how you'd use it in environments where you're already running a SOBR with a performance tier and want to add Ootbi as either the performance tier, the capacity tier, or an additional performance tier extent.

Adding an Ootbi repository as a SOBR extent is the same as adding any other repository: in the SOBR configuration, add the Ootbi repository to the Performance Tier. Each Ootbi node you've added as a separate repository can be a separate extent. SOBR then distributes backup data across the extents automatically, and SOSAPI capacity reporting feeds VBR the free space per extent so placement decisions are accurate.

Since Veeam v12.1, you can use multiple SOSAPI enabled repositories as extents in the same SOBR performance tier and VBR will have accurate capacity data per extent for initial placement. This is how you scale Ootbi beyond a single node without losing the VBR management benefits that SOSAPI provides.

7. DR Testing with IAM Read Only Access

There's a scenario that catches people out: you want to test restores from Ootbi on a secondary VBR server (a DR server, a standby, a test environment) without that secondary server being able to take ownership of the production repository or write to it. By default, if you attach an existing Ootbi repository to a second VBR server using the same credentials, VBR will attempt to take complete ownership and this can interfere with the primary VBR server.

Ootbi supports IAM policies, which lets you solve this cleanly. Create a separate read only IAM user and policy in Ootbi for your DR server, with permissions to list and get objects but not to put, delete, or modify them. Your DR VBR server connects using those restricted credentials. VBR warns you about repository ownership but the restricted policy prevents it from taking ownership or making changes. The production repository stays intact and the DR server can restore from it.

Object First's documentation covers the specific IAM policy JSON for the DR read only use case. The policy structure is S3 compatible and similar to what you'd write for AWS IAM. The Ootbi web UI has the IAM section under the security or access management area depending on your firmware version.

8. Where Ootbi Fits in Your Overall Architecture

Ootbi is a primary backup landing zone, not a capacity tier. That's an important distinction. Most S3 object storage in Veeam environments is configured as the capacity tier of a SOBR: recent restore points live on fast local storage (a VHR or SAN), older points tier out to object storage automatically. Ootbi is designed to handle the primary backup write path directly. You're writing backup jobs straight to Ootbi from the start, not waiting for data to age out.

That's practical because Ootbi is fast enough for it. The 2 x 10GbE connections on the physical appliance and the SOSAPI Smart Entity routing means you won't hit performance bottlenecks that plague generic object storage in the primary write path. Object First publishes ingest speed at 1 to 2 GB/s per node on the current generation appliance. In practice throughput depends on your workload and network configuration. On a single 10GbE link the network is the constraint, not Ootbi.

A common architecture that works well:

• Primary backup jobs write to Ootbi as the performance tier repository (or as a standalone primary repo). Ootbi provides immutability on the primary copy.
• Backup Copy jobs run from Ootbi to a cloud object storage target (Wasabi, Backblaze B2, your cloud of choice) for the offsite copy. Object Lock on the cloud bucket gives you immutability on the offsite copy.
• SureBackup verification jobs run against the Ootbi restore points. The SOSAPI capacity reporting means VBR can make informed scheduling decisions when the repository is near capacity.
• In a ransomware event, Ootbi restore points are your recovery source. Because Ootbi is hardware separated from your Veeam server, even a complete Veeam server compromise leaves Ootbi intact and its Object Lock immutability enforced.