In this blog post Azure Resilience Checklist for Australian Mid-Market CIOs in 2026 we will explain what Azure Site Recovery, restore points and immutable backups now protect, where their coverage stops, and how to combine them into a recovery plan the business can trust.
Many organisations have Azure backups and still cannot answer a basic question: if a critical system failed or ransomware struck this afternoon, how long would recovery take? The problem is rarely a complete lack of technology. It is usually unclear recovery priorities, overlapping tools and backups that have never been properly tested.
Three resilience technologies with three different jobs
Azure resilience becomes easier to understand when you separate continuity, recovery and protection. Site Recovery keeps systems available, restore points let you return to an earlier state, and immutable backups preserve recovery data against deletion or tampering.
These technologies complement one another. None should automatically be treated as a replacement for the others.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingAzure Site Recovery keeps important systems running
Azure Site Recovery continuously copies supported virtual machines to a secondary location. If the primary environment becomes unavailable, the organisation can start replicated systems in Azure or another configured Azure region.
It supports planned failovers, emergency failovers, non-disruptive tests and failback when the original environment is ready. Recovery plans can also control the order in which systems start, helping databases come online before the applications that depend on them.
Site Recovery for Azure Local is now generally available for production workloads. Azure Local is Microsoft’s platform for running Azure-managed infrastructure in your own facilities. The simplified setup is covered in our guide to what IT teams should do after Azure Site Recovery for Azure Local became generally available.
The important limitation is that replication is not historical protection. If corrupted or encrypted data is replicated, Site Recovery may faithfully copy the problem. It improves availability, but it does not replace clean backups.
Restore points give IT teams a practical rewind option
An Azure virtual machine restore point captures the machine’s configuration and point-in-time copies of its attached disks. Restore points are incremental, meaning later copies generally store changes rather than repeatedly copying every disk in full.
Application-consistent restore points prepare supported applications before taking the copy, reducing the risk of incomplete transactions. Crash-consistent restore points capture the disks in a state similar to what would remain after a sudden power loss.
Restore points can help rebuild a machine, recover disks or return an application to a known state. Azure Backup also provides recovery points in a fast snapshot tier and a longer-term vault tier, allowing faster operational recovery alongside more durable retention.
Cross-region copying of virtual machine restore points can extend protection against a regional outage, but this capability still carries preview limitations. It should not become a production dependency without checking workload support, encryption, networking, copy completion and recovery procedures.
Immutable backups protect the last clean copy
An immutable Azure Backup vault blocks operations that could delete recovery points or shorten their retention. When immutability is locked, it cannot simply be switched off by an administrator or an attacker using a compromised account.
Locked immutability now applies across the workloads protected by Azure Backup and can be used with both Recovery Services vaults and Backup vaults. Microsoft is also introducing write-once, read-many storage behind this protection, while service-enforced immutability remains in place where that storage backing is not yet available.
This matters because modern ransomware operators often target backups before encrypting production systems. Our article on immutable Azure backups for ransomware resilience explains the control in more depth.
The practical Azure resilience checklist
1. Start with business recovery targets
List the systems that generate revenue, support customers, process payroll or keep operations moving. For each one, define the recovery time objective, which is how quickly it must return, and the recovery point objective, which is how much recent data the business can afford to lose.
A blanket four-hour target sounds simple but often wastes money on minor systems while leaving critical dependencies overlooked.
2. Match protection to the business consequence
- Use Site Recovery where extended downtime would cause serious financial or operational harm.
- Use restore points where fast rollback, disk recovery or machine reconstruction is required.
- Use immutable backups wherever losing historical recovery data would create an unacceptable ransomware, legal or compliance risk.
Most important workloads need all three, configured for different failure scenarios.
3. Include the dependencies around each server
Recovering a virtual machine is not enough if identity, networking, domain name services, certificates or database connections are missing. Document the full business service rather than protecting servers as isolated items.
This is where recovery plans become valuable. They convert a collection of protected machines into an ordered business recovery process.
4. Lock immutability only after validating retention
Locked immutability is intentionally difficult to reverse. Before enabling it, confirm retention periods, legal requirements, workload lifecycle and likely storage costs.
Add multi-user authorisation through Azure Resource Guard, which requires approval through a separately controlled security resource for sensitive backup operations. This reduces the chance that one compromised administrator can destroy the recovery capability.
5. Separate backup authority from daily administration
The same account should not manage production systems, change backup policies and approve destructive backup operations. Use separate roles, strong multifactor authentication and tightly controlled emergency accounts.
Microsoft Defender and Wiz, a cloud security platform that identifies risks across cloud environments, can help expose dangerous permissions and configuration gaps before they become recovery problems.
6. Test recovery without disrupting production
Run Site Recovery test failovers in an isolated network. Restore selected files, disks, databases and complete virtual machines from backup, then ask application owners to confirm that the recovered service actually works.
Australian government guidance has long emphasised regular backups and recovery testing. Organisations transitioning from the Essential Eight, the Australian government’s established cybersecurity baseline, to the newer ASD Essentials for enterprise IT should preserve evidence of these tests.
7. Measure actual recovery time
Do not mark a test successful simply because a machine started. Record how long the full service took to become usable, what manual work was required and whether the result met the approved business target.
Our broader Azure platform resilience checklist covers the governance and evidence CIOs should expect around these tests.
8. Review hybrid systems as one environment
Mid-market organisations often have Azure workloads, local infrastructure and older servers managed by different teams. Azure Arc, which brings non-Azure servers into Azure’s management layer, can make protection more consistent across this mixed environment.
See how Azure Arc simplifies hybrid disaster recovery, but do not assume central visibility means every workload has a working recovery path.
What this looks like in a mid-market business
Consider a 200-person professional services firm with its finance platform in Azure, several local virtual machines and customer documents spread across multiple systems. It had daily backups, but the infrastructure team had never tested a full application recovery.
A sensible design would use Site Recovery for the finance application and its dependent servers, regular restore points for fast rollback, and locked immutable backups for longer-term clean copies. Quarterly failover and restore exercises would then prove whether the documented recovery times were realistic.
The business outcome is not simply “more backup.” It is less downtime, clearer accountability and a much lower chance of discovering a recovery gap during a ransomware incident.
Resilience should be proven rather than assumed
Azure now provides strong options for continuity, point-in-time recovery and ransomware-resistant backup. The remaining risk is usually how those tools are designed, secured and tested.
CloudProInc brings more than 20 years of enterprise IT experience to this work as a Microsoft Partner and Wiz Security Integrator. Our Melbourne-based team works directly with organisations across Australia and internationally, without the layers of a giant, faceless provider.
If you are unsure whether your Azure environment could meet the recovery promises being made to the board, we are happy to review the setup and identify the practical gaps — no strings attached.