In this blog post Azure Backup in 2026 with VMware 9 and Immutable Recovery Plans we will explain what has changed, why successful backup jobs do not prove recoverability, and how to build a recovery posture that protects the business when systems, credentials or entire sites are compromised.
At a high level, Azure backup and recovery technology creates protected copies of your systems and data, stores them separately from production, and provides a way to restore them after ransomware, accidental deletion, hardware failure or a major outage. The important question is no longer simply whether a backup exists. It is whether the right systems can be restored safely, in the correct order and within a timeframe the business can tolerate.
VMware 9 support closes an important protection gap
VMware upgrades often move faster than backup platforms. That creates an uncomfortable period where the virtualisation environment may be current, but the system protecting it is not officially supported.
Microsoft Azure Backup Server V4 Update Rollup 2, released in 2026, adds support for protecting virtual machines running on VMware vSphere 9.0, including vCenter Server 9.0 and ESXi 9.0. Azure Backup Server is Microsoft’s hybrid backup platform, which protects on-premises workloads to local disk and can then send recovery data to Azure for offsite retention.
For VMware environments, the backup is agentless at the virtual machine level. In plain English, you do not need to install backup software inside every VMware server. Azure Backup Server communicates securely with vCenter or ESXi, discovers the virtual machines and protects them through centrally managed backup policies.
Azure Site Recovery, which replicates workloads into Azure so they can be started during an outage, and Azure Migrate also support vSphere 9.0. However, backup, replication and migration are different services. Support for VMware 9 in one product should never be assumed to mean that every connected tool, plug-in and recovery process is ready.
Before upgrading VMware, confirm the exact versions of Azure Backup Server, its agents, vCenter, ESXi and any third-party recovery tools. Our earlier article on VMware to Azure migration security choices explores the broader decisions involved when workloads are also moving into Azure.
A supported backup is not automatically a safe backup
Imagine a 200-person business with 70 VMware virtual machines. Its dashboard shows that backups completed overnight, so management assumes ransomware recovery is covered.
But the same administrator account can change retention settings, stop protection and manage the backup infrastructure. No full business application has been restored in 18 months. The backups exist, but an attacker who compromises the administrator account may be able to damage the recovery path as well as production.
This is the gap immutability is designed to address.
What Azure backup immutability actually does
An immutable backup cannot be deleted or have its retention period shortened before the protected period expires. Think of it as placing a recovery copy in a time-locked safe rather than leaving it in a filing cabinet that an administrator can empty.
Azure supports immutability across Recovery Services vaults and Backup vaults. These vaults are protected Azure containers that hold recovery points and the policies controlling how long those recovery points are retained.
When immutability is enabled, destructive operations are restricted. When it is locked, the setting becomes irreversible. Azure can also use write once, read many storage, commonly called WORM storage, so protected backup data cannot be rewritten or removed during its locked period.
Time-based immutability provides another useful option in 2026. It allows an organisation to set an immutability period independently from its wider backup retention policy. This can help align protection with ransomware risk, contractual obligations and data retention requirements.
Locking a vault should still be treated as a governance decision, not a checkbox. If retention periods are wrong, locked immutability can preserve unnecessary data and increase storage costs. Review the design first, then lock it. Our guide to lowering Azure backup and recovery costs without adding risk explains how to balance protection and spending.
Immutability is one layer of the recovery posture
Immutability protects recovery points, but it does not prove that applications will start, databases will be consistent or employees will regain access. A strong recovery posture combines technology, people and tested procedures.
For most organisations, that means addressing five areas:
- Coverage: Every business-critical server, database, file store and cloud service is identified and protected.
- Isolation: Backup data and management controls are separated from everyday production access.
- Authority: No single compromised administrator can quietly remove the organisation’s recovery options.
- Testing: Systems are restored regularly, not merely checked for successful backup status.
- Business priorities: Recovery order and timeframes are agreed with business leaders rather than guessed during an incident.
Azure features such as role-based access control, which limits what each account can do, soft delete, multi-user authorisation and Resource Guard can add further protection. Resource Guard places sensitive operations behind a separately controlled approval boundary, reducing the chance that one stolen account can disable protection.
Backup and disaster recovery solve different problems
Backup gives you historical recovery points. Disaster recovery keeps a copy of a workload ready to start in another location. High availability keeps services running through smaller infrastructure failures.
A replicated VMware server can still copy ransomware-encrypted data into Azure. A backup may contain a clean historical version, but restoring it could take longer than the business expects. Mature recovery planning uses the right combination rather than treating one product as the answer to every incident.
Leaders should define two practical targets for each critical service. The first is how much recent data the business can afford to lose. The second is how long the service can remain unavailable. These targets should drive backup frequency, replication choices, storage design and testing.
What a useful recovery test should prove
A restore test should do more than recover one file into an empty folder. It should demonstrate that a real business service can return without relying on the systems that may have been compromised.
- Choose a critical application and document its servers, databases, network connections and identity requirements.
- Restore it into an isolated recovery environment where it cannot affect production.
- Confirm that the selected recovery point is clean and usable.
- Start components in the correct order and test the application with a business owner.
- Record the actual recovery time, problems encountered and manual steps required.
- Update the recovery plan and repeat the test after major infrastructure changes.
This evidence is important for the Essential Eight, the Australian government’s baseline cybersecurity framework. Regular backups are one of its eight controls, and Australian Signals Directorate guidance expects restoration of data, applications and settings to be tested through disaster recovery exercises.
A green dashboard is useful operational information, but it is not evidence that the business can recover. We explore that distinction further in Azure Backup Assurance Turns Inventory Into Recovery Decisions.
A practical 2026 action plan
For organisations running VMware and Azure together, the next review should focus on a short list of decisions:
- Confirm VMware 9 protection across backup, replication and migration products.
- Update Azure Backup Server V4 and its required components through a controlled change process.
- Map critical workloads to agreed recovery times and acceptable data loss.
- Review retention before enabling and locking immutability.
- Separate backup administration from normal infrastructure administration.
- Require additional approval for destructive backup operations.
- Run at least one end-to-end recovery exercise for a critical service.
- Give executives a recovery report based on tested outcomes, not backup job counts.
Database workloads may require additional application-specific controls. For example, our article on immutable Azure SQL backups for practical ransomware recovery covers how database recovery points fit into a wider ransomware plan.
Recovery confidence must be demonstrated
VMware 9 support is a valuable step because it allows organisations to modernise their VMware estate without leaving a known backup compatibility gap. Immutability makes those backups harder to destroy. Neither improvement, however, replaces access separation, realistic recovery targets or regular restore testing.
CloudProInc is a Melbourne-based Microsoft Partner and Wiz Security Integrator with more than 20 years of enterprise IT experience. We work hands-on across Azure, Microsoft 365, Defender, Wiz and hybrid VMware environments, helping Australian organisations turn backup tools into practical recovery plans.
If you are not sure whether your current backups would survive a compromised administrator account or support a real business recovery, we are happy to review the setup and identify the gaps — no strings attached.