In this blog post Immutable Azure SQL Backups for Practical Ransomware Recovery we will explain how to protect critical database backups from ransomware, compromised administrators and accidental deletion.
Many CIOs are told, “Azure handles the backups.” That may be true, but it does not answer the question that matters during an attack: can the business restore a clean, usable database within an acceptable timeframe?
Immutable backups help close that gap. An immutable backup is locked so it cannot be changed or deleted during its retention period, even if someone gains powerful administrative access.
What immutable Azure SQL backups actually do
Azure SQL Database is Microsoft’s managed cloud database service. Microsoft handles the underlying servers, maintenance and routine backup processes, while your organisation remains responsible for setting appropriate retention, recovery and security policies.
Immutability uses “write once, read many” storage. In plain English, Azure can create and read the backup, but nobody can overwrite or erase it before the agreed retention period ends.
This is different from simply keeping a backup for a long time. A seven-year backup that an attacker can delete today is not a seven-year recovery option.
Our earlier blueprint for immutable Azure SQL backups explains the core controls. Here, we will focus on turning those controls into a practical recovery design that a CIO can govern, fund and test.
Why ordinary backups may not survive ransomware
Modern ransomware attacks do not always begin by encrypting files. Attackers may first steal an administrator’s identity, study the cloud environment and quietly weaken recovery controls.
They can attempt to reduce retention periods, delete recovery points or remove entire resources. AI-assisted attacks can make this process faster, as discussed in our article on AI-driven cyberattacks against Azure environments.
The result is a dangerous situation: the dashboard says backups were successful, but the backups needed after the attack are gone or too recent to provide a clean restore point.
A practical four-layer recovery design
1. Protect recent recovery points automatically
Azure SQL Database and Azure SQL Managed Instance now apply immutability protection to up to the most recent seven days of automatic point-in-time recovery backups. Point-in-time recovery means restoring the database to a selected moment before corruption or deletion occurred.
This protection is enabled by Microsoft as part of the managed service and does not require a separate storage account. It provides a useful safety net for recent incidents without adding configuration overhead or backup charges.
However, seven days may not be enough. Ransomware can remain undetected for weeks, and data corruption may not become visible until a month-end process or customer audit.
2. Add locked long-term retention
For Azure SQL Database, long-term retention can preserve selected full backups for up to ten years. These copies can be kept weekly, monthly or yearly, depending on business and compliance requirements.
Time-based immutability should be enabled and locked for critical databases. Once protected, new long-term backups cannot be modified or deleted until their retention period expires, including by a privileged administrator.
A policy might keep weekly backups for eight weeks, monthly backups for twelve months and yearly backups for seven years. That is only an example; retaining everything indefinitely creates unnecessary cost and can complicate privacy obligations.
The following Azure command illustrates the configuration pattern. It should be tested and approved through change control before use because locked retention has lasting cost and governance consequences.
az sql db ltr-policy set \
--resource-group Production-RG \
--server company-sql-server \
--name finance-database \
--weekly-retention "P8W" \
--monthly-retention "P12M" \
--yearly-retention "P7Y" \
--week-of-year 1 \
--tb-immutability Enabled \
--tb-immutability-mode LockedOnly backups created after the policy is enabled and locked receive the time-based protection. Existing backups need separate assessment rather than being assumed to be immutable.
3. Plan for regional failure as well as ransomware
Immutability prevents deletion, but it does not automatically solve every outage scenario. The backup storage redundancy setting determines whether copies remain local to one Azure region or are replicated elsewhere.
Business-critical databases should be assessed for geo-redundant backup storage, which keeps copies in a paired Azure region. This can support recovery when an entire region is unavailable, although the organisation must still understand possible data delay and restoration time.
Do not confuse this with availability zones, which help applications continue operating through a data centre failure inside one region. Our guide to zone-resilient Azure SQL Managed Instance workloads covers that availability layer in more detail.
Availability keeps a service running. Backups help you recover after data has been damaged. Most important systems need both.
4. Separate backup control from daily administration
Immutability is strongest when it is combined with identity separation. The same account used for routine database management should not have unrestricted power over backup policies, security monitoring and recovery approvals.
- Require multi-factor authentication for all administrators.
- Use separate administrator accounts instead of everyday email accounts.
- Grant access only when it is needed and remove standing privileges.
- Alert on retention changes, backup failures and unusual administrative activity.
- Require a second person to approve major recovery-policy changes.
These controls reduce the chance that one stolen identity can compromise production systems and their recovery path at the same time.
The limitation CIOs need to know about
Azure SQL Database and Azure SQL Managed Instance do not currently have identical long-term immutability options. Managed Instance receives the automatic protection for recent recovery points, but its native long-term retention backups cannot currently be locked in the same way as Azure SQL Database backups.
Organisations using Managed Instance may need a separate copy-only backup written to an immutable Azure Storage location. This adds design and operational work, so confirm the database platform before approving the recovery architecture.
A 200-person business recovery scenario
Consider a 200-person distributor whose ordering, inventory and finance applications depend on one Azure SQL database. The board accepts losing no more than 30 minutes of transactions and wants core ordering restored within four hours.
The design retains recent point-in-time backups, creates locked weekly and monthly recovery points, and uses geo-redundant storage. Administrative access is separated, and the recovery team restores the database into an isolated test environment every quarter.
During testing, the database itself restores successfully in 70 minutes. However, the application cannot connect because a security key and a network rule were missing from the recovery procedure.
That test provides the real business value. The company identifies the dependency before an emergency, updates the runbook and demonstrates that recovery is more than a green backup status.
Test recovery rather than trusting the policy
The Essential 8, the Australian government’s cybersecurity framework that many organisations use to reduce common security risks, includes regular backups. Australian Signals Directorate guidance also expects restoration to be tested as part of disaster recovery exercises.
For critical Azure SQL systems, each test should confirm:
- A suitable immutable recovery point exists.
- Authorised staff can access it during an incident.
- The database can be restored as a new database.
- Applications, identities, encryption keys and network settings can be reconnected.
- The measured recovery time and data loss meet agreed business targets.
- Evidence is retained for executives, auditors and insurers.
Immutability supports Essential 8 goals, but it does not prove compliance by itself. Governance, access controls, documentation and successful recovery tests are equally important.
Balance recovery protection with cost
Locked retention should be based on business value rather than fear. Classify databases by impact, then give customer, finance and operational systems stronger protection than temporary reporting or development databases.
This keeps the design affordable without weakening critical recovery. Our guides to reducing Azure backup costs safely and controlling Azure storage costs provide practical ways to manage retention spending.
Make recovery a business capability
A strong ransomware-recovery design combines recent immutable backups, locked long-term copies, appropriate regional redundancy, separated administration and regular restoration testing. The outcome is not simply better technology; it is less downtime, lower financial exposure and clearer evidence for boards, insurers and auditors.
CloudProInc brings more than 20 years of enterprise IT experience as a Microsoft Partner and Wiz Security Integrator. Our Melbourne-based team works directly with organisations across Australia and internationally to design practical Azure, Microsoft 365 and cybersecurity controls without the layers of a large, faceless provider.
If you are not sure whether your Azure SQL backups would survive a compromised administrator or a serious ransomware attack, we are happy to review the current setup and identify the gaps — no strings attached.