If you run Veeam and want an immutable primary repository, there are two mainstream routes: build a Veeam Hardened Repository on a Linux server, or buy an Object First Ootbi appliance. Since Veeam acquired Object First in January 2026, both come from the same company. In Veeam’s own words, you can build it yourself on the hardware you choose, or buy it hardened out of the box. The choice is less about which is more secure than about what each asks of you.
View the data behind this chart
| Object First Ootbi | Hardened Repo (VIA) | Hardened Repo (own Linux) | |
|---|---|---|---|
| What is locked | S3 objects | Backup files | Backup files |
| Lock enforced by | Object Lock, compliance | Linux file system | Linux file system |
| OS hardening | Object First | Veeam image | Your team |
| Veeam connects with | S3 access key | Certificate | Single-use credentials |
| Forever-forward | Recommended | Not supported | Not supported |
| Hardware | Object First appliance | Your server | Your server |
Two ways to the same goal
A Hardened Repository is block storage. Veeam installs its Data Mover on a Linux server with local or remotely attached block storage, and makes backup files immutable at the file-system level for the period you set; during it they cannot be moved, modified or deleted, but can be copied. Veeam recommends XFS for its performance and block cloning.
Ootbi is object storage. Veeam writes to an S3 bucket on the appliance, and Object First applies S3 Object Lock in compliance mode, under which no user, including an administrator, can delete a locked object version or shorten its retention. Object First adds what it calls Zero Access: no destructive actions against the appliance’s firmware, OS or storage software either. See how Ootbi’s immutability works.
What building a Hardened Repository involves
Veeam now recommends deploying the Hardened Repository from its Veeam Infrastructure Appliance ISO, which installs a prepared operating system and sets up the role. Hardened repositories deployed that way use certificate-based authentication with no SSH, cannot have multi-factor authentication disabled unless Security Officer accounts are enabled, and cannot be joined to a domain. Veeam also recommends disabling the appliance’s Host Management web interface to cut the attack surface.
If you build the Linux server yourself, Veeam’s requirements are specific. A physical machine with local storage is recommended. The data array should be RAID 6 or 60 with write-back cache and a 128 or 256 KB stripe, with the disks’ own cache disabled; the OS should sit on mirrored SSDs of at least 100 GB. NFS and SMB storage are not allowed. The server should have a redundant network connection, cannot be shared between Veeam servers, and must not have Veeam Agent for Linux installed. You connect it with single-use credentials that Veeam never stores.
None of this is hard for a team that runs Linux. It is ongoing work, though: patching the OS, watching the hardware, keeping the configuration from drifting, and knowing that on a self-built Linux server, anyone who gains root can generally remove a file’s immutable flag.
The backup-chain difference
One operational difference is easy to miss. A Hardened Repository supports only forward incremental backups with periodic active or synthetic fulls; Veeam rules out reverse incremental and forever-forward incremental, because an immutable file cannot be merged until its lock expires. XFS block cloning keeps synthetic fulls cheap on disk.
On Ootbi the opposite advice applies. Object First’s checklist recommends forever-forward incremental and warns that cloned jobs with active fulls enabled store extra full backups, because Veeam reuses existing blocks in object storage for synthetic fulls and merges but not for active fulls. If you move jobs between the two, review the backup method, not just the target. Our object storage sizing guide shows what active fulls cost on immutable object storage.
Who carries the hardening
This is the real dividing line. With a Hardened Repository you choose the hardware and own the platform: the server vendor supports the hardware, Veeam supports the software, and your team, or the Veeam appliance image, keeps the operating system in shape. With Ootbi, Object First takes the support case for the whole box and coordinates any hardware replacement with the hardware vendor; each unit includes three years of support, and Object First supplies the firmware, OS and software updates.
Neither removes your share of the work. Object First’s own hardening guide still asks you to keep the appliance off public IPs, restrict or unplug iDRAC, set up MFA, change factory passwords and lock the room. But the list is shorter, and it does not include maintaining Linux.
Where each one fits
A Hardened Repository suits teams with Linux skills, an existing server estate or a preferred hardware vendor, and estates large enough that choosing dense storage servers matters. It keeps Veeam’s storage-agnostic promise: any supported server, any capacity.
Ootbi suits teams that would rather not run Linux, that want compliance-mode Object Lock without building it, and distributed estates, where the desktop Ootbi Mini and the free Fleet Manager cover branches without local IT. It is also the quicker route for service providers who want a uniform, supportable target at every client.
Both need a second copy elsewhere. Immutability on one site does not survive the loss of that site, which is why Veeam’s Zero Trust Data Resilience model calls for multiple resilience zones. See what ZTDR asks for.
Our view
We supply both: the servers and storage for a Hardened Repository, specified to Veeam’s requirements, and Object First appliances. For most mid-sized UK estates without dedicated Linux staff, Ootbi is the lower-risk choice because the hardening is done and stays done. Where there is an existing server estate and the skills to run it, a Hardened Repository on the Veeam Infrastructure Appliance is a strong, flexible option. Either way, size for Veeam’s actual retention, not the number in the job.