SQL Server 2025 – Immutable Backups Part 1 – Storage

Most people know they need backups. Fewer have thought about what happens when somebody else gets to them first. Ransomware doesn’t start by encrypting your databases. It starts by finding your backups, because once those are gone you have nothing to recover to and every reason to pay. So a backup that anyone with the right credentials can delete is only a partial answer. It protects you from a failed server. It doesn’t protect you from someone who has made their way into your environment.

What you want is a backup that can’t be changed or deleted by anybody until the retention period you set has passed. Not an attacker, not a compromised admin account, and not you on a bad day. SQL Server 2025 makes this a lot more practical. Backup to URL now supports Managed Identity, so you can write backups to immutable Azure Blob Storage without handing out a SAS token or a storage key. There’s no secret sitting in a credential waiting to be found.

This is a three-part walkthrough of how I set it up:

• Part 1 (this post): the storage account and the immutable container
• Part 2: the Managed Identity, Microsoft Entra authentication and outbound connectivity on the SQL Server VM
• Part 3: the private endpoint, permissions, the credential and the first immutable backup

What’s in this environment

These are the names I use throughout the series. Swap in your own as you go.

Component	Name used in this series
SQL Server	SQL Server 2025 on an Azure VM
Resource group	2025-Immutable-Backups
Virtual machine	sql2025
Virtual network	vnet-australiaeast-1
subnet	snet-australiaeast-1
Storage account	2025immutablebackups
Blob endpoint	2025immutablebackups.blob.core.windows.net
Backup container	sqlbackups
Private endpoint	2025-blob-pe
Retention period	7 days
Management tool	SSMS 22

 

You’ll also need enough rights in Azure to create resources and assign roles in the resource group, and someone with Privileged Role Administrator (or Global Administrator) in Microsoft Entra ID for one step in Part 2. It’s worth finding that person before you start rather than halfway through.

SAS token or Managed Identity

When you back up to URL, and specifically to Azure Blob Storage, there are two ways to authenticate:

• A credential using a SAS token
• A Managed Identity, which requires the instance to be either connected to Azure Arc or running on an Azure VM

This series uses a Managed Identity on an Azure VM. A SAS token works, but it’s a secret with an expiry date, and secrets have a habit of ending up somewhere they shouldn’t.

Creating the storage account

In Azure, go to the right resource group. That can be one you already have, or one you create specifically for your SQL Server 2025 immutable backups.

• Choose + Create
• Search the Marketplace for Storage account
• Create a general-purpose v2 storage account

The access tier

Because these are backups, Cool or Cold storage looks like the obvious choice. It might be. It might not. Cheaper storage comes with dearer write operations, and depending on how big your databases are and how often you back them up, those operations can add up to wipe out the saving. Cool and Cold also carry early deletion charges, 30 days for Cool and 90 for Cold, so if your retention is shorter than that you pay for the minimum anyway. Spend five minutes in the Azure pricing calculator before you decide. I’ve gone with Cool for this series. You may well be better off with Hot.

Networking

You have two options:

1. Disable public access and use a private endpoint. This is the one I’d recommend.
2. Leave public access on, but restrict it to selected virtual networks and IP addresses.

We’ll build the private endpoint and tighten the firewall in Part 3.

Data protection

• Turn on soft delete for blobs and pick a retention period. I’d use somewhere between 7 and 14 days. Do the same for soft delete for containers.
• Then **Review + create**.

Putting a lock on the storage account

Immutability protects the blobs. It doesn’t stop somebody deleting the storage account they sit in. A resource lock does.

• Open the new storage account
• Expand Settings and select Locks
• Click Add
• Give the lock a sensible name
• Set the lock type to Delete
• Click OK

 Creating the backup container

The backups get their own container.

• Expand Data storage and select Containers
• Click Add container
• Name it (I’m using sqlbackups)
• Leave the access level as Private
• Click Create

Setting the retention policy

This is the part that actually makes the backups immutable, and it’s where your retention period gets set.

• Open the container
• Expand Settings and select Access policy
• Under Immutable blob storage, click Add policy
• Choose Time-based retention as the policy type
• Set the retention period (I’ve used 7 days)

Seven days suits a walkthrough. It’s probably not right for production. Your retention period should come out of what your business can tolerate, which I wrote about in You want a Ferrari on a Volkswagen budget. It should also allow for corruption you haven’t found yet, which is the subject of The corruption you won’t find until it’s too late. An immutable backup of an already-corrupt database is very well protected and not much use.

Leave it unlocked

Your policy will now show as Unlocked. Leave it that way until you’ve finished every step in this series and tested your backups to this container. Once a policy is locked, it can’t be deleted. The retention period can be extended but never shortened. And the container can’t be deleted while any backup in it is still within retention, so if you get something wrong, you wait it out. That’s exactly what you want in production. It’s not what you want while you’re still working out whether you’ve set it up right.

Where this leaves us

We now have a general-purpose v2 storage account with soft delete on blobs and containers, a delete lock on the account, and a private sqlbackups container with a time-based retention policy that’s still unlocked. None of this does anything yet, because nothing can write to it. In Part 2 we give the SQL Server VM an identity that can.
—
Warwick Rudd is a Microsoft Certified Master and Data Platform MVP, and the founder of SQL Masters Consulting. If you’d like help working out what your recovery requirements are: Backup, Recovery & Data Integrity