Immutable Backups: Your Last Line of Defence Against Ransomware

For decades, the basic principle of backup was simple: take regular copies of your data and store them somewhere safe. If something went wrong — hardware failure, accidental deletion, or a natural disaster — you could restore from backup and carry on. That model assumed the backup itself would remain intact. Modern ransomware has shattered that assumption by actively seeking out and destroying backup files before launching the encryption payload against production systems.

Threat actors commonly compromise a network weeks or even months before triggering encryption. During this dwell time they map the environment, escalate privileges, and identify backup infrastructure. Backup servers running on Windows are especially vulnerable because the same domain credentials that give an attacker lateral movement often grant access to the backup console and its underlying storage. Groups like LockBit and BlackCat have been observed deleting Veeam backup files, wiping shadow copies, and even reformatting NAS appliances before executing the final ransomware payload.

An immutable backup is one that cannot be modified, overwritten, or deleted by anyone — including administrators — until a pre-defined retention period expires. Immutability is enforced at the storage layer rather than the application layer, which means even if an attacker gains full control of the backup software, they cannot tamper with the underlying data. The concept borrows from regulatory archiving, where financial institutions have long been required to store records in a format that prevents alteration.

The two foundational technologies behind immutable storage are WORM (Write Once Read Many) and Object Lock. WORM has its roots in optical media and tape, where data could physically be written only once. Modern implementations enforce WORM semantics in software on disk-based or flash-based storage. Object Lock, popularised by Amazon S3, applies immutability to individual objects in an object store, with each object carrying a retention timestamp that the storage system enforces independently of any IAM policy or root account permission.

WORM storage guarantees that once data is written, it cannot be changed or erased for the duration of the retention period. In an on-premises context, WORM is typically implemented through specialised firmware on NAS or SAN appliances that intercepts delete and overwrite commands at the block or file level. Products from vendors such as NetApp (SnapLock), Dell EMC (Centera / PowerScale SmartLock), and QNAP (WORM folders on QuTS hero) all provide this capability. The retention clock is usually tied to the appliance's internal clock, and administrative interfaces are deliberately restricted to prevent clock manipulation.

Amazon S3 Object Lock offers two modes: Governance and Compliance. In Governance mode, users with specific IAM permissions can override the lock — useful for testing or correcting mistakes. In Compliance mode, no one, not even the root account holder, can delete or shorten the retention period until it expires. Azure Blob Storage provides equivalent functionality through immutable blob policies with legal-hold and time-based retention options. Google Cloud Storage offers a Bucket Lock feature that converts a retention policy into an irreversible lock. For Australian resellers, recommending Compliance-mode locks on a locally hosted S3-compatible target — or on AWS Sydney (ap-southeast-2) — keeps data sovereign while achieving true immutability.

Air-gapped backups and immutable backups are complementary, not competing, strategies. An air-gapped backup is physically or logically disconnected from the network, making it unreachable by any online attacker. Classic examples include LTO tape cartridges stored off-site and removable USB drives locked in a safe. The downside is operational: someone must physically manage the media, rotation schedules introduce human error, and restore times are measured in hours or days rather than minutes. Immutable backups, by contrast, remain online and accessible for rapid restore, but rely on storage-layer enforcement to prevent tampering. The strongest posture combines both — an immutable on-site or cloud copy for fast recovery, plus an air-gapped off-site copy for catastrophic scenarios.

Veeam Backup & Replication has become the de facto standard for virtualisation-centric backup in the SMB and mid-market space, and its immutability features are among the most mature available. The Hardened Linux Repository is Veeam's flagship on-premises immutability mechanism. It uses a minimal Linux server running XFS with the immutable file attribute set on every backup chain file. The Veeam transport service runs as a non-root user, and direct SSH access is disabled after setup, meaning even a compromised Veeam console cannot delete or modify backup files during the immutability window. For cloud targets, Veeam natively supports S3 Object Lock on AWS, Wasabi, and other S3-compatible providers, applying Compliance or Governance mode locks automatically at write time.

When configuring Veeam immutability for a client, set the immutability period to at least seven days beyond your longest backup chain. This ensures that even if an attacker sits dormant for a full backup cycle, the oldest restore point remains protected. Use the Veeam Configuration Backup feature to store an encrypted copy of the Veeam configuration database on a separate immutable target so that the backup infrastructure itself can be rebuilt in a disaster.

QNAP NAS appliances running QuTS hero (the ZFS-based operating system) support WORM folders that enforce file-level immutability. Once a shared folder is configured in WORM mode, files written to it cannot be modified or deleted until the retention period elapses. This is enforced at the filesystem layer, beneath the SMB/NFS protocol stack, so it is transparent to the backup application writing data to the share. For resellers deploying Veeam in SMB environments, a QNAP NAS with WORM folders provides an affordable on-premises immutable target that does not require a dedicated Linux server. Pair the NAS with Veeam's NAS backup proxy for optimal throughput and reduced CPU load on the NAS itself.

For organisations that want off-site immutability without managing physical media, cloud object storage with Object Lock is the most practical solution. AWS S3 with Object Lock in Compliance mode is the gold standard, supported natively by Veeam, Commvault, Rubrik, and most other enterprise backup products. Wasabi Hot Cloud Storage offers an S3-compatible alternative with immutability support and no egress fees, which can significantly reduce costs for restores and DR testing. Backblaze B2 also supports Object Lock and is priced competitively for archival workloads. Australian resellers should verify that the chosen provider has a data centre in Australia or New Zealand if data sovereignty is a client requirement — AWS Sydney and Wasabi Sydney both qualify.

Immutability without a well-designed retention policy can lead to runaway storage costs or, worse, gaps in protection. The retention period must account for the realistic dwell time of a ransomware attacker — the average is now over 20 days — plus the time needed to detect an incident and begin recovery. A minimum of 30 days of immutable retention is a sensible baseline for most SMB clients. Organisations subject to regulatory requirements may need 12 months or more. Structure retention in tiers: daily backups immutable for 30 days, weekly backups immutable for 90 days, and monthly backups immutable for one year. This balances storage consumption with recovery flexibility.

First, follow the 3-2-1-1-0 rule: three copies of data, on two different media types, with one copy off-site, one copy immutable or air-gapped, and zero errors verified through automated restore testing. Second, isolate the credentials used to manage immutable storage from the backup server's service account. If the backup server is compromised, the attacker should not be able to administer the storage target. Third, enable MFA on all cloud storage accounts and restrict Object Lock configuration changes to a break-glass account with hardware MFA. Fourth, test restores regularly — immutability guarantees the data is there, but only a successful test restore proves it is usable.