Ransomware is a financial calculation. Attackers encrypt your data, destroy your recovery options, and wait for you to pay. The calculation breaks the moment you can recover without them. Immutable backup storage is the mechanism that breaks it.
How Attackers Think About Your Backups
Ransomware groups that target enterprise environments do not detonate immediately. They spend days or weeks inside your network before encryption begins. During that time, they are mapping your environment with one specific goal: find the backup locations and destroy them before you can use them.
Network shares are mapped and encrypted. Backup server agents are targeted by name — Veeam, Commvault, Backup Exec. Backup jobs are monitored, and the destination storage is accessed during the backup window. By the time encryption begins, your most recent backup may already be ciphertext.
Immutable storage breaks this pattern. If the backup destination cannot be modified or deleted — by anyone, including the attacker with full domain access — the recovery path survives.
What Immutability Actually Means
Immutable storage is WORM: Write Once, Read Many. Once data is written and locked, it cannot be modified, overwritten, or deleted for the duration of the lock period. The key distinction is in the lock modes.
Governance mode allows users with specific IAM permissions to override the lock. It is useful for managing retention, but it is not true immutability from an attacker’s perspective — a compromised account with sufficient permissions can still delete objects.
Compliance mode cannot be overridden by anyone — not the account owner, not the storage administrator, not the cloud provider support desk. An object locked in compliance mode cannot be deleted until the lock period expires. This is the mode that changes the ransomware math.
The three platforms with enterprise-grade Object Lock support are Azure Blob Storage immutability policies, AWS S3 Object Lock, and MinIO (on-premises or self-hosted S3-compatible). All three support compliance mode. All three work with SQL Server native backup.
How SQL Server Backups Go to Immutable Storage
SQL Server has supported backup directly to Azure Blob Storage since SQL Server 2012. The syntax is straightforward:
BACKUP DATABASE [YourDatabase]
TO URL = 'https://youraccount.blob.core.windows.net/backups/YourDatabase_full.bak'
WITH COMPRESSION, STATS = 10;Configure the container-level immutability policy before the first backup lands. Set the lock period to match your retention requirement — 30 days, 90 days, whatever your recovery and compliance requirements dictate. Once the policy is applied and locked, every object written to that container is protected.
AWS S3 Object Lock works the same way with a credential-based URL target. MinIO is the on-premises option for organizations that cannot or will not use public cloud storage — it runs in your datacenter, supports the S3 API, and implements full Object Lock including compliance mode.
If your organization already runs enterprise SAN or NAS infrastructure, check what your existing vendor offers before building something new. NetApp ONTAP SnapLock Compliance mode locks snapshots for a defined retention period — not even ONTAP administrators or NetApp support can delete them before the clock expires. Pure Storage SafeMode protects snapshots with multi-step verification and multi-factor authentication, even if the storage API is compromised. Dell PowerProtect and HPE StoreOnce both include immutability features in their current product lines. The capability may already be sitting in infrastructure you own — but each has its own licensing model and configuration requirements.
Before committing to any of these options, three things need to be evaluated.
File size and transfer speed. Cloud options transfer backups over your WAN connection. A multi-terabyte SQL Server database can take longer to move than your backup window allows. Measure your database sizes against available bandwidth before assuming cloud immutable storage fits your environment.
Isolation. Object Lock, WORM, and vendor immutability features all operate at the API or storage layer. An attacker with operating-system access to a MinIO server, or management-plane access to a storage array’s admin interface, can potentially bypass those protections entirely. Whether it is a Linux server running MinIO, a NetApp controller, or a Pure Storage array — the management path to that system needs to be isolated from any identity a compromised domain account can reach. The storage is only as protected as the path to its admin plane.
Cost. Enterprise SAN immutability features often require separate licensing. Cloud storage carries per-GB and egress costs that scale with data volume. MinIO is open source but requires hardware and operational overhead. None of these is prohibitive — but the cost model needs to be understood before the architecture decision is made.
Every option works in the right context. None of them works in the wrong one.
What Attackers Do When They Find Immutable Storage
They cannot encrypt it. They cannot delete it. What they can do is attempt to exfiltrate it — copy your backup files and threaten to publish your data. Immutability does not prevent exfiltration. This is why immutable backups are one layer of a defense-in-depth strategy, not the only layer.
The combination that closes both doors is immutable backup storage plus network segmentation that prevents the backup destination from being reachable at all from a compromised machine. If they cannot reach the storage, they cannot exfiltrate from it. If they somehow reach it, compliance-mode Object Lock prevents deletion.
The Gap Immutability Does Not Cover
Immutability protects the backup file. It does not protect your TDE encryption certificates.
If your databases use Transparent Data Encryption, the certificate that unlocks the encrypted pages lives in the master database — not in the backup file. If that certificate is lost or encrypted, SQL Server will restore the database file successfully and then refuse to open it. The data exists. The key is gone.
A complete ransomware recovery posture requires both: immutable storage for data backups, and a separate certificate backup stored in a location the ransomware cannot reach — a hardware vault, an offline encrypted copy, or a secrets management system like Azure Key Vault or OpenBao.
Certificate storage is not enough on its own. SQL Server Audit must cover certificate and TDE state changes: CREATE CERTIFICATE, ALTER CERTIFICATE, DROP CERTIFICATE, and ALTER DATABASE … SET ENCRYPTION ON/OFF. Every one of those events should generate an alert. An attacker who rotates a TDE certificate or silently enables TDE on a database that was previously unencrypted leaves a record in the audit log — but only if you are watching for it. Passive logging without alerting is not a control. It is a record of what happened after you lost.
Know Before You Build
The right choice between cloud object storage, on-premises MinIO, enterprise SAN immutability, and purpose-built appliances depends on your database sizes, existing infrastructure, network architecture, and isolation requirements. Getting the architecture wrong produces a false sense of protection — exactly the kind this post is about.
The SQL Server Security Discovery Call is where we work through your environment before you start building. Database sizes, existing infrastructure, isolation requirements, cost constraints — and a backup architecture designed to work the same way across every instance you manage.