Chapter 10

Backup & disaster recovery

The last chapter protects what you built: Azure Backup for "I deleted something" and Azure Site Recovery for "the whole region is down". It ends with a full cleanup of the lab, which is a good exercise in itself: locks, soft delete and replication all try to stop you.

Backup or disaster recovery?

Two numbers drive every design in this area:

• RPO (recovery point objective): how much data you can afford to lose, measured in time. "RPO 24 hours" means a daily backup is fine.
• RTO (recovery time objective): how long the service may be down while you recover.

Most production workloads use both: Site Recovery to survive a region outage, Backup to recover from mistakes. Replication faithfully copies a deletion or ransomware encryption too, so it's not a backup.

Two kinds of vault

Backups are stored in a vault. There are two types, and the exam asks which one protects what:

Both are managed together in Azure Business Continuity Center (formerly Backup center), which gives one view of protected items, jobs, policies and alerts across vaults and subscriptions.

Vault settings that matter

• Storage redundancy: GRS (default), ZRS or LRS. You can only change it before the first item is protected.
• Cross Region Restore (GRS vaults): restore in the paired region at any time, not just after Microsoft declares a disaster.
• Soft delete: deleted backup data is kept for 14 days (configurable in enhanced soft delete) so an attacker or mistake can't wipe your backups. It can be made always-on (irreversible).
• Immutable vault: prevents operations that would reduce retention or delete recovery points.
• Multi-user authorization with a Resource Guard: critical operations (like disabling soft delete) need approval from a second person in another tenant or subscription.

Backing up Azure VMs

When you enable backup on a VM, Azure installs a backup extension. At backup time it takes a snapshot of the disks (an instant restore point that stays next to the VM for fast restores) and then transfers the data to the vault.

Backup policies

• Standard policy: one backup per day (or week).
• Enhanced policy: backups every 4, 6, 8, 12 or 24 hours, instant restore points kept up to 30 days, and support for Trusted launch VMs, Premium SSD v2 and Ultra disks. Trusted launch VMs need the Enhanced policy, so your lab VMs do.
• Retention: daily, weekly, monthly and yearly points, up to 99 years.

Consistency: Windows backups are application-consistent using VSS. Linux backups are file-system consistent, or application-consistent if you add pre/post scripts. If the VM is off, the backup is crash-consistent.

You can also run Backup now (an on-demand backup with its own retention date), for example before a risky change.

Restore options

Files, blobs and on-premises

• Azure Files (Recovery Services vault): based on share snapshots taken on a schedule. Restore the whole share or individual files, to the original or another location. A newer vaulted tier also copies the data into the vault.
• Azure Blobs (Backup vault):
  • Operational backup: continuous, kept in the storage account itself (using soft delete, versioning, change feed and point-in-time restore). Protects against deletion/corruption, but not against losing the account.
  • Vaulted backup: scheduled copies into the Backup vault, so they survive deletion of the account.
  The vault's managed identity needs the Storage Account Backup Contributor role on the account.
• On-premises: the MARS agent backs up files, folders and system state of Windows machines directly to a Recovery Services vault. For applications (SQL, Exchange, Hyper-V) use MABS or DPM.

Backup reports and alerts

• Backup jobs in the vault or Business Continuity Center show each job's status, duration and errors.
• Built-in Azure Monitor alerts for backup (job failures, security events like "soft delete disabled") are generated automatically. To get notified, route them to an action group with an alert processing rule (chapter 9). The old "classic" backup alerts are being retired.
• Backup reports (trends in storage, jobs, policies, optimisation) need a diagnostic setting on each vault sending data to a Log Analytics workspace in resource-specific mode.

Azure Site Recovery

Azure Site Recovery (ASR) continuously replicates VMs to another region (or on-premises VMware, Hyper-V and physical servers to Azure), so you can fail over when the primary site is unavailable.

Setting it up

1. Create a Recovery Services vault in the target region.
2. Enable replication for the VMs: choose the target region, resource group, VNet (network mapping), availability (zone/set), and a replication policy.
3. The replication policy sets recovery point retention (up to 15 days) and how often app-consistent snapshots are taken.
4. Group VMs into a recovery plan: the order in which they start (database before web tier), plus manual actions or Automation runbooks (e.g. update DNS).

Failover types

• Test failover: creates the VMs in an isolated VNet you choose. Replication continues, production isn't affected. Do this regularly to prove DR works, then Cleanup test failover.
• Failover (unplanned): for a real disaster. You pick a recovery point: Latest (lowest RPO, slower), Latest processed (lowest RTO), Latest app-consistent, or a custom point.
• After failover: Commit (no more switching to other recovery points), then Re-protect (replicate back from the DR region), and later fail back to the primary region.

Self-check

Some jobs here (the first VM backup, initial ASR replication) take 30–60 minutes in the background. Start them, continue with the next steps, and come back. Paste the variables first:

RG=rg-az104-lab; LOC=westeurope; LOC2=northeurope; INIT=xx
ST=staz104${INIT}01
az vm start -g $RG -n vm-web1 --no-wait; az vm start -g $RG -n vm-web2 --no-wait

1. Task

   Back up vm-web1

   Create a Recovery Services vault rsv-az104 in the right region for backing up vm-web1, with LRS storage (to save cost in this lab). Protect vm-web1 with a policy that fits a Trusted launch VM, keeping daily points for 7 days, and start a backup now.

   Done when

   • vm-web1 appears under Backup items, and a Backup job is running or completed.
   • You know why the storage redundancy had to be set before protecting the VM.
   Solution · Portal

   1. Create a resource → Backup and Site Recovery (Recovery Services vault): rsv-az104, region westeurope (same as the VM).
   2. Vault → Settings → Properties → Backup Configuration → Update: Locally-redundant → Save.
   3. Vault → Backup: Azure, Virtual machine → policy subtype Enhanced → create policy pol-vm-enhanced (every 24 hours, daily retention 7 days, instant restore 2 days) → add vm-web1 → Enable backup.
   4. Backup items → Azure Virtual Machine → vm-web1 → Backup now.
   Solution · Azure CLI

   az backup vault create -g $RG -n rsv-az104 -l $LOC
   az backup vault backup-properties set -g $RG -n rsv-az104 --backup-storage-redundancy LocallyRedundant
   az backup policy list -g $RG -v rsv-az104 --query "[].{name:name, type:properties.policyType}" -o table
   # New vaults include "EnhancedPolicy"; if not, create one in the portal.
   az backup protection enable-for-vm -g $RG -v rsv-az104 --vm vm-web1 --policy-name EnhancedPolicy
   az backup protection backup-now -g $RG -v rsv-az104 -c vm-web1 -i vm-web1 \
     --backup-management-type AzureIaasVM --retain-until $(date -u -d '+7 days' +%d-%m-%Y)
   az backup job list -g $RG -v rsv-az104 -o table

2. Task

   Back up the file share and restore a single file

   Protect share1 (chapter 7) in rsv-az104 with a daily policy and take an on-demand backup. Then delete from-vm.txt from the share and restore only that file from the backup.

   Done when

   • from-vm.txt is back in share1.
   • You noticed that the storage firewall didn't block Azure Backup. Which exception allowed it?
   Solution · Portal

   1. Vault → Backup: Azure, Azure Files (Azure Storage) → select storage account → Add share1 → policy (default daily is fine) → Enable backup.
   2. Backup items → Azure Storage (Azure Files) → share1 → Backup now.
   3. Delete from-vm.txt in the portal (Storage account → File shares → share1).
   4. Backup item → File Recovery → restore point → Original location → Add file → from-vm.txt → Restore.

   The exception Allow Azure services on the trusted services list (chapter 7, step 7).

3. Task

   Protect the blobs with a Backup vault

   Create a Backup vault bvault-az104 and configure operational backup of the blobs in your storage account, with 7 days retention. The vault needs a permission on the storage account; let the portal grant it.

   Done when

   • The backup instance for your storage account shows Protection configured.
   • You can name the role the vault received.
   Solution · Portal

   1. Create a resource → Backup vault: bvault-az104, region westeurope, redundancy LRS.
   2. Vault → + Backup → datasource Azure Blobs (Azure Storage) → policy: new, Operational, 7 days → select the storage account.
   3. Validation shows the missing role → Assign missing roles (it assigns Storage Account Backup Contributor to the vault's managed identity) → wait a minute → Revalidate → Configure backup.
4. Task

   Hear about backup problems

   Make sure that built-in backup alerts for rsv-az104 reach ag-az104-email (chapter 9), and that Backup reports get data from the vault in log-az104.

   Done when

   • An alert processing rule routes backup alerts to the action group.
   • rsv-az104 has a diagnostic setting to log-az104 in resource-specific mode.
   Solution · Portal

   1. Monitor → Alerts → Alert processing rules → Create: scope rsv-az104, rule type Apply action group → ag-az104-email, schedule Always, name apr-backup-notify.
   2. rsv-az104 → Monitoring → Diagnostic settings → Add: tick the Azure Backup reporting categories (CoreAzureBackup, AddonAzureBackupJobs, AddonAzureBackupPolicy, AddonAzureBackupStorage, AddonAzureBackupProtectedInstance…), destination log-az104, Resource specific.
   3. Later: Business Continuity Center → Reports (data appears after a few hours).
5. Task

   Replicate vm-web2 to the DR region

   Set up Site Recovery for vm-web2 to northeurope. Create the vault rsv-az104-dr in the right region, and let Site Recovery create the target resource group and VNet. Initial replication takes a while; carry on with step 6 while it runs.

   Done when

   • rsv-az104-dr → Replicated items shows vm-web2 with status Protected (after initial sync).
   • You can say why this vault is in a different region from rsv-az104.
   Solution · Portal

   1. Create a Recovery Services vault rsv-az104-dr in northeurope (target region), resource group rg-az104-lab.
   2. vm-web2 → Backup + disaster recovery → Disaster recovery: target region northeurope → Advanced settings: target subscription, resource group (new, e.g. rg-az104-lab-asr), virtual network (new, created by ASR), availability zone, vault rsv-az104-dr, replication policy (default 24-hour retention) → Start replication.

   For DR, the vault goes in the target region so it's available when the source region isn't.

6. Task

   Practise restores while you wait

   When the vm-web1 backup job has finished: find the restore options for a recovery point, and generate (don't run) the File Recovery script. Decide which option you'd use to (a) get one config file back, (b) roll back the whole VM in place, (c) inspect the old disks without touching production.

   Done when

   • You've seen the restore wizard and can answer (a), (b) and (c).
   Solution · Portal

   rsv-az104 → Backup items → vm-web1: Restore VM shows Create new (virtual machine or Restore disks) and Replace existing; File Recovery → pick a point → Download Executable (a script plus password that mounts the point via iSCSI). Answers: (a) File Recovery, (b) Replace existing, (c) Restore disks.

7. Task

   Run a disaster recovery drill

   When vm-web2 is Protected: create an isolated VNet vnet-dr-test (10.99.0.0/16) in the DR region and run a test failover of vm-web2 into it with the latest processed recovery point. Check the test VM runs, then clean up the test failover.

   Done when

   • A VM vm-web2-test ran in northeurope while production kept running.
   • After cleanup, the replicated item is back to Protected without a test VM.
   Solution · Portal

   1. Create VNet vnet-dr-test (10.99.0.0/16, one subnet 10.99.1.0/24) in rg-az104-lab-asr, region northeurope.
   2. rsv-az104-dr → Replicated items → vm-web2 → Test failover: recovery point Latest processed, VNet vnet-dr-test → OK.
   3. When the job finishes, look at the VM in the DR resource group (Run command hostname; curl -s localhost).
   4. Replicated item → Cleanup test failover → add a note, tick Testing is complete → OK.

Cleanup: delete the whole lab

When you're done (and only then), remove everything so it stops costing money. This is also a lesson: locks, soft delete and replication all block deletion, in that order of surprise.

1. Task

   Stop Site Recovery and Backup properly

   Disable replication of vm-web2. In both Recovery Services vaults and the Backup vault, disable soft delete first, then stop protection and delete the backup data of every item.

   Done when

   • All three vaults have zero protected and zero soft-deleted items.
   If an item is already soft-deleted

   Turn off soft delete, Undelete the item, then Stop backup → Delete backup data again. If soft delete was set to always-on, you have to wait for the retention period (14 days) to end.

   Solution · Portal

   1. rsv-az104-dr → Replicated items → vm-web2 → Disable replication.
   2. rsv-az104 → Properties → Security settings → Soft delete and security settings → Update: untick soft delete (for cloud workloads) → Update.
   3. Backup items → each item → Stop backup → Delete backup data (type the item name). Also Backup infrastructure → Storage accounts → Unregister the storage account.
   4. Same for bvault-az104: Properties → soft delete off; Backup instances → Delete.
   Solution · Azure CLI (Recovery Services vault)

   az backup vault backup-properties set -g $RG -n rsv-az104 --soft-delete-feature-state Disable
   az backup protection disable -g $RG -v rsv-az104 -c vm-web1 -i vm-web1 \
     --backup-management-type AzureIaasVM --delete-backup-data true --yes
   az backup item list -g $RG -v rsv-az104 -o table      # repeat disable for any remaining item

2. Task

   Remove what lives outside the resource group

   Some things you created aren't in rg-az104-lab. Find and remove them: the lock on vnet-hub (it blocks the group's deletion), the subscription diagnostic setting, the ASR resource group, and optionally the budget and management group.

   Done when

   • az lock list -g rg-az104-lab returns nothing.
   • No diagnostic setting on the subscription points at log-az104.
   Solution · Azure CLI

   az lock delete -n lock-hub-nodelete -g $RG --resource-name vnet-hub --resource-type Microsoft.Network/virtualNetworks
   az monitor diagnostic-settings subscription delete -n diag-activity --yes
   az group list --query "[?contains(name,'az104') || contains(name,'asr')].name" -o tsv
   az group delete -n rg-az104-lab-asr --yes --no-wait       # the DR resource group from step 5
   # optional: Cost Management → Budgets → delete budget-az104-lab
   # optional: az account management-group delete -n mg-az104-lab

   If you did the optional DNS task: also delete the four lab NS records at your registrar. The Azure DNS zone itself is deleted with the resource group.

3. Task

   Delete the resource group

   Delete rg-az104-lab. If it fails, the error message tells you what is still blocking it (a lock, a vault with items, a resource in use).

   Done when

   • az group exists -n rg-az104-lab returns false. The Container Apps environment's managed resource group disappears with it.
   Solution · Azure CLI

   az group delete -n $RG --yes
   az group exists -n $RG

4. Task

   Clean up Entra ID

   Delete Ada, Ben, the guest, both groups, set SSPR back to None (if this is the state you started with), and remove the trial license if you don't want it.

   Solution · Azure CLI

   DOMAIN=$(az rest --url https://graph.microsoft.com/v1.0/domains --query "value[?isDefault].id" -o tsv)
   az ad user delete --id az104-ada@$DOMAIN
   az ad user delete --id az104-ben@$DOMAIN
   az ad group delete -g az104-admins
   az ad group delete -g az104-dept-it
   # guest and SSPR: Entra admin center → Users / Protection → Password reset