AZ-305 Backup and Disaster Recovery Design: Site Recovery, Azure Backup, Database and Storage Recovery

Backup and disaster recovery (DR) design decides how much data a workload may lose and how fast it must run again after a failure, and then picks the Azure service that meets those two numbers for each failure you need to survive. The two numbers are the recovery point objective (RPO), the maximum acceptable data loss measured in time, and the recovery time objective (RTO), the maximum acceptable time until the workload runs again. The official task has four skills: recommend a recovery solution for Azure and hybrid workloads that meets recovery objectives, and recommend backup and recovery solutions for compute, for databases and for unstructured data.

Three questions shape every design:

• What failure must be survived? An accidental deletion, data corruption or ransomware, the loss of one datacenter (an availability zone), or the loss of a whole region.
• What are the RPO and RTO for this workload? Minutes or hours, and do they apply in the same region or another one?
• What else is required? Data residency, how long copies must be kept, who may delete them, cost and administrative effort.

Keeping a workload running through a single component or zone failure without any failover step is high availability (availability zones, zone-redundant services, replicas). It is the sibling task, covered in the AZ-305 high availability lesson; this lesson treats zones only where they set the scope of a recovery.

Replication meets tight RPO and RTO; backup meets long retention and recovery from bad data; a workload that needs both gets both. Azure Site Recovery continuously replicates VM disks to a target region or zone and keeps recovery points only for a short window (up to 15 days for Azure VMs). Failing over starts the replicated VMs, so the RPO is minutes and the RTO is the time to boot and reconnect. Azure Backup takes periodic copies (daily, or every few hours with an Enhanced VM policy) and keeps them for the retention you set, from days to years. Its RPO is hours, and a restore from the vault takes longer than starting a replica.

Two consequences come up constantly. First, replication is not a backup: a deletion or encryption by ransomware is copied to the replica within minutes, so a requirement to recover a state from weeks ago needs Azure Backup even when Site Recovery is in place. Second, backup is not DR for tight objectives: a geo-redundant vault with Cross Region Restore gets backups into the paired region, but its RPO is still the backup interval.

Failure scope and residency

The failure scope picks the target. Region-to-region Site Recovery protects against the loss of a region. Zone-to-zone disaster recovery uses Site Recovery to replicate VMs to another availability zone in the same region; it suits single-instance VMs that can't be rebuilt for active-active and data that must not leave the region, and it doesn't protect against a full regional outage. Backups stored in a zone-redundant vault likewise stay in the region but keep a backup-level RPO.

Tier recovery by criticality

The Azure Well-Architected Framework's reliability guidance asks you to classify workloads by criticality and set recovery targets per tier, because the strictest mechanism for everything is the most expensive design. A common outcome: Site Recovery only for mission-critical workloads whose RPO is minutes, Azure Backup to a geo-redundant vault with Cross Region Restore for workloads that must be restorable in another region within a day or so, and locally redundant backup for workloads that only need in-region restores. Each workload gets the cheapest mechanism that meets all of its objectives, and DR drills prove the targets are met.

For Azure VMs, Site Recovery replicates every disk to a target region (or zone) and lets you fail over a single VM or a whole application in a controlled order. You enable replication per VM; the Site Recovery Mobility service extension is installed on the VM automatically, and changes are sent continuously to cache storage and then to replica managed disks in the target. Nothing runs in the target until you fail over, so you pay mainly for storage there.

• Recovery points: crash-consistent points are created every five minutes; app-consistent points (which flush in-memory application data) are created at a frequency you choose in the replication policy, no more often than hourly. Points are kept for up to 15 days.
• Multi-VM consistency: put VMs that write related data into a replication group so they share crash-consistent and app-consistent recovery points and fail over to the same point in time. It adds CPU overhead on the VMs, so use it only where the application needs it.
• Recovery plans: group VMs, start the groups in order (for example database, then application, then web tier) and add manual actions or Azure Automation runbook scripts before or after a group, for example to update a DNS record or a load balancer.
• Test failover: starts VMs in the target from a chosen recovery point without stopping replication or touching production. Point it at a virtual network isolated from production so the copies can't conflict with live systems, then clean up the test failover. This is how you run audit drills.
• Failover, commit and failback: a real failover starts the VMs in the target; after you commit, they run unprotected. Re-protect reverses replication back to the original region, reusing the original disks where they still exist so only changes are sent. When the VMs are in sync, fail over again to return, then re-protect once more to restore the original direction.

Site Recovery protects the VMs, not PaaS services. Azure SQL Database, Cosmos DB and storage accounts use their own geo-replication or backup features, described below, and a recovery plan's scripts can orchestrate them alongside the VMs.

Site Recovery can use Azure as the secondary site for an on-premises datacenter: it replicates VMware VMs, Hyper-V VMs and physical servers to Azure, fails them over when the datacenter is lost and fails them back on-premises afterwards. The components you deploy depend on the source.

Replication from VMware and Hyper-V gives an RPO of minutes, and recovery plans, test failover and failback work as they do for Azure VMs. For VMware failback, the VMs replicate back to the on-premises site through the appliance before a planned failover returns them.

Keep three neighbours apart. Azure Migrate (with its appliance and the Migration and modernization tool) moves servers to Azure once; it is not an ongoing DR service with failback. Azure Backup Server and the MARS agent keep periodic backups and restore slowly. Azure File Sync synchronises file shares; it doesn't replicate whole servers.

Azure Backup stores recovery points in one of two vault types, and which one depends on the workload: a Recovery Services vault for VMs, SQL Server and SAP HANA in VMs, Azure Files and on-premises servers, and a Backup vault for newer workloads such as blobs, managed disks, AKS and Azure Database for PostgreSQL.

One vault of the right type can protect several of the workloads in its column, so you only need a second vault when a design mixes workloads from both columns, not one vault per workload. A vault that backs up Azure VMs must be in the same region as the VMs.

Storage redundancy and Cross Region Restore

A vault stores its data with locally redundant (LRS), zone-redundant (ZRS) or geo-redundant (GRS) storage. Set the redundancy before you protect anything: once backup items are configured in a Recovery Services vault, the setting can no longer be changed. To move to GRS later, protect future backups in a new GRS vault and stop protection in the old vault while retaining its data, so existing recovery points stay restorable until they expire; recovery points can't be moved between vaults.

Cross Region Restore (CRR) lets you restore from the copy in the paired region at any time, not only after Microsoft declares an outage, so it also supports drills. It requires a GRS vault. It is supported for Azure VMs, SQL Server and SAP HANA in VMs, and Azure Files vault-standard backups in Recovery Services vaults, and for the vault tier of supported Backup vault workloads such as AKS. ZRS keeps copies across zones in the same region, which survives a datacenter loss and meets in-region residency, but doesn't help in a regional outage.

Soft delete, immutability and multi-user authorization

MUA protects vault operations with a separate Azure resource, the Resource Guard, owned by a different team and optionally placed in another subscription or tenant, so a compromised vault administrator can't act alone. A locked immutable vault is an absolute block that nobody, including your own administrators, can remove. Soft delete is the safety net for anything that is deleted. Ransomware-resilient designs combine them.

Each kind of Azure compute has its own backup mechanism: Azure VM backup for whole VMs, Azure Disk Backup for individual managed disks, Azure Backup for AKS for clusters, and the App Service backup feature for web apps.

Azure VM backup: Standard and Enhanced policies

Azure VM backup installs a backup extension, takes a snapshot (application-consistent on Windows through VSS, file-system consistent or with pre/post scripts on Linux) and transfers it to a Recovery Services vault. Recent recovery points are also kept as snapshots for instant restore, which is much faster than restoring from the vault tier.

So a need for backups every few hours, for fast snapshot restores beyond five days, or for Premium SSD v2 and Ultra disks points to the Enhanced policy, with the instant restore retention raised when the default isn't enough. Even the Enhanced policy stops at every four hours, so it can't give an RPO of minutes.

Azure Disk Backup

Azure Disk Backup protects individual managed disks without any agent or extension in the VM. It is configured from a Backup vault, takes incremental, crash-consistent snapshots on a schedule of every 1, 2, 4, 6, 8 or 12 hours or daily, and keeps them in a resource group you choose (the operational tier only, so there is no vault copy). It can run side by side with a daily VM backup, which makes it the fit for frequent recovery points of one data disk where agents are forbidden.

Azure Backup for AKS

AKS backup protects cluster resources and persistent volumes. It needs the Backup extension installed in the cluster, configured with a storage account and blob container that hold the backed-up Kubernetes resources, and Trusted Access between the cluster and a Backup vault. Backups first land in the operational tier: disk snapshots plus the blob container in the source region and your subscription. You can also move one recovery point a day to the vault tier, stored outside your tenant. The vault's LRS or GRS setting applies only to the vault tier, so restoring to a standby cluster in the paired region needs vault-tier retention in a GRS Backup vault with Cross Region Restore. The vault tier currently supports Azure Disk persistent volumes only. Backing up node pool VMs or replicating them with Site Recovery doesn't capture the application's Kubernetes state.

App Service backup

App Service has its own backups of an app's files and configuration; Azure Backup does not protect App Service apps.

When a requirement names your own storage, a different schedule or retention beyond 30 days, custom backups are the built-in way; for retention longer than 30 days, keep backups indefinitely and remove old ones with your own process, such as a storage lifecycle rule. Exporting an ARM template captures configuration but not the app's content.

On-premises servers back up to Azure with either the Microsoft Azure Recovery Services (MARS) agent, which sends files straight to the cloud, or Microsoft Azure Backup Server (MABS), which adds application-aware protection and a local disk copy. Both store their offsite copies in a Recovery Services vault.

A small estate that wants files and system state in Azure with no extra server fits MARS. Application-consistent backups of databases or hypervisors with fast local restores fit MABS (or System Center DPM, which works the same way). The Azure Backup workload features for SQL Server in Azure VMs need the workload to run in Azure, so they don't protect on-premises databases, and Site Recovery replicates for failover rather than keeping backup history.

Servers that use Azure File Sync with cloud tiering are the exception. A tiered server holds only part of the data set, and Microsoft's guidance is not to back it up with an on-premises solution, because tiered files are recalled or captured as stubs. Back up the Azure file share (the cloud endpoint), which always holds the full data set; a lost server is replaced by installing the File Sync agent on a new server and letting it sync.

Azure SQL Database and SQL Managed Instance back themselves up automatically; your design chooses how long backups are kept, where they are stored, and whether regional recovery uses backups (geo-restore) or a live secondary (geo-replication or failover groups).

• Point-in-time restore (PITR): full, differential and log backups support restoring to any point within a retention of 1 to 35 days (7 by default), as a new database.
• Long-term retention (LTR): a policy keeps weekly, monthly and yearly full backups for up to 10 years in the service's storage, restorable as a new database, with no scripts or exports to manage.
• Backup storage redundancy: LRS, ZRS or GRS (geo-zone-redundant where offered). The default is geo-redundant, which copies backups to the paired region and enables geo-restore. Choosing LRS or ZRS keeps backups in the region for residency but removes geo-restore. The setting also applies to LTR backups. For most tiers you can change it later and the change applies to future backups; for Hyperscale it can be set only when the database is created, so an existing Hyperscale database gets new redundancy by creating a geo-replica or copy with the required setting and switching to it.

Choosing a regional recovery option

Relaxed objectives measured in hours at the lowest cost fit geo-restore from the default geo-redundant backups. Tight objectives need a live secondary. When several databases must fail over together, or applications must not change connection strings, a failover group adds that on top of geo-replication. SQL Managed Instance doesn't support per-database active geo-replication: its regional DR feature is the failover group, which pairs two instances, and its read-only listener can send reporting to the secondary during normal operation. Zone redundancy and read scale-out replicas are high availability within one region.

Databases that Azure doesn't fully manage, or that use their own backup models, each have a specific option: workload backup or Automated Backup for SQL Server on VMs, periodic or continuous mode for Cosmos DB, and geo-redundant built-in backups plus Azure Backup for PostgreSQL and MySQL flexible servers.

SQL Server on Azure VMs

Workload backup fits central management alongside other VM backups, fine-grained restores and retention of years. Automated Backup fits teams that want native backup files in their own storage, managed with lifecycle rules, and no vault. A VM-level backup alone can't restore one database to a point in time.

Azure Cosmos DB

Every Cosmos DB account uses one of two backup modes.

• Periodic (the default): full backups at an interval, by default every four hours keeping the last two. Interval and retention are configurable. Backup storage redundancy is geo-redundant by default and can be changed to zone-redundant (survives a datacenter loss, stays in the region) or locally redundant. Restores are requested from Azure support.
• Continuous: self-service point-in-time restore of an account, database or container, including deleted ones, through the portal, CLI, PowerShell or templates. The 7-day tier has no backup storage charge (restores are charged); the longer tiers add backup storage charges. Continuous backup isn't supported for the API for Apache Cassandra, so a Cassandra account tunes its periodic interval and retention to meet its RPO instead.

Adding regions to a Cosmos DB account is replication: it helps with regional outages but copies a bad write or deletion straight away, and it moves data to another region.

Azure Database for PostgreSQL and MySQL flexible server

Flexible servers back up automatically, with built-in retention of up to 35 days (7 by default), stored zone-redundantly in regions with availability zones and locally redundant elsewhere. Choosing geo-redundant backup storage copies backups and logs to the paired region and enables geo-restore when the primary region is unavailable. For PostgreSQL flexible server this option is available only when the server is created, so it belongs in the initial design. Retention beyond 35 days for PostgreSQL flexible server comes from Azure Backup in a Backup vault, which keeps long-term backups for up to 10 years. Zone-redundant high availability and longer built-in retention don't move backups out of the region.

Unstructured data is protected at two levels: local features inside the storage account for fast, in-place recovery, and vaulted backups copied outside the account so they survive its deletion or a ransomware attack. Storage redundancy (LRS through RA-GZRS) protects against hardware, zone and region failure, but it replicates deletions and overwrites, so it is not a backup.

Azure Blob backup

One backup policy in a Backup vault can enable both tiers on the same account: operational backup for rolling back to any moment, vaulted backup for daily offsite copies kept for months or years. Object replication and versioning on their own keep copies but aren't managed backups.

Azure Files backup

Azure Backup protects Azure file shares from a Recovery Services vault with two tiers:

• Snapshot tier: share snapshots kept in the storage account. Restores are fast, but the backups are tied to the account.
• Vault-standard (vaulted) tier: changed data is also copied to the Recovery Services vault, so backups survive account deletion or ransomware, and with a GRS vault and Cross Region Restore they can be restored in the paired region.

Soft delete for file shares is a storage account setting that keeps a deleted share, with its contents and snapshots, for a retention period you choose so it can be undeleted. It is cheap and needs no backup infrastructure. Blob soft delete and blob point-in-time restore don't cover file shares, and a resource lock blocks only management-plane deletes. With Azure File Sync, protect the cloud endpoint, the Azure file share; restored files sync down to the servers.