Azure SQL PITR Backup Immutability Preview: Full Retention Protection With a Permanent Lock

Ransomware crews like to delete backups before they encrypt anything, so this is a real defensive gain. It also comes with a one-way switch: once you turn the lock on, you cannot turn it off. Read the fine print before you click.

What changes in this preview​

Microsoft's Learn documentation describes two levels of PITR backup protection:

• Default immutability. Azure SQL automatically protects up to the most recent seven days of PITR backups. You don't configure anything and you don't pay extra for it.
• Locked immutability aligned with PITR retention. This is the new preview option. You can lock immutability to the database's configured PITR retention period, including periods longer than seven days.

Microsoft's own example uses 35 days of PITR retention. Without the lock, only up to the latest seven days are immutable. With the lock, immutability covers all 35 days.

Neither option needs a storage account or any Azure Storage immutability policies. Both are built into the managed backup service, and existing backup and restore workflows keep working.

Summary: Default seven-day protection is already there for supported databases. The preview lets you stretch immutability across your whole PITR window, and the cost of that is a permanent commitment.

How we got here​

A year ago this wasn't possible at all. In a Microsoft Tech Community support post from late 2025, an engineer answered a customer bluntly: short-term retention (PITR) backups (1–35 days) do not support immutability. At that point, immutability was available only for long-term retention (LTR) backups in Azure SQL Database, and the suggested workarounds included RBAC, Azure Policy and regularly exporting database copies to your own Azure Storage with immutability enabled.

About three months ago Microsoft closed the first part of that gap. On the Azure SQL blog it announced General Availability of automatic backup immutability up to the most recent 7 days of point-in-time restore (PITR) backups in Azure SQL Database and Azure SQL Managed Instance, at no additional cost. That protection applies regardless of your configured PITR retention period.

This preview is the second part: retention and immutability can now cover the same window.

There are signs in the tooling too. A GitHub pull request in the Azure PowerShell repository adds point-in-time backup immutability support to Azure SQL Database and Managed Instance short-term retention cmdlets, and it updates the SQL SDK to API version 2026-08-01-preview.

Retention and immutability are separate controls​

This is the point most likely to trip people up. PITR retention sets how long restore points are kept. Immutability sets how long those backups are protected from being changed or deleted. Microsoft describes the new lock as the thing that lines the two up.

What that means in practice:

• If you raise PITR retention to 35 days without the lock, you still get only up to seven days of immutable backups.
• Raising retention does not bring back backups that have already expired. Microsoft says the available restore history grows over time as the service keeps backups longer.

So if you raise retention from 7 to 35 days and enable the lock today, you won't have 35 days of immutable restore points tomorrow. You'll build up to that over the following weeks.

The lock is permanent​

Microsoft is blunt in its documentation: once you enable the lock, you can't disable it and you can't reduce the configured PITR retention period. You can only increase retention, up to the maximum your database supports.

Microsoft's example: lock a database at 14 days, and you can later raise it to 35 days. After that you can't drop it to seven days, and you can't go back to 14 either.

Three more points from the documentation:

• There is no unlock operation. The CLI parameter accepts a Boolean, but passing false (or $false in PowerShell) does not reverse a lock that's already on.
• It is not a delete lock. You can still delete the database. Its retained backups stay immutable for their applicable period, and deleting the database does not start a new 35-day period for each backup.
• Don't test it on a database you care about. Microsoft warns against enabling the setting as a temporary test on any database whose retention you might need to reduce.

This permanence is intentional. A ransomware operator holding stolen admin credentials could switch off a lock that can be reversed. That's why Azure Backup's immutable vaults work the same way: locking the Immutable vault setting makes it irreversible to prevent any malicious actors from disabling immutability and deleting backups.

Summary: A permanent lock is what makes the protection worth having, and it's also what makes it risky to enable carelessly. Decide on your retention period before you lock it.

Check eligibility first​

Not every Azure SQL configuration is supported. Microsoft Learn lists these limitations:

The Hyperscale limitation matters most. If you have a migration to Hyperscale planned, factor in that the immutability guarantee will disappear when you move.

Before you enable it​

Microsoft's planning checklist comes down to five things:

1. Pick a PITR retention period that meets your recovery, governance and data retention requirements.
2. Make sure you can keep backups for that long without needing to shorten it later.
3. Review backup storage costs. Default immutability is free, but backup retention and storage are billed at normal service pricing.
4. Confirm that your service tier, and your update policy if you're on Managed Instance, supports immutability.
5. Use an account with permission to update the database's short-term backup retention policy.

If you want to lock your current retention without increasing it, Microsoft says to supply the database's existing retention value in place of the 35-day example.

How to enable the lock​

Azure portal (both services)​

1. Open the SQL logical server (for Azure SQL Database) or the managed instance that contains the database.
2. Select Backups, then Retention policies.
3. Select the database.
4. Select Configure policies.
5. Under Point-in-time restore, set the number of retention days.
6. Select Lock immutability to configured PITR backup retention period.
7. Read the permanent-lock warning, apply the changes and confirm if prompted.

Azure CLI​

You need an Azure CLI version that supports --lock-immutability. Sign in and select the right subscription first.

Azure SQL Database:

az sql db str-policy set --resource-group "myResourceGroup" --server "mySqlServer" --name "myDatabase" --retention-days 35 --lock-immutability true

Azure SQL Managed Instance:

az sql midb short-term-retention-policy set --resource-group "myResourceGroup" --mi "myManagedInstance" --name "myDatabase" --retention-days 35 --lock-immutability true

Azure PowerShell​

You need an Az.Sql module version that supports -LockImmutability.

Set-AzSqlDatabaseBackupShortTermRetentionPolicy `
  -ResourceGroupName "myResourceGroup" `
  -ServerName "mySqlServer" `
  -DatabaseName "myDatabase" `
  -RetentionDays 35 `
  -LockImmutability $true

For Managed Instance, use Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy with -InstanceName in place of -ServerName.

A practical note: the PowerShell pull request mentioned above says that before the fix, the SQL Database cmdlet rejects valid lock-only updates unless another retention setting is supplied. If a lock-only command fails on an older module, update Az.Sql or pass -RetentionDays explicitly before you start troubleshooting anything else.

Verify the change​

In the portal, go back to Backups > Retention policies, select the database and check Configure policies. From the command line:

• Azure SQL Database: az sql db str-policy show or Get-AzSqlDatabaseBackupShortTermRetentionPolicy
• Azure SQL Managed Instance: az sql midb short-term-retention-policy show or Get-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy

How it compares with LTR immutability​

Long-term retention immutability is a different feature, and it works differently. According to Microsoft's LTR documentation, LTR backups can use time-based immutability enabled at the policy level and also legal holds, and time-based immutability has an unlocked state that you can lock or disable. That documentation also warns that backup storage charges continue to accrue as long as the immutable backup file exists, even if its past the configured LTR expiration date.

The new PITR lock is simpler. It has one switch, no unlocked trial state, and no legal holds. Microsoft also says it doesn't keep backups indefinitely: they still expire under the applicable retention policy.

Compliance: helpful, not a guarantee​

Azure SQL enforces backup immutability using Azure Storage's immutable storage capabilities. Microsoft notes that those capabilities have been validated for scenarios including SEC Rule 17a-4(f), CFTC Rule 1.31(d) and FINRA record-retention requirements. It also states that locking PITR immutability does not, on its own, make you compliant with any particular regulation. Your legal and compliance teams still need to sign off.

Analysis: who should turn this on?​

This is my own assessment, based on general industry practice rather than anything Microsoft has said.

• Good fit: Production databases with a stable, agreed recovery window, especially in regulated industries and in organizations whose ransomware playbook assumes admin credentials may be compromised.
• Wait for now: Databases heading to Hyperscale, Managed Instances still on the SQL Server 2022 update policy, and anything where retention is still being debated or tied to cost reviews.
• Remember the preview status: Azure's own definition of preview is non-production use and testing. Combine that with a permanent lock and the sensible path is to pilot on non-critical databases first.

One more caution: immutable backups don't replace good identity hygiene. An attacker with admin access can still delete the database. What they can't do is wipe the PITR backups you'd use to recover it, and that difference matters a lot during an incident.

Bottom line: Azure SQL now offers immutability for the whole PITR window, which closes a gap that many security teams had already identified. Decide on your retention period first, check your tier and update policy, and then enable the lock.