A manufacturer runs a line-of-business virtual machine, a managed Azure SQL database, and a shared file repository. Its DR requirement says it can lose at most fifteen minutes of orders and must recover customer service in two hours. The infrastructure team proposes Azure Backup for all three and calls the problem solved when nightly jobs succeed. The proposed backup schedule cannot meet the data-loss target, and it says nothing about application routing after a regional outage. Backup and disaster recovery are connected, but not interchangeable.<\/p>\n
Microsoft AZ-305<\/strong> tests designing backup\/recovery for compute, databases and unstructured data, as well as service-specific high availability. The existing paired-region disaster-recovery specialist<\/a> covers regional placement and broad patterns. Here the goal is to map actual RTO and RPO to Azure Backup, Azure Site Recovery, database-native protection, and a tested restore sequence without claiming one mechanism protects every failure class.<\/p>\n RPO is the maximum tolerable data loss measured in time; RTO is the maximum acceptable time before service is restored. Both belong to a business operation, not just a virtual machine. A two-hour RTO includes getting the database writable, recovering necessary secrets, routing users to a working endpoint, replaying queued work safely and confirming the actual transaction path. The recovery clock does not stop when a VM powers on.<\/p>\n Different components may need different protection. Stateless web nodes can be recreated from deployment code, while an order ledger may need frequent transaction-log recovery. A data lake of reproducible extracts can accept longer restoration. Write those distinctions before buying replication or backup storage, then identify where time and data loss actually accrue in the workflow.<\/p>\n Azure Backup supports policy-driven protection for supported Azure and hybrid workloads through appropriate vault and data-source models. Backup can help recover after accidental deletion, data corruption, ransomware exposure or infrastructure failure where a usable historical point is required. The Azure Backup overview<\/a> describes protection policies and recovery mechanisms. Confirm supported workload, region, retention and vault type instead of assuming all Azure services have identical backup behavior.<\/p>\n For a virtual machine, design a backup policy and restore permissions, not just a green job history. Determine which files, disks or complete machine can be recovered, how much downtime restores require, and whether application-level consistency is guaranteed for the chosen workload. A weekly restore test may reveal missing drivers, stale configuration or a broken domain trust even when every backup job succeeded.<\/p>\n Azure supports different backup vault constructs and workload features. A Recovery Services vault is common for Azure VM and traditional workload backup and integrates with relevant recovery capabilities; a Backup vault supports selected newer workload protection models. They are not simply interchangeable labels or a reason to move every existing backup. Choose the vault type after confirming support for the specific resource and recovery feature.<\/p>\n Keep retention policy, administrator roles, soft-delete controls, immutability where supported, and encryption-key management aligned with the asset classification. A privileged application operator should not necessarily be able to delete protected recovery points. Separate routine backup monitoring from destructive backup administration and test that the designated emergency role can actually perform a restore.<\/p>\n Azure Site Recovery can replicate supported virtual machines and coordinate supported disaster-recovery failover workflows. Its purpose is different from a historical point-in-time backup: replication and failover can reduce restoration work for infrastructure disruption, but replication may also carry logical corruption or damaging configuration changes. Retain independently protected historical recovery points when the business needs to undo earlier data states.<\/p>\n Site Recovery design must map source\/target networks, identity, test failover isolation, storage, protection policy, and recovery plans. A test failover should not change production DNS or start duplicate writers against the same live database. Measure how long the application actually becomes usable in the target and which manual steps remain in the runbook.<\/p>\n Azure SQL Database and Managed Instance have engine and service-specific backup, point-in-time restore, retention and geo-replication capabilities. SQL Server on Azure VMs has another operating model. Map all relevant options against data-loss tolerance and recovery time rather than assuming VM-level backup is sufficient for every transaction. Restoring a virtual disk does not necessarily recover a consistent database at the desired point.<\/p>\nAssign recovery objectives per business service<\/h2>\n
Use Azure Backup for historical recovery points<\/h2>\n
Distinguish Recovery Services vaults from Backup vaults<\/h2>\n
Use Site Recovery for orchestration and ongoing replication<\/h2>\n
Choose database-native recovery for data integrity<\/h2>\n