Create a Recovery Services vault
Interpret Configuration Settings and Integration Options
A Recovery Services vault is a central storage location in Azure for protecting workloads like virtual machines and databases. A key decision during creation is choosing a storage replication type, which locks permanently once backups are configured. You choose between Locally-redundant storage (LRS) for low-cost protection within one data center, Zone-redundant storage (ZRS) for replication across availability zones in one region, or Geo-redundant storage (GRS), the default, which copies data to a secondary paired region for maximum durability.
Security and access are managed through Role-Based Access Control (RBAC). To protect against data loss, Soft Delete retains deleted backups for 14 days. For strict compliance, Immutable vaults can be enabled to prevent the early deletion of recovery points. The vault can use platform-managed keys for encryption by default or customer-managed keys (CMK) stored in Azure Key Vault for greater control. The vault integrates with Azure Site Recovery for disaster recovery orchestration and supports Cross Region Restore (CRR) for restoring to a secondary region if GRS is configured.
Assess Prerequisites and Deployment Considerations
Before creating a vault, you must plan its location and dependencies. The vault must be deployed in the same region as the resources it will protect and placed within a specific Subscription and Resource Group. The choice of storage replication type (GRS, LRS, or ZRS) must be finalized before any data is protected, as it cannot be changed later.
To use advanced features like customer-managed keys, you must prepare supporting infrastructure first. This includes enabling a Managed Identity for the vault and ensuring Azure Key Vault has soft delete and purge protection enabled. Network planning is also important; for example, on-premises servers using the Microsoft Azure Recovery Services (MARS) agent need outbound internet access to Azure Backup endpoints. If you plan to restore data across different subscriptions, you must configure the appropriate RBAC permissions in advance.
You create a Recovery Services vault through the Azure portal's Business Continuity Center. The steps involve selecting your subscription, resource group, providing a unique vault name, and choosing the region. After creation, you configure protection by going to the Backup center, selecting a data source type like Azure Virtual machines, and linking it to your vault along with a backup policy that defines the schedule and retention.
Ongoing management includes monitoring jobs and modifying settings. Before enabling backups, you can change the default storage replication from GRS to LRS in the vault's properties. To defend against ransomware, you can enable immutable vault settings. If a disaster occurs in the primary region, you can use Cross Region Restore to recover resources directly in the secondary paired region.
Create an Azure Backup vault
A backup policy is the rule that governs your backups, defining the schedule (daily or weekly) and how long data is retained. Retention rules can follow a grandparent-parent-child structure to keep some backups longer and can extend up to 10 years for compliance. You apply these policies through a Backup vault, which is the storage entity for your backup data. You create the vault and then link it to the specific storage accounts and containers you want to protect. A key security feature is immutable vaults, which lock recovery points to prevent deletion before their expiry date.
Implement Azure Recovery Services Vault Creation
An Azure Recovery Services vault is a central management resource for backup and disaster recovery, storing backup data and recovery points. Creation requires specifying a subscription, resource group, unique name, and, critically, the region, which must match the region of the resources being protected. You can create the vault via the portal, PowerShell, ARM templates, or the REST API.
A foundational decision is selecting the storage redundancy. Geo-redundant storage (GRS) replicates to a paired region and is the default for maximum durability. Locally redundant storage (LRS) is lower cost and keeps copies in a single data center. Zone-redundant storage (ZRS) replicates across availability zones within one region. This setting is locked after backups are configured. The vault also supports advanced restore features like Cross Region Restore (CRR) for GRS vaults and Cross Subscription Restore within the same tenant.
Advanced security features protect backups from accidents and attacks. Soft delete retains deleted backup data for a period (14 days by default) for recovery. Immutable vaults make it impossible to delete any recovery point before its scheduled expiration, a crucial defense against ransomware. The storage replication type (LRS, ZRS, or GRS) chosen during vault creation is foundational for data durability and enables features like CRR.
Security is also managed through Azure Role-Based Access Control (RBAC) to limit vault operations. Encryption at rest uses Microsoft-managed keys by default, but you can use customer-managed keys (CMK) for greater control. When planning, consider how the vault's configuration affects your Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For example, with GRS, restoring to a secondary region might have an RPO of up to 36 hours due to replication latency.
An Azure Backup strategy is defined by a backup policy, which sets the schedule (daily or weekly) and retention rules (daily, weekly, monthly, yearly) for recovery points. Policies are scoped to a single recovery vault. You can modify policies later; extending retention applies to existing recovery points, while reducing it marks older points for deletion. You can also run an on-demand backup with custom retention outside the scheduled policy.
When stopping protection for a resource, you choose between stop protection and retain backup data to keep existing recovery points, or stop protection and delete backup data to remove all recovery points permanently. Security is enforced by encrypting data at rest and in transit and using role-based access control (RBAC). Soft delete is enabled by default to guard against accidental deletions. Monitoring is done with tools like Backup Explorer and integration with Azure Monitor and Log Analytics.
Implement Governance, Security, and Lifecycle Management for Backup Policies
To protect against ransomware and unauthorized deletions, you can enable immutability on a vault to lock recovery points until their expiration. Access is controlled through specific RBAC roles like Backup Contributor, Backup Operator, and Backup Reader. For governance at scale, you can use Azure Policy to automatically configure backups for new resources and link them to a central vault.
Designing retention periods requires care because Azure Backup does not allow selective deletion of individual recovery points; reducing retention applies to all associated resources and prunes old points automatically. For maximum security, multi-user authorization (MUA) can be implemented using a Resource Guard to require external approval for critical changes like disabling soft delete. Using customer-managed keys (CMK) provides direct control over encryption keys. Regularly resuming protection on paused workloads ensures retention rules are re-evaluated, and performing test restores validates that recovery times meet your RPO and RTO targets.
Define Backup Policy Parameters and Protection Scope
Backup parameters must match the criticality of each workload. Mission-critical systems may use enhanced policies with multiple daily backups to minimize data loss (a low RPO). Retention rules are split between short-term needs for immediate recovery and long-term retention for regulatory compliance, with older points potentially moved to a cost-effective archive tier.
The protection scope defines which resources are governed by a policy and is influenced by vault design. Best practices suggest using multiple recovery vaults to segregate workloads by region, department, or environment to isolate risk and enforce RBAC. This is necessary because a single vault has scalability limits, such as supporting a maximum of 1,000 virtual machines. To maintain oversight across distributed vaults, administrators use the Backup Center as a unified management plane.
Azure Backup uses saved copies called recovery points to restore a resource. Data is stored in a Snapshot Tier for Instant Restore and a Vault Tier for long-term retention. When restoring, you decide between Original Location Recovery (OLR) to replace the existing source or Alternate-Location Recovery (ALR) to create a new instance.
Restore methods vary by goal. Create New Virtual Machine rebuilds a complete VM, while Restore Disks recovers virtual hard disks for manual attachment. For granular recovery, Item Level Restore (ILR) recovers specific files or folders without a full VM rebuild. For workloads like SQL Server on Azure VMs, restore is granular and supports Point-in-Time Recovery using transaction logs. Cross-Region Restore (CRR) enables recovery in an Azure paired region for regional outages. For Encrypted VMs, the process requires restoring disks first and then using PowerShell to recreate the VM with keys from Key Vault. All restore operations are tracked in the Backup Center and must be validated post-recovery.
Interpret Backup Job Status and Troubleshoot Failures
Azure Backup provides monitoring tools in the Recovery Services vault to show job statuses: Completed, In progress, Failed, Canceled, and Completed with warnings. You can filter jobs by item type, operation, status, and time range to identify issues.
When a job fails, Azure Backup generates alerts via Azure Monitor. Critical alerts are triggered for events like backup/restore failures or deletion of backup data. To diagnose failures, examine job logs. Common causes include Transient errors (network issues), Permission issues (missing RBAC roles), Resource constraints (insufficient storage), Unhealthy workload extensions, and Unsupported backup types. Remediation may involve retrying jobs, assigning correct permissions, or adjusting policies. Monitoring solutions like Backup Explorer and Backup Reports help analyze trends and forecast storage. Regularly validating backups through test restores ensures recovery points are usable, and security features like soft-delete and Multi-User Authorization (MUA) protect against data deletion.
Azure Backup policies define protection through Scheduling (when backups run), Retention (how long data is kept), and Storage Options (LRS, GRS, ZRS). These policies are applied to workloads like Azure VMs, SQL Server on Azure VMs, and Azure Files and Azure Blobs.
Security features protect backup data. Encryption at rest uses platform-managed keys (PMK) or customer-managed keys (CMK). Soft Delete retains deleted backup data for 14 days. Multi-User Authorization (MUA) adds a critical protection layer by requiring multiple users to authorize destructive operations like disabling soft delete or deleting backups. Monitoring is done via Backup Explorer and integration with Azure Monitor for custom alerts. Periodically performing Test Restores validates the backup configuration and confirms successful data recovery.
When preparing Azure VMs to fail over to a secondary region, you must define target resources like the subscription, resource group, and virtual network. While Azure Site Recovery can create these automatically, administrators often customize them to match the production environment. Network planning involves mapping IP addresses and ensuring Network Security Groups in the target region allow outbound replication traffic on port 443.
Load balancers and Azure Traffic Manager are not created automatically and must be provisioned in the target region in advance to direct traffic after a failover. Recovery Plans combined with Azure Automation scripts can automate connecting these components. Compute sizing in the target region typically matches the source VM size, and you must configure Availability Sets or Availability Zones for high availability. For specialized workloads, Azure Site Recovery integrates with SQL Always On availability groups and requires failing over Active Directory and DNS servers first so other application tiers can authenticate.
Azure Site Recovery is a service for business continuity and disaster recovery, replicating workloads between Azure regions or from on-premises to Azure. Implementation starts by creating a Recovery Services vault, which is the central management point. You enable the vault's managed identity and assign it specific roles for accessing storage accounts.
You define replication policies that set the recovery point retention history and app-consistent snapshot frequency, which determine potential data loss (RPO) and how far back you can recover. Enabling replication for Azure VMs involves selecting the source VMs, configuring the target location and network, and then enabling replication. All communication within the service uses TLS 1.2, and data integrity is maintained through checksums. Automation is possible using the REST API, PowerShell, or the Azure SDK.
Execute and Orchestrate Disaster Recovery Operations
Azure Site Recovery keeps applications running during outages by replicating workloads to a secondary site. Recovery Plans organize how multiple virtual machines fail over together for complex applications, automating the startup order (e.g., database before web server) and allowing for custom scripts or manual steps.
There are three main failover types. A Test Failover is a drill that doesn't impact production. A Planned Failover for maintenance ensures zero data loss. An Unplanned Failover responds to a sudden disaster, aiming for minimal data loss. When triggering a failover, you select a Recovery Point—such as the Latest for the lowest RPO, Latest Processed for a lower RTO, or Latest App-consistent for database integrity. After a successful failover and verification, you Commit the operation to finalize it. To return to the primary region, you perform Reprotection to start reverse replication, followed by a Failback.
Execute Failover Operations and Recovery Point Selection
Azure Site Recovery supports Planned Failovers for zero-data-loss maintenance and Unplanned Failovers for sudden outages. When executing a failover, selecting the correct recovery point is vital. The Latest point offers the lowest Recovery Point Objective (RPO). The Latest Processed point offers a lower Recovery Time Objective (RTO). The Latest App-consistent point captures memory-resident data for database integrity.
For maximum data integrity, you can select the option to Shut-down machine before beginning failover to synchronize final changes. If the source is inaccessible, failover proceeds with the latest available data. After failover, the VM must be validated in the secondary region. If needed, you can use Change recovery point to select a different snapshot. Once satisfied, you Commit the failover, which deletes other recovery points for that session. To return to the original region, you must later initiate Reprotection.
For multi-tier applications, Recovery Plans sequence the failover of different tiers (web, app, database), and Automation Runbooks can handle tasks like updating DNS or load balancer settings.
Configuring failover involves ensuring the VSS Provider service is installed and set to Automatic to create application-consistent snapshots. If disabled, errors like Error 2147943458 may occur, requiring a restart of the VSS, Azure Site Recovery VSS Provider, and VDS services. Performing Test Failovers is essential to validate your disaster recovery configuration in the secondary region without impacting production.
If you encounter a no Mobility Service heartbeat error due to an expired tenant, you must manually update the TenantId and ClientId in the source machine's configuration file and restart services. Ensuring successful recovery requires addressing these pre-failover configuration issues.
Manage Post-Failover Commitment and Reprotection
After a failover, the VM runs in the secondary region but is not finalized. The Commit process confirms the failover, making the secondary VM the permanent primary and deleting all other recovery points for that session. Once committed, the VM is in an unprotected state because replication has stopped.
To re-establish protection, you must initiate reprotection, which sets up reverse replication from the secondary region back to the primary. This is a prerequisite for failback. Reprotection uses delta replication, calculating a checksum to copy only the changes made while the VM was in the secondary region, saving time and bandwidth. Successful reprotection requires verifying that the target virtual network, resource groups, and availability sets in the primary region are correctly configured. After reprotection, you can perform a failback, which is a planned failover to return the workload to the primary region, shutting down the source VM in the secondary region to ensure data consistency.
Set Up and Manage Backup Reports
Azure Backup provides reporting by sending diagnostic data from Recovery Services vaults to a Log Analytics workspace. Once configured, you view reports in the Azure portal through the Business Continuity Center. These reports give visibility into backup jobs, protected items, storage usage, and policy compliance across workloads like Azure VMs and SQL databases.
Reports integrate with Azure Monitor Logs for deep analysis with custom queries and with Azure Resource Graph for querying data across multiple subscriptions. For convenience, reports can be emailed, customized with Azure workbooks, exported to Excel, or pinned to your dashboard.
Assess Backup Report Metrics for Compliance and Optimization
Reports help assess health and compliance by tracking metrics like success rates, failure trends, and job durations over time. You examine Backup Health Events and Restore Health Events, using dimensions like Datasource ID and Health Status to pinpoint issues.
Reports also aid in optimization and cost management. The Optimize tab identifies Inactive Resources (items without a recent successful backup) and highlights Retention Optimizations where items are kept longer than necessary, offering chances to reduce storage costs. Analyzing failure trends helps distinguish persistent problems from transient errors.
Interpret Backup Alert Types and Resolution Strategies
Azure Backup alerts are categorized by severity: critical, warning, and informational. Critical alerts indicate serious problems like backup/restore failures or destructive operations such as deleting backup data. Warning alerts signal successful operations with minor issues.
There are several alerting mechanisms. Built-in Azure Monitor Alerts are automatically created for critical scenarios. Metric Alerts allow custom rules based on backup health metrics. Log Analytics or Azure Resource Graph-based Alerts use data sent to those services for custom logic. Alerts are routed using Action Groups to channels like email or webhooks. Alert Processing Rules can suppress alerts during maintenance.
Resolution depends on the alert. For a critical backup failure, investigate job logs and check VM health and configurations. For a security alert, confirm if the action was authorized and use soft-delete or multi-user authorization (MUA) to recover data if needed. Persistent issues require investigation using Backup Reports and Azure Monitor Logs.
StudyCerts
StudyCerts