Azure VM Backup and Disaster Recovery Runbook for Recovery Testing

Overview

Azure Backup protects supported virtual machines by storing recovery points in a Recovery Services vault. A practical design separates three activities: configuring protection, monitoring backup health, and proving recovery through a test restore. Treating these as separate tasks prevents a common failure mode in which a VM appears protected but has never been restored in a realistic scenario.

Before changing anything, document the workload and its recovery objectives. Record the VM name, subscription, resource group, region, operating system, attached data disks, application owner, and dependencies such as databases, identity services, file shares, DNS, or external APIs. Define a recovery point objective (RPO)—how much data loss is acceptable—and a recovery time objective (RTO)—how quickly the service must be available. The backup schedule and restore procedure should support those objectives rather than simply using default settings.

A Recovery Services vault is a management and storage boundary for backup data. During design, consider its region, access controls, redundancy choices, soft-delete or security settings exposed in the current Azure experience, and the operational separation needed by your organization. Portal labels and available options can change, so confirm the current Microsoft documentation before applying a production configuration.

Backup is not the same as disaster recovery. Azure VM Backup provides recovery points for restoring a VM, disks, or files, while a broader disaster recovery plan may also require replicated workloads, network failover, application dependency mapping, and a tested communications plan. Use the appropriate service and procedure for the failure you are preparing to handle.

Checklist by scenario

Scenario 1: Protect a new Azure VM

1. Inventory the workload. Confirm the VM, disks, operating system, application role, region, and data classification. Identify whether the workload requires application-consistent recovery.
2. Create or select a Recovery Services vault. Choose a suitable subscription, resource group, and region. Apply least-privilege access and ensure the operations team can manage backup and restore actions.
3. Choose a backup policy. Set the schedule and retention periods according to the RPO, legal requirements, and business value of the workload. Avoid assuming that a long retention period automatically meets a recovery requirement.
4. Enable backup for the VM. Select the correct VM and policy, then confirm that protection is enabled and that the first backup is scheduled or started according to the current portal workflow.
5. Check consistency. Determine whether the recovery point is crash-consistent or application-consistent. For database and transactional workloads, coordinate with the application owner and verify the supported consistency method.
6. Verify the first recovery point. Do not close the change after enabling protection. Confirm that the job completed, the VM shows a healthy protection state, and the recovery point has the expected timestamp.

Scenario 2: Perform a controlled test restore

1. Choose a non-production subscription or resource group when possible, and obtain approval for any temporary resources and data handling.
2. From the vault, select the protected VM and start the restore workflow. Select a recovery point that represents the test objective, such as the latest successful point or a point before a known change.
3. Choose the restore type and destination. A new VM is usually easier to validate without affecting production; disk-only restoration may be more appropriate when the original VM configuration is managed separately.
4. Use an isolated virtual network or controlled subnet if the restored system could conflict with production IP addresses, hostnames, services, or credentials.
5. Record the start time, recovery point, restore job identifier, destination resources, and completion time. The elapsed time is useful evidence for the RTO review.
6. Validate boot, disks, operating system services, application health, data visibility, permissions, and network dependencies. Do not stop at “the VM started.”
7. Remove temporary resources only after collecting evidence and receiving approval. Confirm that deletion does not remove production resources or required backup data.

Scenario 3: Recover after a VM or disk failure

1. Declare the incident and identify the required recovery point using business and technical evidence.
2. Confirm that the selected point belongs to the correct VM and includes the required disks and data.
3. Decide whether to restore a complete VM, disks, or files. Use a new target when preserving the original environment is important for investigation.
4. Rebuild or validate networking, identity, monitoring, secrets, certificates, scheduled tasks, and application dependencies.
5. Have the service owner perform functional acceptance testing before reopening access to users.
6. Document the final recovery time, data loss, deviations from the runbook, and follow-up actions.

Restore options and retention considerations

Retention settings should be reviewed with the data owner and finance team. Backup storage, protected instances, transactions, restored resources, and related services can affect cost. For planning, compare the policy with your broader Azure cost optimization checklist and review storage considerations in the Azure storage pricing guide.

What to double-check

• Permissions: Confirm that backup operators can view jobs, configure protection, and initiate restores, while production administrators retain appropriate separation of duties.
• Encryption and keys: If customer-managed keys or disk encryption are used, document key ownership, access, rotation, and recovery implications.
• Application consistency: A successful backup job does not by itself prove that a database or application can recover cleanly. Include application-specific checks.
• Network isolation: Make sure a test restore cannot accidentally advertise routes, reuse production addresses, trigger automation, or connect to live dependencies.
• Quotas and supportability: Check current Azure Backup limitations, supported VM configurations, disk arrangements, operating system requirements, region availability, and restore restrictions before relying on a design.
• Monitoring: Configure an owner and review failed jobs, stale protection states, policy changes, and alerts. A backup that nobody monitors will eventually become an untested assumption.
• Evidence: Keep job identifiers, timestamps, screenshots or exported results where appropriate, test notes, and approval records in the team’s operational repository.

Common mistakes

• Enabling protection but never confirming the first successful recovery point.
• Testing only that a restored VM boots, without testing applications, data, permissions, and dependencies.
• Restoring into the production network and creating an address, hostname, or service collision.
• Using one broad policy for every VM, even though development, file services, databases, and critical business systems have different RPO and retention needs.
• Ignoring credentials, certificates, secrets, scheduled tasks, monitoring agents, and external integrations after restoration.
• Assuming backup protects an entire service when its database, storage, identity, or configuration is managed separately.
• Deleting test resources without recording the result or checking that production resources remain intact.

When to revisit

Review this Azure disaster recovery checklist monthly or quarterly, depending on workload criticality. At minimum, review backup health, failed jobs, policy assignments, recovery-point age, vault access, and capacity or cost signals. Perform a test restore on a planned cycle rather than waiting for an incident.

Repeat the review after a VM resize, operating system change, disk or application migration, region or network redesign, identity change, encryption-key change, retention-policy update, or Azure Backup workflow change. Also revisit the runbook before seasonal planning cycles and after any incident that exposes a recovery gap.

Use this compact recovery-test template for each exercise:

1. Date and owner: record the test date, participants, workload, and approval.
2. Objective: state whether the test measures file recovery, VM recovery, application recovery, RPO, RTO, or a combination.
3. Recovery point: record its timestamp, source VM, policy, and consistency status.
4. Target: record subscription, resource group, region, network, restored resources, and isolation controls.
5. Results: record restore start and finish times, elapsed recovery time, validation steps, data checks, and user or owner sign-off.
6. Gaps: list failed steps, unexpected dependencies, cost concerns, security issues, and assigned corrective actions.
7. Next review: schedule the next test and update the runbook immediately if the environment or portal workflow has changed.

A backup policy is a configuration; a recovery test is evidence. Keep both current, link each protected workload to an owner, and treat every infrastructure change as a prompt to confirm that recovery still works.