Setting Up Immutable Backups with Veeam, Wasabi, or S3 Object Lock

Why standard backups are no longer enough against ransomware

The days when ransomware simply encrypted files on the desktop are over. Modern ransomware groups operate according to a methodical playbook: they gain access to the network, often through phishing or compromised VPN credentials. Then they move undetected through the infrastructure for weeks or months, acquire administrator privileges, and map the environment. Before they launch the encryption, they specifically seek out and destroy the backups.

The pattern is well documented. Ransomware families such as LockBit, BlackCat, and Royal include modules that automatically search for backup software (Veeam, Acronis, Veritas), stop backup services, delete backup repositories, and remove shadow copies. When the attacker has administrator privileges and your backup system is reachable through the same Active Directory, your backups are just as vulnerable as your production data.

Immutable backups solve this problem because they are neither deletable nor modifiable even for an attacker with full administrator privileges. Immutability is enforced not through access rights (which an admin can bypass) but through technical mechanisms that cannot be overridden for the defined period.

What "immutable" means technically

Immutability can be implemented at various levels, and not all implementations are equally secure.

Object Lock at the storage level

S3 Object Lock (and compatible implementations from other providers) prevents the deletion and overwriting of objects for a defined period. There are two modes:

Governance Mode: Objects are protected, but users with special permissions (s3:BypassGovernanceRetention) can lift the protection. This is useful for testing purposes but does not provide complete protection against an attacker with root access to the AWS account.

Compliance Mode: Objects cannot be deleted or modified by anyone until the retention period expires. Not even the root account of the AWS account can lift the protection. This is the most secure variant but also the least flexible. If you set an incorrect retention period, you must wait until it expires.

Immutable flag at the filesystem level

Linux filesystems (ext4, XFS) support the immutable attribute via chattr +i. Files with this attribute cannot be modified, deleted, renamed, or linked -- not even by root. The attribute can only be removed by root with chattr -i, meaning an attacker with root access can lift the protection.

Veeam uses this concept in the Hardened Repository with an additional safeguard: the Veeam service that writes the backups does not have root access. It sets the immutable flag via a separate process, and the only way to remove the flag is local root access to the Linux server (which is additionally secured, e.g., by disabling SSH root login).

WORM storage at the hardware level

Specialized storage systems such as NetApp SnapLock or dedicated WORM appliances implement immutability at the hardware level. This is the most secure but also the most expensive option and overkill for most mid-market companies.

Option 1: Veeam Hardened Linux Repository

The Veeam Hardened Repository is the most popular solution for immutable backups among SMEs. It is based on a hardened Linux server that serves as a backup target.

How it works

A dedicated Linux server (Ubuntu or RHEL/Rocky) is installed with a minimal configuration and hardened. Veeam installs a transport service on the server that receives and writes backup data. For each written backup file, the immutable attribute is automatically set. The retention period is configured in Veeam. Only after the period expires may the file be deleted.

The critical security mechanism is the separation of privileges. The Veeam service on the Linux server runs under an unprivileged user and has no root access. It can write files and set the immutable flag (via a SUID helper) but cannot remove the flag. SSH root login is disabled. The only way to remove the immutable flag is local console access with the root password.

Setup step by step

1. Prepare the Linux server: Install Ubuntu Server 22.04 LTS (or newer) with minimal configuration. No desktop, no unnecessary services. Create a dedicated user for Veeam (e.g., veeamrepo) and configure SSH key authentication for this user. Disable SSH root login and password authentication.

2. Provision storage: Set up an XFS filesystem for the backup data. XFS is recommended because it reliably supports the immutable attribute and handles large files efficiently. Format the volume and mount it permanently (e.g., under /mnt/veeam-repo).

3. Add as repository in Veeam: In the Veeam console, add the Linux server as a "Direct attached storage" or "Linux" repository. Enable the option "Make recent backups immutable for X days." Veeam recommends at least 7 days; 14 to 30 days is more practical.

4. Harden the server: Configure a local firewall (iptables/nftables) that only allows Veeam traffic on the required ports. Set up automatic security updates (unattended-upgrades). Restrict physical access to the server.

Pitfalls and best practices

The Veeam service account must not have sudo privileges. This sounds obvious but is sometimes overlooked during setup because the automatic configuration via SSH initially requires elevated privileges. After setup, these must be removed.

The immutability period must be longer than your retention policy for the oldest recovery points. If you want to retain 14 days and set immutability to 7 days, backups from day 8 onward are no longer protected.

Plan enough storage capacity. Immutable backups cannot be prematurely deleted to free space. If your repository fills up and the oldest backups are still immutable, new backup jobs will fail.

Option 2: Wasabi Hot Cloud Storage with Object Lock

Wasabi has established itself as a cost-effective alternative to AWS S3 for backup purposes. The major advantage over AWS: Wasabi charges no egress fees, which is critical for backup scenarios. You pay for stored data volume, not for downloads during a restore.

Pricing model

Wasabi currently charges 6.99 USD per TB per month (as of March 2026), with no egress fees and no API request fees. For comparison: AWS S3 Standard costs 23 USD per TB per month plus egress fees of 90 USD per TB. For a backup volume of 5 TB, you pay approximately 35 USD per month with Wasabi, versus approximately 115 USD per month with AWS S3 Standard (excluding egress).

Wasabi has a minimum storage duration of 90 days. If you delete an object after 30 days, you still pay for 90 days. For backup scenarios with typical retention periods of 30 to 90 days, this is a non-issue.

Setting up Object Lock with Wasabi

1. Create a bucket with Object Lock: Object Lock must be enabled when creating the bucket. It cannot be added retroactively. In the Wasabi console or via CLI: aws s3api create-bucket --bucket my-backup-bucket --object-lock-enabled-for-bucket --endpoint-url https://s3.eu-central-1.wasabisys.com

2. Configure default retention: Set a default retention for the bucket in Compliance Mode: aws s3api put-object-lock-configuration --bucket my-backup-bucket --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}' --endpoint-url https://s3.eu-central-1.wasabisys.com

3. Create an IAM user: Create a dedicated user for the backup software with minimal permissions: PutObject, GetObject, ListBucket. Explicitly do not grant DeleteObject or s3:BypassGovernanceRetention.

4. Configure backup software: Configure Veeam (Scale-out Repository with Capacity Tier), Restic, BorgBackup, or another S3-compatible tool with the Wasabi endpoint and the credentials of the dedicated user.

Wasabi-specific notes

Wasabi supports both Governance and Compliance Mode. For backups, use exclusively Compliance Mode because Governance Mode can be bypassed by a user with the appropriate permissions.

Object Versioning is automatically enabled with Object Lock. This means that even on an overwrite attempt, the old version is preserved. This increases storage consumption but provides additional protection.

Wasabi has data centers in Europe (Amsterdam, Frankfurt). For DSGVO (GDPR)-compliant data storage, you should choose a European location.

Option 3: AWS S3 with Object Lock

AWS S3 is the reference standard for Object Lock implementations. If you already use AWS or need the enterprise features of S3, it is the natural choice.

S3 storage classes for backups

Not every S3 storage class is equally suited for backups. S3 Standard offers the lowest latency and fastest access but is the most expensive option. For backups you rarely retrieve, that is wasteful.

S3 Glacier Instant Retrieval is significantly cheaper (approx. 4 USD per TB per month) and provides access in milliseconds. This is the best option for backups you need quickly in an emergency but rarely access.

S3 Glacier Flexible Retrieval is even cheaper (approx. 3.60 USD per TB per month), but access takes minutes to hours. Suitable for long-term archiving, not for operational DR.

S3 Glacier Deep Archive is the cheapest option (approx. 1 USD per TB per month), but access takes up to 12 hours. Only practical for regulatory long-term archiving.

All storage classes support Object Lock.

Setup

1. Create a bucket with Object Lock: As with Wasabi, Object Lock must be enabled when creating the bucket. aws s3api create-bucket --bucket my-backup-bucket --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1 --object-lock-enabled-for-bucket

2. Lifecycle rules for storage class transition: Configure a lifecycle rule that moves backups to a cheaper storage class after a defined time: e.g., after 30 days from S3 Standard to Glacier Instant Retrieval, after 90 days to Glacier Flexible Retrieval.

3. Set default retention in Compliance Mode: aws s3api put-object-lock-configuration --bucket my-backup-bucket --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

4. Create an IAM policy: Create a restrictive IAM policy that grants only the necessary permissions. Explicitly block DeleteObject and BypassGovernanceRetention.

5. Enable MFA Delete: For additional protection, you can enable MFA Delete, which requires multi-factor authentication for delete operations. This protects even when IAM credentials are compromised.

Cost optimization with AWS

Egress fees at AWS can be significant during a restore. Downloading 5 TB from S3 costs approximately 450 USD. Factor these costs into your DR budget. Alternatives: AWS Snowball for large data volumes (physical shipment of a storage device) or a local cache tier (e.g., via Veeam) that serves the most common restore requests locally.

Additional options for SMEs

Backblaze B2 with Object Lock

Backblaze B2 has supported Object Lock in Governance and Compliance Mode since 2022. Pricing is 6 USD per TB per month, with no egress fees for the first 3x of the stored volume per month (then 0.01 USD per GB). For many backup scenarios, egress is effectively free.

Backblaze B2 is S3-compatible and works with Veeam, Restic, Duplicati, and most other backup tools. Object Lock setup works analogously to AWS S3.

Linux server with XFS and immutable attribute (without Veeam)

If you do not use Veeam, you can also implement immutability manually on a Linux server. The backup process (e.g., Restic or BorgBackup) writes data to an XFS filesystem. A separate script then sets the immutable attribute with chattr +i on the written files. A cron job removes the attribute after the retention period expires.

This solution is free but requires more manual setup and maintenance. Security depends on how well the Linux server is hardened. If an attacker gains root access to the server, they can remove the immutable attribute.

Choosing retention periods correctly

Choosing the retention period is a balancing act. Too short: the backup is no longer protected before you detect an attack. Too long: you pay for storage you do not need and cannot clean up in Compliance Mode.

Reference values

The average dwell time of an attacker in the network is 10 to 21 days according to current studies. This means an attacker is in your network for an average of two to three weeks before activating the ransomware. Your immutability period should be at least as long as the expected dwell time plus the time you need for detection and recovery.

A pragmatic recommendation: 30 days of immutability for operational backups and 90 days for monthly or quarterly full backups, aligned with the 3-2-1-1-0 principle. This protects you against the typical dwell time and delayed detection.

Calculating costs

Immutable backups cannot be prematurely deleted. Calculate your storage volume conservatively. If you write 50 GB of incremental backups daily and set immutability to 30 days, you need at least 1.5 TB of storage just for the incremental data of the last 30 days. Full backups come on top.

Plan a buffer of 30 to 50% for unexpected data growth. If your immutable storage fills up, no new backups can be written -- and that is a serious problem.

Testing immutable backups

Immutability protects the integrity of stored data but not its quality. An immutable backup containing corrupted data remains corrupted. That is why restore tests, ideally as a bare-metal recovery test, are indispensable even for immutable backups.

Additionally, test the immutability itself: attempt to delete or modify an immutable backup and verify that the action is correctly blocked. This sounds trivial, but misconfigurations do occur. An Object Lock bucket accidentally configured with Governance instead of Compliance Mode provides less protection than assumed.

Document the tests including evidence that immutability works -- in ISMS Lite, backup strategies, retention periods, and test results can be centrally evidenced. An auditor will not only ask whether your backups are immutable but whether you have verified it.

Integration into the backup strategy

Immutable backups are one building block of your backup strategy, not the entire strategy. They address a specific threat (manipulation or deletion of backups by attackers or insiders) but do not replace other aspects such as backup interval (RPO), restore speed (RTO), offsite storage, and regular testing.

The ideal combination for an SME looks like this: local backups on a Veeam Hardened Repository for fast restores (minutes to a few hours) and cloud backups on Wasabi or S3 with Object Lock for offsite protection and long-term immutability. Both copies are immutable; both are regularly tested.

Related articles

• Data Backup per BSI: The 3-2-1-1-0 Principle in Practice
• Creating a Disaster Recovery Plan: From Incident Back to Normal Operations
• Defining RPO and RTO Correctly: How to Find the Right Values
• Testing Bare-Metal Recovery: From Total Failure to a Running Machine
• Ransomware Attack: Immediate Response, Communication, and Recovery