Immutability: A Powerful Shield Against Ransomware in SQL Environments

In today’s digital landscape, ransomware attacks are among the most disruptive and costly threats organizations face. These attacks often target critical data—encrypting or deleting it to extort payment. One of the most effective strategies to mitigate this risk is immutability.

🧱 What Is Immutability?

Immutability means that once data is written, it cannot be altered or deleted for a defined period. This concept is widely used in software engineering (e.g., immutable objects in programming) but has become a cornerstone in data protection and cybersecurity.

In storage and backup systems, immutability ensures that even if an attacker gains access, they cannot tamper with or erase the protected data.

🛡️ How Immutability Protects Against Ransomware

Ransomware typically works by:

1. Gaining access to systems.
2. Encrypting or deleting data.
3. Demanding ransom for restoration.

With immutable backups or storage:

• Encrypted or deleted data can be restored from a clean, untouchable copy.
• Attackers cannot modify or delete immutable data, even with elevated privileges.
• Organizations can recover quickly without paying the ransom.

Immutability with Azure storage

Azure storage supports immutability for blob storage and is compliant with industry requirements in this space.

🗃️Using Azure immutable storage for SQL Server backups

SQL Server backups can be written to Azure storage using the BACKUP TO URL  T-SQL command. However, writing backups to immutable storage is not supported in the current versions of SQL Server 2022 and prior. This is because of the way SQL Server writes the backups to the .bak file. It first creates the .bak file with zeros and then updates it with the data. By definition of immutability, the file once written cannot be edited or deleted. Hence, the current two step backup process does not allow writing to Azure immutable storage.

You will see the following error when you attempt to write a backup to immutable storage with SQL Server 2022.

 

 

With SQL Server 2025 CTP 2.1 Preview, instead of the current two-steps to create and write the .bak file, everything is done in one step. This change only applies when writing to Azure blob storage, specifically when backing to BlockBlobs, and does not impact other targets such as disk or S3-compatible object storage.

 

Immutability in action

Following is an end-to-end scenario of configuring immutability for Azure storage container and creating a native SQL backup file to it using SQL Server 2025 CTP 2.1 Preview.

Configure immutability for Azure storage container

1. Navigate to your storage account and then to the desired container under Data storage

 

 

2. Select the More button on the right for the desired container and select “Access policy”

 

 

 

3. Click on Add policy

 

 

 

4. Select Time-based retention from the Policy type

 

5. Enter a number for the retention. It is advised to choose a very small number such as 1-2 days for testing purposes.
6. Leave the “Enable version-level immutability” unchecked. For testing purposes, we highly recommend not to Lock the immutable policy as that will prevent you from making any modifications.
7. Leave the default of “Allow protected append writes to” to None
8. Select Save
9. After saving, go back to More > Access policy on the storage container to verify immutability. You should see a container scoped, time-based immutable policy with the configured retention period.

 

10. Retrieve the SAS token – from the storage container, select More, and then select “Generate SAS” with relevant Permissions specified.

For example:

11. From the generated SAS token, copy the token

Switch to SQL Server Management Studio

12. Connect to the SQL Server 2025 CTP 2.1 Preview instance
13. In a New Query window, create the Credential as follows

IF NOT EXISTS (SELECT *
              FROM sys.credentials
              WHERE name = 'https://dnstorage1.blob.core.windows.net/immcontainer')
CREATE CREDENTIAL [https://dnstorage1.blob.core.windows.net/immcontainer]
        WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<token>';

14. Enable the Trace flag to switch to the single write workflow

DBCC TRACEON(3012,-1)

15. Perform a database backup as follows:

BACKUP DATABASE WideWorldImporters
TO URL = 'https://dnstorage1.blob.core.windows.net/immcontainer/WideWorldImporters.bak';
GO

The backup should succeed, as follows:

 

Some details to note:

1. Formerly one could see a 0-byte blob when the backup process starts. However, in the new workflow the blob would not be visible under your storage account in the Azure portal until the backup has completed successfully.
2. If the backup fails mid-way, you may not see any blob in the container in the Azure portal, but it may exist in an uncommitted state. If you retry without specifying the “FORMAT” option, the backup statement may fail indicating that a blob already exists at the specified path, and you should use the “WITH FORMAT” option. If you retry using the “WITH FORMAT” option, the backup workflow will be able to proceed.
3. Once a backup has been successfully completed, use of “FORMAT” option becomes inconsequential till the point the backup is protected by the immutable policy as nobody can delete/overwrite the blob.
4. The example used a time-based retention policy but the same result can be achieved using Legal Hold for immutability. Azure immutable storage has more details on time-based vs legal hold types of immutability.

Alternatively, you can also follow the instructions at Code examples to create a Shared Access Signature, create a credential and perform a full database backup.

 

Verifying immutability

Once the backup is created, you can verify the immutability of the backup by attempting to modify/delete the backup.

Modifying the file by attempting to overwrite to the same file:

I attempted to re-run the same command to overwrite the backup file, and I get the following error:

 

Adding WITH FORMAT:

 

 

Delete the immutable backup:

From Azure storage container, I tried to delete the backup file I just created:

 

 

As you can see, once written, the backup files cannot be modified or deleted until the configured retention period expires.

 

🔚 Final Thoughts

Immutability is not just a buzzword—it's a critical defense mechanism in the fight against ransomware. For SQL databases, where data integrity and availability are paramount, implementing immutable backups and storage can mean the difference between a minor incident and a catastrophic loss.

By embracing immutability, organizations can ensure that their most valuable data remains safe, recoverable, and resilient—no matter what threats come their way.