Offline vs. Immutable Backups for Azure SQL Database (General Guidance)

Microsoft

Feb 27, 2026

Security and compliance teams often ask for “offline backups” and “immutable backups” as part of ransomware resilience, audit readiness, and recovery strategy. In Azure SQL Database, these terms map to different capabilities and operating models.

Immutable backups (WORM) are supported natively for Long-Term Retention (LTR) backups in Azure SQL Database, using time-based and legal hold immutability modes.
Offline backups (customer-controlled copies stored under your own governance) typically require a customer-managed export/copy process, because platform-managed backups (including LTR) are retained within Azure’s managed backup system.

This post explains the difference, what’s supported today, and practical design considerations to help you choose the right approach.

1) Start by clarifying the requirement: “offline” vs. “immutable”

What “immutable backup” means in practice

An immutable backup is stored in a Write Once, Read Many (WORM) state—non-modifiable and non-erasable for a user-defined retention period, providing protection against accidental or malicious deletion or modification (including by privileged administrators).

Azure SQL Database supports backup immutability for LTR backups, written to Azure immutable storage.

What “offline backup” usually implies

“Offline” is commonly used to mean customer-controlled copies stored separately (often under separate access controls and retention governance). Azure SQL Database’s built-in backups are platform-managed; if your policy explicitly requires “offline/customer-controlled” artifacts, you typically implement an export/copy process in addition to platform-managed backups.

2) What Azure SQL Database supports natively: LTR + immutability (WORM)

Long-Term Retention (LTR) basics

LTR exists to retain backups beyond the short-term retention window. It relies on the full database backups automatically created by the Azure SQL service and stores specified full backups in redundant Azure Blob storage with a retention policy of up to 10 years.

If an LTR policy is configured, automated backups are copied to different blobs for long-term storage. The copy process is a background job that has no performance impact on the database workload.

Immutability modes for LTR backups

Azure SQL Database LTR backups support both:

Time-based immutability (policy-driven) — enabled at the LTR policy level; once enabled and locked, new LTR backups taken from that point forward inherit the settings and remain immutable until the retention period ends.
Legal hold immutability — enabled/disabled on a specific existing backup, independent of time-based settings; backups remain immutable until legal hold is explicitly removed.

3) Key operational constraint to plan for (important!)

Microsoft documentation notes that when you configure immutability for an Azure SQL Database with an LTR policy, the associated logical server can be blocked from deletion until all immutable backups are removed (time-based and/or legal hold).

This is a big lifecycle-management consideration (especially for non-prod environments or automation that deletes/recreates servers).

4) Cost model: what changes when you enable immutability?

According to the documentation, there’s no additional cost for enabling immutability on LTR backups; however, backup storage charges continue to accrue as long as the immutable backup file exists, even if it’s past the configured LTR expiration date (while it remains immutable).

For broader spend governance, Microsoft recommends using Cost Management features to set budgets, monitor costs, and review forecasted costs and trends.

Practical interpretation (design guidance): immutability changes the delete/modify behavior and therefore can affect how long backups remain stored, which can influence total backup storage cost over time. This aligns with the “charges continue to accrue as long as the immutable backup file exists” note.

5) How to enable LTR and immutability (high-level, supported steps)

Configure LTR retention (Azure portal)

Microsoft’s guidance for LTR policy management includes navigate to your server → Backups → Retention policies, select the database(s), and set weekly/monthly/yearly retention periods (or 0 for none).

Enable time-based immutability (Azure portal)

The time-based immutability article describes enabling it through the server’s Backups → Retention Policies → Configure Policies, then checking Enable time-based immutability policy and lock the time-based immutable policy (backups aren’t immutable until locked).

Note: The documentation also highlights that only backups taken after enabling and locking time-based immutability become immutable; for existing backups, use legal hold immutability instead.

6) If you truly need “offline” (customer-controlled) backups

Azure SQL Database platform-managed backups (including LTR) are retained within Azure’s managed backup system. If your requirement explicitly mandates customer-controlled “offline” copies, you typically implement a customer-managed export/backup approach and store exported artifacts under your own governance and retention controls.

This is commonly positioned as complementary to platform-managed backups—use platform features for operational recovery plus LTR immutability for tamper-proof retention and add customer-managed exports only if “offline custody” is a strict requirement.

7) Compliance notes you can cite internally

The immutability documentation states Azure SQL Database backup immutability helps meet stringent regulatory requirements (examples listed include SEC Rule 17a-4(f), FINRA Rule 4511(c), and CFTC Rule 1.31(c)-(d)). It also notes that the Cohasset report is available in the Microsoft Service Trust Center, and you can request a letter of attestation via Azure Support.