In this blog
It’s Monday morning: you come to work and find that an Azure Local VM is gone.
Maybe it was deletion caused by an operator error, a script that ran against the wrong target, a configuration management tool that overcorrected, or a non-production refresh. Maybe the deletion was caused by a malicious actor.
The cause, at this point, is secondary. The immediate task is recovery.
So you locate the last clean snapshot and restore it to the most appropriate cluster: the original (if it is still available and has capacity) or an alternate when circumstances point elsewhere.
What comes back is a Hyper-V VM. The Azure Portal, your management plane, cannot see this restored VM as a managed resource.
The basic contract of backup and recovery is that you restore to a known good state. A Hyper-V VM is not the state you had—it lacks an Azure identity, is not an Azure-managed resource, and is outside the Azure governance boundary. So a recovery that removes a VM from that model isn't truly returning the last known good state. It creates a new starting point with extra steps.
While an incident is still unfolding, your team should be focused on recovery, not on reconciling VMs that are outside the Azure control plane. The gap that is a nuisance in routine operations becomes an operational blocker during a mass recovery event and recovery readiness is what decides how bad that day gets. Fortunately, Rubrik Threat Hunting and Turbo Threat Hunting can identify candidate recovery points free of known indicators of compromise—and from that same RSC session, you initiate recovery to a clean alternate cluster without switching tools or workflows.
Why This Happens
An Azure Local VM is an Azure resource. It is arc-enrolled, placed in a resource group, connected to a logical network, and deployed to a custom location that represents the cluster in Azure. Its identity is defined in Azure, not just on the physical cluster. Without that identity, the VM sits outside the scope of how your organisation manages, governs, and operates its Azure environment.
Protecting Azure Local VMs only at the physical cluster level means protecting the VM without visibility into the Azure identity.
On-Demand Session:
Hypervisor Freedom: Unified Protection for Modern Infrastructure
How Rubrik Solves It
If you onboard your Azure subscription for Azure Local (the same way you already do for Azure Cloud workloads), Rubrik maps a protected VM to its Azure identity, not just its physical cluster. Rubrik understands where your VMs physically run AND where they belong in Azure. That mapped identity is what makes the recovery different.
With Azure identity mapped, alternate-location recovery becomes Azure-aware. Unlike recovery approaches that treat Azure Local as an extension of Hyper-V, Rubrik integrates with Azure Local's first-class ARM APIs, treating Azure Local as a distinct platform.
The recovered VM lands in the right resource group, connected to the correct logical network, manageable from the Azure Portal—reducing the reconciliation work that would otherwise follow.
What you get back is a true Azure Local VM, fully manageable within the Azure Portal.
Azure Local VM Recovery
Cloud Account Integration and Export to Azure Local VM are in limited availability with CDM 9.6.1. To join, talk to your Rubrik account team.”