Veeam Backup & Replication offers two established ways to make backup data immutable: a hardened Linux repository, where the operating system protects the backup files, and an S3-compatible object storage repository with object lock, where the storage platform refuses deletion until a retention period expires. Both stop a ransomware operator or a rogue administrator from erasing restore points. They differ in who enforces the protection, how much infrastructure the backup team runs, and how each behaves as volumes and retention windows grow.
The choice matters more than it used to. Attackers target backup infrastructure early, and immutability has moved from an optional hardening step to a baseline expectation in security reviews and cyber insurance questionnaires. This article compares the two models on where immutability is enforced, operational burden, scale-out path, multi-site options, restore behavior, cost and what a compromised backup server can still do, then looks at running both together.
What does immutability mean in a Veeam context?
In Veeam terms, immutability means a restore point cannot be modified or deleted for a defined period, even by an account with full rights in the Veeam console. Relying on access control alone is the naive answer: it fails as soon as an attacker obtains those credentials, which is exactly what ransomware campaigns set out to do.
Immutability therefore has to be enforced somewhere the backup server cannot override. The hardened Linux repository places that enforcement point in the file system of a Linux host the backup team controls. An S3 object lock repository places it in the storage platform, which applies a retention rule to each object and rejects delete or overwrite requests until the rule expires.
How does a hardened Linux repository work?
A hardened repository is a Linux server with directly attached block storage formatted with XFS. Veeam writes backup files to it and sets the file system immutable attribute on each file for the configured retention period. While the attribute is set, the file cannot be deleted, renamed or modified, even by root, until a scheduled process on the repository clears it.
Two design choices make this credible. The repository is registered in Veeam with single-use credentials, so the backup server holds no persistent privileged login to the host. And the host is meant to be isolated: no remote password login, no directory domain membership, restricted SSH, and treatment as an appliance rather than a general-purpose server.
What the backup team takes on
The backup team becomes the owner of a small, security-sensitive Linux estate. Someone has to harden the OS image, apply kernel and package updates, monitor for drift, replace disks and control physical access. None of this is difficult, but all of it is recurring, and the immutability guarantee depends on it being done consistently.
Scaling is scale-up: add disks or replace the host with a larger one. Several hardened repositories can be grouped as performance extents in a scale-out backup repository, but each remains an independent host with its own patching, failure domain and capacity ceiling.
How does S3 object lock work as a Veeam repository?
With object storage, Veeam writes backup data as objects into a bucket with versioning and object lock enabled and sets a retain-until date on each object. The platform enforces that date: delete or overwrite requests before expiry are refused regardless of the credentials presented. Veeam extends retention dates for objects still needed by active restore points, so administrators never touch individual objects.
Object storage serves Veeam in two roles. As a capacity tier in a scale-out backup repository, it receives copies or offloaded restore points from a performance tier, typically for longer retention or offsite protection. As a direct-to-object performance tier, it receives primary backups straight from the jobs. The immutability mechanism is identical in both roles.
Where the operational burden moves
The backup team no longer patches a Linux host to preserve immutability. Hardening effort shifts to the storage platform's access model: a dedicated Veeam user, least-privilege bucket policies, MFA for administrative access and separation between backup and storage administration. An on-premises object store still has hosts to update, but that work belongs to the storage layer and does not weaken the lock if it slips.
Scaling is horizontal. Object storage grows by adding nodes or drives to a single namespace, so one bucket can grow from tens of terabytes to petabytes without re-architecting repositories or migrating data between hosts.
What can a compromised backup server do in each model?
In the hardened repository model, a compromised Veeam server can delete backup jobs, change retention policies and stop future backups. It cannot delete or modify files carrying the immutable attribute. But if the attacker also gains root on the Linux host, through a separate vulnerability, weak SSH configuration or physical access, the attribute can be cleared and the data destroyed. The hardened repository is only as strong as the Linux hardening around it.
In the object lock model, a compromised Veeam server can disrupt future backups in the same way but cannot shorten retention on objects already locked. With compliance-style locking, even the storage administrator cannot remove a lock before it expires. The attacker would have to compromise the storage platform itself: a separate system with separate credentials and, ideally, a separate team. That separation of duties is the core security argument for object lock.
How do restore behavior, multi-site options and cost compare?
Restore behavior
Restores from a hardened repository behave like any block-based repository: fast random access and instant recovery support. Restores from object storage depend on the platform. A well-provisioned on-premises object store delivers high throughput over a local network and supports instant recovery and file-level restores directly. Object storage in a hyperscale cloud may add egress charges and bandwidth limits to large restores, worth modeling before committing long retention there.
Multi-site and geographic options
A hardened repository is one machine in one location; offsite protection means a second hardened host elsewhere plus a backup copy job. Object storage platforms typically replicate between sites or buckets, and some stretch a single namespace across locations, so the storage layer can produce the second immutable copy rather than additional Veeam jobs and hosts.
Cost profile
A hardened repository is inexpensive to start: a server, drives and a Linux distribution. Its cost curve bends upward with scale because each host adds hardware, rack space and administrative time. Object storage has a higher entry point for a small deployment but flattens as capacity grows, particularly when erasure coding replaces mirroring and one platform absorbs retention that would otherwise need several hosts. Suppose an organization must keep 90 days of immutable restore points for 400 TB of source data; one storage platform versus a fleet of hardened servers becomes an operational cost question as much as a hardware one.
Decision table: hardened repository or object lock?
| Dimension | Hardened Linux repository | S3 object lock repository |
|---|---|---|
| Where immutability is enforced | XFS immutable attribute on a Linux host the backup team operates | Retention rule enforced by the object storage platform |
| Operational burden | OS hardening, patching, physical security per host | Storage-layer access policies; host maintenance owned by storage team |
| Scale-out path | Scale up per host; more hosts as SOBR extents | Add nodes or drives to a single namespace |
| Multi-site options | Second host plus backup copy jobs | Platform replication or stretched buckets |
| Restore behavior | Block-speed local restores, instant recovery | Fast on local object storage; egress and bandwidth considerations in public cloud |
| Cost profile | Low entry cost, rises with host count | Higher entry point, flattens at scale |
| Compromised backup server | Cannot delete locked files; root on the host could | Cannot shorten locks; requires separate compromise of the storage platform |
| Best fit | Short-term local retention, smaller sites, fast operational restores | Long retention, offsite copies, large or growing estates |
Why many organizations run both
The two models are not mutually exclusive, and the scale-out backup repository is built to combine them. A common pattern uses a hardened repository as the performance tier for recent restore points, where fast local restores matter most, and an object lock bucket as the capacity tier for longer retention and the offsite copy. Immutability applies at both tiers, so a short window on the hardened host does not leave older data exposed.
Questions that help settle the split:
- How long must restore points remain immutable, and can a single hardened host store that period comfortably?
- Who patches and monitors the hardened host, and is that role documented and staffed?
- Is an offsite immutable copy required by policy, regulation or insurer, and how will it be produced?
- Are backup and storage administration separated, so one compromised role cannot undo the other's controls?
- What restore throughput does the largest workload need, and where must that data live to meet it?
- How much will data grow over the retention lifetime, and which model absorbs that with the least re-architecture?
How Scality ARTESCA fits as an object lock target for Veeam
Scality ARTESCA is S3 object storage designed for backup, validated with Veeam as an object lock repository for both direct-to-object and capacity tier use. Immutability is enforced by the platform, so a compromised Veeam server cannot shorten or remove retention on locked objects. The security model is described on the ARTESCA security and cyber resilience page.
ARTESCA is available as software or a hardware appliance and scales from tens of terabytes to petabytes in a single namespace, which suits the long-retention and offsite roles where a hardened repository fleet becomes hard to manage. Guidance for sizing an object lock tier is in the backup repository sizing post, and the list of validated backup applications is on the backup compatibility page.
Whichever model is chosen, the practical step is the same: decide who is accountable for the enforcement point, document it, and test a restore from immutable data before an incident forces the question.