Azure Backup & Site Recovery: Vaults, Policies & Failover (AZ-104)

A Recovery Services vault holds backups of Azure virtual machines, Azure Files shares, SQL Server and SAP HANA running inside Azure VMs, and on-premises machines protected by the MARS agent or Microsoft Azure Backup Server (MABS); it is also the vault Azure Site Recovery uses for replication and failover. An Azure Backup vault is the newer vault type for workloads the Recovery Services vault does not handle, such as Azure Blobs, Azure managed disks (Azure Disk Backup) and Azure Database for PostgreSQL, and Microsoft keeps adding datasources to it. The workload decides the vault: a VM backup or a Site Recovery setup needs a Recovery Services vault, while blob, disk or PostgreSQL backup needs a Backup vault.

Create the vault in the same region as the data it protects. A vault backs up resources in its own region, so a VM in East US is protected by a vault in East US; for Azure Disk Backup the Backup vault must sit in the disks' region. You create either type from its own portal page (Recovery Services vaults or Backup vaults > Create) or from Azure Business Continuity Center, which now appears in the portal as Resiliency and replaces Backup center as the at-scale management view. Before you protect anything, open the vault's properties and set its storage redundancy and Cross Region Restore (next section), because those choices lock once backup is configured.

A vault's storage replication type decides where the copies of your backup data live, and it can be changed only before backup is configured for any item in the vault. After the first item is protected the setting is locked: stopping protection while retaining data does not unlock it, and there is no grace period. To move a vault in use to a different redundancy, protect the workloads in a new vault created with the right setting (stop protection in the old vault first). New Recovery Services vaults default to geo-redundant storage, so a team that wants cheaper locally redundant storage must change it straight after creating the vault, in Properties > Backup Configuration. The setting governs the copies held in the vault; instant restore snapshots stay with the source disks (next to the VM) whatever the vault uses, so an Enhanced policy does not change the vault's redundancy.

Cross Region Restore lets you restore from the paired-region copy whenever you choose — for a compliance drill, an audit, or a partial outage — rather than only after Microsoft declares a regional disaster. It needs a GRS vault and is switched on in the vault's Backup Configuration properties; ZRS or LRS cannot use it. The vault stays in the workload's own region: you do not create a vault in the paired region. Once enabled, existing and new items replicate their recovery points to the secondary region over time, and an item can take up to 48 hours to show up as restorable there. Enabling it is a one-way choice — it cannot be turned off again — and a vault with Cross Region Restore costs more than plain GRS storage. On restore you pick Secondary Region and then the target resource group, network and storage in the paired region.

Cross Region Restore restores backup recovery points in the paired region. It is not disaster-recovery replication of running VMs; keeping a live workload ready to fail over is Azure Site Recovery's job, covered later in this lesson.

A backup policy defines when backups run and how long recovery points are kept — a schedule plus retention rules. It lives in the vault, you assign it when you enable protection, and one policy can protect many items so they behave consistently.

Retention is layered in a grandfather-father-son pattern, all inside one policy: a daily range (how many days each daily point is kept), a weekly range (which day's backup counts as the weekly point and for how many weeks), a monthly range (for example the last day of each month, kept for months or years) and a yearly range (for example 31 December, kept for years). Each range answers a different requirement: how far back any day can be restored is set by the length of the daily range, while a rule about a single backup per week, month or year is met by the matching weekly, monthly or yearly range, not by stretching the daily range. Longer retention means more stored data and more cost.

Three behaviours are worth knowing because they decide how you change protection later:

• An item belongs to one policy at a time. Editing a shared policy changes every item it protects, so when only a subset of items needs different retention or timing, that subset needs its own policy assigned to just those items.
• Changing retention reaches existing recovery points. Extending the daily range keeps existing points longer under the new rule; reducing it marks older points for pruning at the next cleanup. The expiry times shown in the portal can take up to 24 hours to update.
• Changing a schedule affects future backups only — it cannot create recovery points for times that have already passed.

Example: nightly backups kept 14 days, each Friday's kept 8 weeks and the first of each month kept 2 years is one policy with daily, weekly and monthly ranges — not three policies.

Azure VM backup policies come in two types. A Standard policy takes one backup a day (or on chosen days of the week). An Enhanced policy adds hourly schedules — a backup every 4, 6, 8, 12 or 24 hours within a window — and longer snapshot retention. Some VMs need the Enhanced policy regardless of frequency: VMs with Premium SSD v2 or Ultra Disks can only be backed up with an Enhanced policy. Backup frequency sets the worst-case data loss: with one backup a day, up to a day of changes can be lost, while an Enhanced policy's hourly schedule narrows that gap to the chosen interval without adding any replication infrastructure.

Instant restore is what makes restores of recent points fast. A VM backup runs in two phases: first a snapshot of the disks is taken and kept alongside the disks (the snapshot tier), then the data is transferred to the vault (the vault-standard tier). A recovery point is usable as soon as the snapshot exists, and restoring from a point still held in the snapshot tier skips the slow copy back from vault storage. How long snapshots stay is a policy setting:

Restores are fast only for points still inside the snapshot window, so the window should cover however far back fast restores are expected; a window longer than five days is beyond a Standard policy and needs an Enhanced policy. Snapshots cost storage while they are kept, so retention is a speed-versus-cost choice. The vault's archive tier is the opposite end: cheap long-term storage for old monthly or yearly points, with slower restores.

Azure Backup protects Azure VMs, Azure Files shares, SQL Server and SAP HANA databases in Azure VMs, Azure Blobs, managed disks, PostgreSQL, and on-premises machines, keeping point-in-time recovery points you restore from after accidental deletion, corruption or ransomware. Azure VM backup is extension-based: Azure installs the backup extension on the VM, so you do not deploy an agent yourself.

Azure Disk Backup is a separate, agentless option in a Backup vault: it takes incremental snapshots of managed disks on a schedule, with no extension or agent inside the VM. The vault must be in the disks' region. It suits frequent, crash-consistent disk-level protection rather than application-consistent whole-VM backup.

For on-premises machines there are two paths, and the choice turns on whether you need application awareness and a backup server:

When you register a MARS agent you set an encryption passphrase. Data is encrypted with it before it leaves the server, and Microsoft cannot recover it — store it safely outside the server. To restore a lost server's data to a replacement machine, install the MARS agent there and use the another server recovery option with the vault credentials and the original passphrase; without the passphrase the data cannot be decrypted.

Soft delete keeps backup data recoverable after someone deletes it, by mistake or maliciously. It is on by default for Recovery Services and Backup vaults. On Recovery Services vaults it is now enforced (secure by default) and cannot be disabled through any client; the same enforcement is reaching Backup vaults region by region. When protection is stopped with delete backup data, the item and its recovery points move to a soft-deleted state instead of being purged.

• Retention: 14 days by default, at no charge. The soft-delete retention period is set per vault and can be raised to between 14 and 180 days; days beyond 14 are charged.
• Undelete: returns the item to the stop protection with retain data state. Recovery points are then restorable straight away, but no new backups run.
• Resume backup: to keep protecting the item in the same vault with its policy, select Resume backup after undeleting. A soft-deleted item cannot be protected again in the same vault until it has been undeleted (it can be protected in a different vault).

Soft delete protects backup data in the vault. It does not bring back a file deleted inside a running VM's file system — that is a restore from a recovery point. Together with immutable vaults and multi-user authorization (Resource Guard), soft delete is part of Azure Backup's ransomware protection.

Azure Backup offers several ways to restore a VM, and the right one depends on what was lost and what must be kept. Each restore starts by choosing a recovery point — one of the points your policy retained.

Restores normally target the VM's own region; with Cross Region Restore on a GRS vault you can also restore in the paired region.

Azure Files backup is snapshot-based and offers two levels: a full share restore (to the original or an alternate location) and an item-level restore of selected files or folders. A full share restore rolls the share back to the snapshot, overwriting files that changed after it was taken; an item-level restore brings back only the selected files or folders and leaves the rest of the share as it is now.

Azure Site Recovery (ASR) continuously replicates a virtual machine's disks to another Azure region so the workload can be brought up there if the source region fails. Its job is keeping a service available, not recovering a deleted file. Site Recovery can replicate between any two supported Azure regions, not only the region pair, and also protects on-premises VMware, Hyper-V and physical servers replicating into Azure.

When you enable Azure-to-Azure replication (from the VM's Disaster recovery page or from a Recovery Services vault in the target region), these pieces come into play:

• Mobility service extension — installed automatically on each VM; it captures disk writes.
• Cache storage account in the source region — changes are staged there before being sent to the target region, so the source VM's performance is not affected.
• Target settings — target resource group, virtual network, and replica managed disks in the target region.
• Replication policy — sets recovery point retention (how far back you can fail over; short, at most 15 days) and the app-consistent snapshot frequency.

Site Recovery creates two kinds of recovery point. Crash-consistent points are taken every few minutes and capture the disk as if power were cut; applications must run crash recovery when they start. App-consistent points are taken at the policy's frequency and, on Windows, use VSS to quiesce applications first, so a database starts cleanly — at the cost of being older than the newest crash-consistent point.

The recovery point objective (RPO) is the most data, measured in time, the business can afford to lose; the recovery time objective (RTO) is the longest the workload may be unavailable. Because replication is continuous, Site Recovery gives a low RPO and a short RTO. The two are independent: the RPO decides whether backups are frequent enough (data loss can never be smaller than the gap between recovery points) or replication is needed, while the RTO decides how fast and how automated the recovery must be.

A recovery plan controls how a set of replicated VMs fails over: it groups the VMs into ordered groups (for example database, then application, then web), fails each group over in turn, and runs pre-actions and post-actions around each group. An action is either an Azure Automation runbook, which runs automatically (updating a DNS record or connection strings, say), or a manual action, which pauses the plan until someone confirms the step is done. Whenever a step must happen with no human involved, use a runbook.

Multi-VM consistency controls something different: which point in time the VMs come back from. VMs in the same replication group share crash-consistent and app-consistent recovery points, so after failover they all reflect the same moment — needed when an application commits a transaction across several VMs. It adds processing overhead, so enable it only for VMs that need it.

A recovery plan can be run as a test failover too, which is how you prove the order and the runbooks work before a real event.

A failover brings replicated VMs up in the target region from a recovery point you choose. For Azure-to-Azure replication the portal offers two operations: Test failover and Failover. (A separate planned failover with zero data loss exists for some on-premises-to-Azure scenarios, not for Azure-to-Azure.)

Test failover is the disaster-recovery drill. It creates VMs from a recovery point in a non-production, isolated virtual network you select in the target region, while production and replication carry on untouched. When validation is finished, run Cleanup test failover to delete the test VMs and record notes. Test failover works for a single VM or a whole recovery plan.

Failover is the real switch. You pick the recovery point:

• Latest — processes all data received by Site Recovery first; lowest data loss, slowest start.
• Latest processed — the newest point already processed; fastest start.
• Latest app-consistent — the newest app-consistent point; applications start cleanly, with more data loss.
• Custom — any retained point you choose; available only when failing over a single VM, not through a recovery plan.

The Shut down machine before beginning failover option tries to shut down the failover source VMs first to avoid data loss; failover continues even if the shutdown fails. After failover you can change the recovery point, then Commit.

Failback returns the workload to the original region in four steps: (1) commit the failover; (2) Re-protect, which reverses replication so the VMs now replicate from the secondary region back to the primary; (3) run Failover towards the primary region; (4) Re-protect again to restore the original direction. Because failback syncs changes onto the original VMs' disks, the VMs in the primary region must be shut down before failing back; Site Recovery cannot write to the disks of a running original VM. Note that during failback the shutdown checkbox acts on the failover source, which is now the secondary-region VMs, so it does not stop the originals.

Azure Backup protects against data loss and corruption — it keeps point-in-time recovery points you restore from after an accidental deletion, a bad change, or ransomware. Azure Site Recovery protects against a region or site outage — it replicates your workload so you can fail over and keep running elsewhere. Backup brings your data back; Site Recovery keeps your service up.

Replication copies corruption. If a faulty script corrupts data, Site Recovery faithfully replicates the corruption to the secondary region, and once the bad change is older than the replication policy's retention there is no clean Site Recovery point left. Recovering from it is an Azure Backup restore from a recovery point taken before the incident. Likewise, Cross Region Restore (restoring backups in the paired region) is not a substitute for Site Recovery (keeping running VMs ready to fail over), and the reverse is also true.

Scenario: a production application must survive both a fat-fingered deletion and a full regional outage. You enable Azure Backup so you always have recovery points for files or whole machines, and you replicate the same VMs with Site Recovery so the workload can fail over if the region goes down. The two are complementary, not alternatives.

Backup monitoring has two parts: alerts tell you about a problem now, and Backup Reports show trends over time. Both are viewed at scale in Azure Business Continuity Center (shown in the portal as Resiliency), which has replaced Backup center as the single view across vaults, subscriptions and regions; each vault's Backup jobs page still shows individual job results.

Alerts. Azure Backup raises built-in Azure Monitor alerts by default for events such as backup and restore job failures and the deletion of backup data. They appear in the portal automatically, but they notify nobody on their own. To send an email or page, create an action group with the receivers and an alert processing rule whose scope covers the vaults (a subscription, for example) that attaches the action group to those alerts. You do not need to write a log alert rule for job failures.

Backup Reports. Reports read from a Log Analytics workspace, so each vault first needs a diagnostic setting that sends its backup data (resource-specific tables) to the workspace. Then open the Backup Reports workbook to see job success, backup items, cloud storage consumed and policy adherence. Plan for two details: the first data can take up to 24 hours to appear, and the workspace's retention (30 days by default) must be raised if you want a year of history.

At scale. Diagnostic settings are per vault, so configuring them by hand misses new vaults. Assign the built-in Azure Policy that deploys vault diagnostic settings to a Log Analytics workspace at a management group or subscription scope. Its DeployIfNotExists effect configures new vaults automatically, and a remediation task fixes existing ones. An Audit or AuditIfNotExists policy would only report vaults that lack the setting without changing anything.