An application can have healthy virtual machines and still be unavailable because its database is corrupt. It can have a recent backup and still be offline for hours because nobody has tested the restore path. It can have a regional replica and still fail when clients resolve a hostname that points to the original site. These are different failure contracts, not three names for the same protection.<\/p>\n
Consider a hypothetical payroll application made up of a web VM, a data service and internal name resolution. Its owners ask for three outcomes: maintain service through a single-server failure, recover a mistaken database update, and resume in another Azure region if the primary region becomes unavailable.<\/p>\n
For Microsoft AZ-104<\/a> recovery design, the solution may combine Azure services, but each must have a testable purpose. Microsoft’s AZ-104 blueprint<\/a> includes Recovery Services and Backup vaults, backup policies and restores, Site Recovery failover, and backup reports and alerts.<\/p>\n A second VM or availability-zone placement can reduce exposure to some compute faults but cannot reconstruct a deleted database record. Azure Backup retains eligible recovery points under a policy, enabling supported restoration. Azure Site Recovery supports replication and failover for qualifying workloads, with separate consistency and regional support requirements. A continuously replicated bad state can still be wrong; the existence of a replica should not be used to promise recovery from any logical data corruption.<\/p>\n Document the recovery point objective (RPO)<\/a>, or maximum acceptable data loss, and recovery time objective (RTO), or target time to return service, for each failure. A daily backup may meet a noncritical archive’s RPO but fail a payroll system whose accepted data-loss window is much shorter. Likewise, the presence of a replicated VM is not proof that clients, databases and identity services can resume within the desired RTO.<\/p>\n A Recovery Services vault manages protection for many supported workloads, including applicable Azure VM and Azure Files backup cases, and it is used in supported Site Recovery configurations. A Backup vault supports different Azure Backup data-source patterns. Choose the vault type after identifying the resource to protect; neither label guarantees that every Azure service can use it. Microsoft’s Azure Backup support matrix<\/a> is the correct reference for workload-specific limits and supported vault types.<\/p>\nWrite down the failure before choosing the protection service<\/h2>\n
\n\n
\n \nIncident<\/th>\n Primary question<\/th>\n Evidence that recovery is usable<\/th>\n<\/tr>\n<\/thead>\n \n One web VM becomes unavailable<\/td>\n Can another serving instance accept traffic without losing required state?<\/td>\n Healthy app response and authorized dependency access<\/td>\n<\/tr>\n \n Database contents are damaged<\/td>\n Which eligible prior recovery point preserves needed business data?<\/td>\n Restored records and tested application consistency<\/td>\n<\/tr>\n \n Primary region fails<\/td>\n Can a supported application dependency chain operate at the target site?<\/td>\n Booted workloads, correct DNS\/network, database and user requests<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n Select the vault for the supported data source<\/h2>\n