A daily VM backup is valuable when someone deletes a configuration file, but it may not meet the business requirement to bring an entire application online within minutes after a datacenter fails. Azure Site Recovery addresses a different class of problem: replication, failover and orchestration for supported workloads. The Microsoft AZ-104 exam covers both protection and operational recovery, so an administrator must distinguish backup retention from a disaster-recovery execution path.
Consider a billing application with two application servers, a database and a private network dependency. Restoring the servers individually is not enough if DNS still directs customers to the failed location or the database is inconsistent. Recovery has an order, and Site Recovery can help coordinate it within its supported scenarios.
Start with RTO and RPO, not a vault
Recovery time objective (RTO) describes how long the business can tolerate the service being unavailable. Recovery point objective (RPO) describes acceptable data loss measured in time. These requirements are related but different. A faster failover does not guarantee that no data is lost, and a frequent backup does not guarantee the workload can be restored within the required time.
Ask a business owner whether losing the last few minutes of transactions is acceptable and whether the service must return within an hour or a working day. Verify the dependency chain: identity, networking, name resolution, application tiers, databases and integrations. Only then choose replication and recovery mechanisms. Test the complete application rather than declaring success when a recovered VM reaches the Azure ‘Running’ state.
A business owner may require service recovery within one hour and tolerate no more than fifteen minutes of lost transactional history. These requirements are RTO and RPO, not Azure product features. Before configuring Site Recovery, identify the complete service: application VMs, databases, DNS, identities, network routes, encryption keys, external integrations and the people authorized to invoke failover. A replicated VM that boots in the secondary region may still be unable to serve users because the database or private DNS resolver is missing. Recoverability must be evaluated at the business-transaction boundary, not at the infrastructure dashboard.
Distinguish Azure Backup and Site Recovery
Azure Backup is designed for supported backup and restore workflows, with policies, recovery points and retention. Azure Site Recovery manages replication and failover for supported physical and virtual workloads and can orchestrate application recovery. Neither makes the other unnecessary; organizations may use both to address different risk classes.
Replication can propagate undesired writes or logical corruption, while a retained backup may preserve an earlier clean state. Conversely, restoring every system from backup can take too long for a low-RTO application. Evaluate threats such as accidental deletion, ransomware, host loss, zone loss and region outage separately. A strong recovery strategy maps each threat to a protection that has been practiced, not to a generic ‘cloud is redundant’ statement.
Azure Backup and Azure Site Recovery can protect the same environment against different risks. Backup offers retained recovery points that help with accidental deletion, logical corruption or restoring older data. Site Recovery continuously replicates supported machine workloads and orchestrates failover to another location so that a service can resume after a serious outage. Replication can carry corrupted data or malicious modifications to the replica; it is not a substitute for protected historical backup. Conversely, an old backup may restore intact data but take longer to reconstitute an entire multi-VM application. Mature plans combine them according to threat and recovery objectives.
Understand replication direction and dependencies
Azure Site Recovery supports particular replication scenarios, including Azure VM replication between regions and supported on-premises workloads into Azure. Supported configurations and prerequisites vary; verify them before describing an arbitrary workload as protected. Source and target networking, storage, compute size and quotas must all be compatible with the proposed failover environment.
If a workload replicates disks to another region but relies on a source-only private DNS zone or external identity service, failover will not automatically satisfy the application dependency. Inventory addresses, application endpoints, security rules, shared secrets and directory connectivity. Determine how users or upstream systems will locate the recovered service and which components must be recovered together.
Replicated machines are not automatically independent of the source region’s supporting services. Review whether the target region has sufficient VM quota, compatible sizes, correctly scoped role assignments, encryption-key access, subnets, DNS and access to persistent dependencies. Replication health and recovery-point timestamps should be monitored before the day of a disaster. A recovery plan should state the authority for selecting a point that may lose some recent writes versus waiting for a more application-consistent point that is older. The RPO observed by operators depends on replication health and the selected point, not on a marketing promise.
Choose a vault and protection policy for the scenario
The Recovery Services vault is a management point for relevant backup and recovery operations, but its region and configuration must suit the protected environment and service-specific rules. Plan access permissions so routine operators can inspect protection health while only authorized personnel can change replication or initiate a destructive recovery action. Treat the vault as sensitive infrastructure.
Configure policy options based on the workload’s desired recovery points, test requirements and cost tolerance. More retained recovery points may require additional storage and management. A policy is only a statement of intent until the replication is healthy; monitor agent state, initial replication, ongoing synchronization and alert conditions that could invalidate the recovery guarantee.
Vault configuration and replication settings must correspond to the protected workload and Azure’s supported source/target scenario. A Recovery Services vault used for Site Recovery may be part of a separate continuity administration boundary; do not assume that a Backup vault supports the same disaster-recovery features. Grant the replication operator and disaster-declaration roles carefully, and document who is allowed to modify protection policy or stop replication. If protecting a production database VM, ensure its supported mobility/agent and application-consistency prerequisites are met before telling the business that a failover plan is operational.
Recovery plans coordinate applications, not just machines
A recovery plan groups protected machines into ordered recovery steps and can include supported automation and manual instructions. Its value lies in modeling which components must start before others. A database that depends on a directory service and is used by an API tier should not be treated as three unrelated servers that can be started in random order.
Define which applications must start, which dependencies need external intervention and how success will be assessed. For example, an API might be reachable on TCP 443 before it can process a transaction against its recovered database. The validation should use a representative business action and confirm data consistency, not merely a port check.
Recovery plans establish sequencing. An application may require directory/DNS services, then a database, then middle-tier workers, then a public or internal frontend. If all machines are started together, the frontend can declare itself healthy while still failing requests to a database that has not recovered. Group machines by startup order, include necessary manual checkpoints, and give each checkpoint a measurable success criterion. An automation step that updates a traffic endpoint should execute only after application validation proves the destination service is ready. Record which step can be retried safely and which might duplicate processing or cause a split-brain condition.
Practice test failover without harming production
Site Recovery supports test failover workflows designed to validate recovery without affecting ordinary ongoing production replication in supported configurations. Use an isolated test network to prevent a recovered copy from conflicting with live systems, sending real customer notifications or writing to the production database. Record which recovery point was selected and how long the application took to become usable.
Do not test only the easiest subset of machines. Include DNS changes, dependency startup, user authentication and relevant security controls. Test failover results should update runbooks and staffing plans. If the recovered application requires manual intervention, measure that time honestly; ignoring it would understate RTO and leave the business with an unrealistic commitment.
A test failover should use an isolated Azure virtual network with a matching-enough topology to validate the application without colliding with production addresses or identities. Choose a recovery point, run the test, inspect VM health and then prove a representative business transaction. A boot screenshot is not an application acceptance test. Microsoft documents that test failover can run without affecting ongoing replication when planned correctly. Clean up test VMs and record the observed RTO, data age, missing dependencies and recovery-plan improvements. Repeating a failed drill is useful; silently accepting the green VM status is not.
Failover and failback require deliberate decisions
During a real incident, an operator chooses a suitable recovery point and executes supported failover actions. After the target environment is verified, traffic is directed to it. Depending on the scenario, committing a failover and re-protecting workloads has implications for later return to the original location. The safest sequence depends on the replication topology and the condition of the source environment.
Failback is not simply pressing the inverse button and expecting every changed database to align. Determine where authoritative data now lives, how it will be synchronized, and which application endpoints need to change again. Use rehearsed, approved steps and preserve the incident timeline. An untested rush back to the original region can cause a second outage after the first recovery succeeded.
During a genuine failover, the incident commander chooses whether to bring workloads online in the target site, recognizing the possibility of data loss and DNS/client redirection delays. After verification, commit behavior and subsequent reprotection require planning for the chosen scenario. Failing back is not always the reverse of one click; dependencies, consistency, changed user data and network address configuration must be reconciled. Avoid turning on the recovered production instance while the original is still serving writes unless the application supports an explicit multi-active model. The plan should name the owner of each irreversible or high-impact step.
Build a recovery exercise appropriate to AZ-104
In a disposable lab, configure a supported replication scenario if access and cost allow. Inspect health, target settings and recovery point options. Execute a test failover into an isolated network, verify guest and application readiness, then clean up the test environment according to the service workflow. If you cannot afford cross-region replication, map the process in the portal and use supported demonstrations while clearly distinguishing simulated steps from executed ones.
Produce a written recovery sequence with objectives, dependencies, owner approvals, expected validation and rollback. Compare it to an Azure Backup restore exercise for the same workload. The point is to demonstrate why replication-based recovery and retained backup address different operational needs and must be managed together.
Draw a four-component training service—DNS, web, application worker and database—and give it RTO and RPO targets. Choose whether each component needs Site Recovery, backup, an availability-zone pattern or a service-native recovery mechanism. Then simulate loss of the primary site in a tabletop exercise and identify exactly when the users regain a valid transaction path. For a supported disposable VM lab, run an isolated test failover and record replica boot, DNS correction, data age and user-facing test results. Restore the initial state and clean up the test resources. The deliverable is a tested recovery procedure with evidence and remaining risk, not only a configured vault.