The standby you pay to keep asleep
The previous part showed how to restore data from a backup. A regional outage poses a different problem: the checkout machines must run somewhere else while the first region is unavailable. A nightly backup may be suitable for a catalogue that can lose a day's changes, but it cannot by itself meet a checkout target of only a few minutes of data loss. Azure Site Recovery (ASR) can replicate supported virtual machines to another region, ready for a failover. The business still has to decide how much data loss and downtime it can accept, and the team must test whether its complete checkout system meets those targets.
Backup brings the data back. Site Recovery keeps the lights on.
Azure Backup keeps recovery points that you restore from. Azure Site Recovery keeps replica disks for protected virtual machines in another region; it creates the recovery VMs during failover. You pay for protection and storage while those VMs wait, and compute when you start them for a test or real failover. A VM replica alone is not a working checkout: databases, identity, DNS, secrets, payment integrations and the route customers use must also work in the target region.1
- ASR
- Azure Site Recovery — a managed service that replicates supported virtual machines to a recovery location and helps start them there during failover. It protects the VMs you configure; it does not automatically move every service the application depends on.
Continuous replication, and what it buys you
For Azure-to-Azure protection, Site Recovery sends VM disk writes through a cache storage account in the source region to replica disks in the target region. It normally creates a crash-consistent recovery point every five minutes. That cadence is not a five-minute RPO guarantee. RPO is the age of the usable recovery point relative to the live VM; delays or replication faults can make it older. Compare the actual RPO and replication health with the business's agreed target, and alert when they drift. The standby VM is created at failover or test failover, when its compute begins to cost money. Protection, storage and data transfer also cost money before that.2
This is the whole economic argument for the tiering that Part VI builds. A warm standby in another region is not free — replication licensing per protected instance, the storage the replica consumes, and the egress of streaming changes across regions all show up on the bill every month, disaster or no disaster. So you do not replicate everything; you replicate the workloads whose loss is measured in revenue and reputation, and you protect the rest more cheaply. Site Recovery is the expensive instrument you point only at the organs that must not stop.
| Azure Backup | Azure Site Recovery | |
|---|---|---|
| Keeps | Recovery points — snapshots at rest | A replica — near-current copies of the running VM's disks |
| Data-loss check | Age of the usable backup point | Monitor actual RPO; five-minute point cadence is not a guarantee |
| Recovery is | A restore — rebuild the machine from a point | A failover — promote the standby and start it |
| You pay for | Backup protection and stored points | Protection, storage and transfer; recovery VM compute during tests or failover |
| Answers | Restore an earlier copy | Start protected VMs in a recovery location |
The two services solve different problems. A critical VM workload may use Site Recovery for regional failover and Backup for earlier restore points after deletion, corruption or a bad deployment. Replication can copy bad changes too. Neither service alone guarantees that the full application, including its managed services and external dependencies, can recover.
Rehearse the switch, then plan the return
Replicate keeps the recovery copy current. Test failover is a separate rehearsal you should run regularly; it is not a required stage on the day of an outage. During an actual outage, failover starts recovery VMs in the target region. After checking the result, you commit the chosen recovery point, reprotect to replicate changes back toward the original region, and later fail back when it is ready. Reprotect the original direction again after the return.3
- Failover
- Failover starts recovery VMs from a selected recovery point. It does not automatically prove the app works or direct customer traffic to it. If the source is reachable, Azure can attempt to shut it down before failover; that option alone does not guarantee zero data loss, because shutdown can fail or replication can lag. When the source is gone, choose an available recovery point and measure its age.
Test failover — the rehearsal most teams skip
A test failover starts recovery VMs without committing a production cutover or stopping replication. Choose a separate virtual network and check that it has no path to production before starting; isolation is a design choice, not an automatic property of the test button. Then check that the VM boots, the app starts, and each dependency you deliberately included in the test works. Clean up the test VMs afterward and record what passed, failed and took time.
A green replication status proves data is moving, not that customers can complete checkout after a regional outage. A test can expose a missing firewall rule, certificate, DNS record or database connection before the outage. Its timing measures the steps and dependencies you tested; it is not automatically the full customer-facing RTO. To claim that RTO, also rehearse routing customers to the recovered application and verify a transaction with test services.
The quarterly rehearsal nobody in production notices
In this fictional case, Campux protects its storefront VMs with Site Recovery. The checkout database, identity service, payment sandbox and DNS need their own recovery arrangements. Each quarter an engineer starts a test failover in a network verified as separate from production. A synthetic order uses test credentials and a payment sandbox, never a real charge. The team records VM boot time, application checks and any failed dependency, then cleans up the test VMs.
In the example drill the VM boots in under two minutes and the staged order completes. That proves those tested steps, not that real customer traffic will be restored in two minutes. The runbook also documents how to route traffic, check the database and compare the actual recovery point age with the agreed RPO. In a later fictional incident, checkout returns in forty minutes against a one-hour target; the measured end-to-end recovery time, not the VM boot time, is what the business can assess.
Play it through
Three minutes. Rehearse a VM failover, check what the test actually proves, then make the real recovery decision in a fictional outage. The simulation stops when it needs your input.
This class carries no live lab. Site Recovery protection and test VMs incur Azure costs, and a safe drill needs a prepared network and dependencies. The simulation lets you practise the decision without creating Azure resources. The section below explains commit, reprotect and failback.
The real switch, then the way home
When an outage crosses the threshold in your runbook, select an available recovery point and run a failover. If the primary is reachable, Site Recovery can attempt to shut down its VMs first; confirm that shutdown and the final replication succeeded before claiming no data was lost. If it is unreachable, use the latest suitable point and compare its actual age with the agreed RPO. Site Recovery starts the recovery VMs. Check the application and its dependencies, route customer traffic, then commit the recovery point after verification. A running VM alone does not mean checkout is serving customers.
After a real failover, protect the workload in its new location. Reprotect reverses VM replication from the now-live secondary region toward the original region. Once it is healthy and the primary region is ready, plan the failback and verify the returned application before routing customers home. Do not switch to an old source VM merely because its region is available: writes made after failover would be missing there.
Finally, reprotect from the original region toward the secondary again and check replication health. The service is protected for the next event only when that direction is healthy and the full application recovery plan remains current.
The failover you had already run four times
In the fictional case, the primary region is unreachable. You check the latest usable recovery point and begin the runbook. The protected VMs start in the secondary region; the team verifies checkout dependencies and routes customers there. Only after checkout works do you record the forty-minute end-to-end recovery against the one-hour target. Then commit and reprotect toward home. When the primary is healthy and reverse replication is ready, fail back in a planned window, verify checkout again and reprotect toward the secondary region.
Plan an isolated recovery rehearsal
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service. What you can claim after it: you can plan and evidence a recovery rehearsal. Performing one is a separate, billed exercise.
Workload: checkout VM and order dependency Business target: recovery within 60 minutes; data loss within 5 minutes No measured rehearsal result yet
Name the isolated test network and dependency checks before a test failover.
List timestamps, recovery-point evidence, DNS and a checkout verification to collect.
Write cleanup steps and compare observed results with both targets.
Check your reasoning after you finish
Targets are not measured results. An isolated test avoids sending production users into a rehearsal; verify dependencies and a real business action, record recovery time and point, and remove test resources through the supported cleanup process.
Examination
Four drills, then two situations. Write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B — Site Recovery can replicate the VMs. Its five-minute recovery-point cadence is not a guaranteed five-minute data-loss limit. Check actual RPO, replication health and the recovery design for the database, DNS, identity and payments. A and D still require restoring older backups. C copies eligible backup data across regions but does not start the application. If the business target is only a few minutes, prove that the entire checkout path can meet it.
B — reprotect before you fail back, always. After failover your machines run in the secondary region, but nothing is copying them anywhere; the primary holds stale data from the moment of the outage. Reprotect turns replication around so the now-live secondary streams its changes back toward the primary, rebuilding a current standby there. Only then can failback cut you home without losing everything that happened while you were failed over. A is the exact mistake that makes recovery a second disaster — you would fail back to data frozen at the outage. C invents a step that does not fit the return path. D throws away the replica and reaches for a backup, confusing the two services entirely. The order is fixed: replicate, failover, reprotect, failback.
Choose an isolated network, test, then clean up. Site Recovery lets you start test VMs without a production cutover, and ongoing replication continues. Isolation depends on the network you choose; a test on a connected production network can cause trouble. The false options confuse testing with stopping protection or permanently promoting the recovery region. Record which dependencies you actually tested so you do not mistake a VM boot check for an end-to-end recovery proof.
# campux-retail — storefront ASR runbook
1. Replicate storefront VMs to the paired region,
continuously; alert if actual RPO exceeds the agreed target.
2. On a real regional outage, run an unplanned
failover from the latest replicated point.
3. Once the failover succeeds, fail back to the
primary as soon as it is healthy.
4. Rehearse with a quarterly test failover in an
isolated network; store screenshots in the runbook.
Line three — it skips reprotect, the stage that makes failback safe. Between failover and failback, your live machines are running in the secondary region and nothing is replicating them home; the primary holds data frozen at the moment of the outage. Failing back "as soon as it is healthy" cuts you over to that stale copy and loses everything customers did while you were failed over — a second disaster dressed as a recovery. The fix is one clause: reprotect, then fail back.
The other lines are sound when the target network really is isolated. Monitoring actual RPO reveals a replica that has fallen behind (A). An unplanned failover is available when the source region is lost (B). A scheduled test can run while replication continues (D). Line three omits reverse replication, so the original region may contain stale data. After failing back, reprotect toward the secondary region again.
Show what the status cannot show. Replication health says data is being copied; it does not tell you whether checkout starts, dependencies respond or customer routing works in the recovery region. A test failover can check those pieces when the test network and dependencies are prepared. Keep a record of exactly what was tested and what remains unverified.
Compare known cost with the outage risk. A drill takes engineer time and billed test resources. The cost depends on the estate, so estimate it from the planned VMs and test duration. The alternative is finding a missing network rule or dependency during an outage, when diagnosis consumes the recovery window.
Keep a cadence the team can sustain. Scope a smaller drill if necessary, but still schedule full application recovery tests. Re-test after material changes to networking, credentials, databases or traffic routing; a previous pass does not validate a changed system.
Use the agreed limits. Compare the observed checkout impact, the remaining RTO window and the actual age of available recovery points. An unplanned failover may lose writes newer than the selected point; the amount is measured, not assumed to be only a few minutes.
Set a decision deadline. For example, fail over if checkout remains degraded past the runbook's threshold. Leave enough of the agreed RTO for VM start, application validation and customer traffic routing. A threshold equal to the entire RTO would be too late.
Communicate and execute the rehearsed move. Tell the channel the threshold and the clock so leadership is not asking. If the line is crossed, you run the tested failover — the one you rehearsed last quarter — not an improvised one, then reprotect so you are covered in the new region. Either way you log the actual recovery time against the objective, because the outage is also next quarter's evidence about whether the numbers you signed are the right ones.
Five things worth carrying out of this part
- Backup keeps recovery points you restore from; Site Recovery keeps replicated disks you fail over to. Backup brings the data back; Site Recovery keeps the service running.
- ASR replicates supported VMs. It normally creates crash-consistent points every five minutes, but actual RPO can be worse. Monitor point age and replication health against the agreed target.
- Test failover is a separate rehearsal. During a real outage: fail over, verify, commit, reprotect toward home, fail back when ready, then reprotect toward the recovery region again.
- Choose and verify an isolated test network. A test VM boot proves only that step; check the application, dependencies, traffic routing and full recovery time separately.
- After a real failover you must reprotect (reverse replication) before you fail back, or you return to stale data. Reprotect is the stage beginners forget and the one that keeps the loop closed.
- Site Recovery's replica is not a running duplicate you can serve from at the same time as the primary — it is a copy held ready, brought online only when you fail over. If you need both regions live and taking traffic simultaneously, that is an active-active architecture built above ASR, not something ASR gives you on its own. ↩
- Microsoft documents five-minute crash-consistent point creation for healthy Azure-to-Azure replication, and also documents faults that prevent points from being created. Monitor the actual RPO of each protected VM; a schedule is not a data-loss guarantee. Architecture · Monitoring ↩
- Microsoft treats test failover as a drill alongside replication. For Azure-to-Azure recovery, its failback tutorial requires reverse replication before returning to the primary region. Test failover · Failback ↩
Plan replication to a second region and a deliberate failover, rehearse the decisions on paper, and say what a live test still has to prove.
Play the lesson above to stamp this class.