Lab 05: VM Disaster Recovery with Azure Site Recovery¶

Configure Azure Site Recovery for a critical VM, run a test failover, and document the validation artifacts needed for a real DR event.

Prerequisites¶

• Azure subscription with contributor-level access to compute, network, backup, and monitoring resources
• Azure CLI installed and signed in
• Variables set for the lab:
  • RG
  • VM_NAME
  • LOCATION
  • VNET_NAME
  • SUBNET_NAME
• A Log Analytics workspace or backup vault where the lab requires it

Architecture Diagram¶

graph TD
    A[Lab 05: VM Disaster Recovery with Azure Site Recovery] --> B[Resource group and networking baseline]
    B --> C[Virtual machine deployment]
    C --> D[Security and access controls]
    D --> E[Observability and validation]
    E --> F[Cleanup and cost review]

Lab Metadata¶

Step-by-step Instructions¶

Step 1: Create the resource group and network baseline¶

az group create \
    --name $RG \
    --location $LOCATION \
    --output json

az network vnet create \
    --resource-group $RG \
    --name $VNET_NAME \
    --address-prefixes 10.40.0.0/16 \
    --subnet-name $SUBNET_NAME \
    --subnet-prefixes 10.40.1.0/24 \
    --output json

Expected outcome:

• The resource group exists in the intended region.
• The virtual network and subnet are available for VM deployment.

Step 2: Deploy the base VM¶

az vm create \
    --resource-group $RG \
    --name $VM_NAME \
    --image Ubuntu2204 \
    --size Standard_D4s_v5 \
    --admin-username azureuser \
    --generate-ssh-keys \
    --vnet-name $VNET_NAME \
    --subnet $SUBNET_NAME \
    --public-ip-sku Standard \
    --storage-sku Premium_LRS \
    --output json

Expected outcome:

• The VM deploys with Premium SSD-backed storage and a predictable network baseline.
• You have enough CPU, memory, and NIC capability to test the scenario without using a tiny burstable SKU.

Step 3: Capture the source workload state for replication¶

Before you enable Azure Site Recovery, record the VM characteristics that the target region must reproduce so your failover test validates the right source configuration.

az vm show \
    --resource-group $RG \
    --name $VM_NAME \
    --query "{name:name,location:location,vmSize:hardwareProfile.vmSize,zone:zones,storageProfile:storageProfile.osDisk.managedDisk.storageAccountType}" \
    --output json

Recommended operator notes:

• Record the source region and zone placement so you can verify the target-region replication design is intentional.
• Note the target virtual network, DNS, and identity dependencies that must exist before test failover.
• Record the recovery point objective and the validation evidence you expect from the failover drill.

Step 4: Validate the scenario end to end¶

Run both control-plane and workload validation so you have a clean baseline before replication and failover testing begin.

az vm get-instance-view \
    --resource-group $RG \
    --name $VM_NAME \
    --output json

az monitor activity-log list \
    --resource-group $RG \
    --offset 2h \
    --output table

Step 5: Optional operational hardening¶

• Review whether replication alone is enough or whether the service also needs a documented application cutover sequence.
• Review whether failover networking, name resolution, and security controls exist in the target region.
• Review whether the workload still needs Azure Backup after ASR is enabled, because replication is not the same as backup retention.

Validation Steps¶

Use the following validation checklist before marking the lab complete:

• [ ] The VM is in the expected power and provisioning state
• [ ] The intended feature change is visible in Azure resource properties
• [ ] At least one CLI verification command was captured after the change
• [ ] You can explain how the lab outcome would change production design or troubleshooting

Cleanup Instructions¶

az vm delete \
    --resource-group $RG \
    --name $VM_NAME \
    --yes

az network nic delete \
    --resource-group $RG \
    --name "${VM_NAME}VMNic"

az group delete \
    --name $RG \
    --yes \
    --no-wait

Cleanup notes:

• Delete associated disks, public IPs, Bastion hosts, vault items, or replication resources if the lab created them.
• Review whether backup vaults or recovery services still hold retained items that continue billing after VM deletion.

See Also¶

• Best Practices
• Operations
• Troubleshooting Playbooks

Sources¶

• Azure virtual machines documentation
• Azure CLI for virtual machines
• Azure Backup for virtual machines
• Azure Site Recovery for Azure VMs