The standby you pay to keep asleep
The previous part left you able to bring data back. That is not the same as staying open. A restore from last night's recovery point returns last night's data and takes however long a full-machine rebuild takes — perfectly adequate for a catalogue you can afford to lose a day of and be down a few hours for, and useless for a checkout system that must survive an entire region going dark with minutes of tolerance. When the number the business signed is that small, backup cannot reach it, because a backup is a copy at rest — you still have to restore it, and restoring is the slow part. What that workload needs is a copy that is already almost current and ready to start in minutes, somewhere the disaster did not touch. That is Azure Site Recovery.
Backup brings the data back. Site Recovery keeps the lights on.
Hold the distinction cleanly, because the exam and the job both probe it. Azure Backup keeps recovery points — snapshots you restore from, on a schedule measured in hours or a day. Azure Site Recovery keeps a replica — a continuously updated copy of your virtual machine disks in a secondary region. No machine is running there while it waits, so it costs you storage but not compute; the VM itself is built from those disks the moment you fail over. Backup answers "the data is gone, get it back." Site Recovery answers a harder question: "the whole region is gone, keep running." One is a diary you can reread; the other is an understudy already in costume, waiting in the wings of a different theatre.1
- ASR
- Azure Site Recovery — a managed service that continuously replicates your VM disks to a secondary region and orchestrates the switch to that region when the primary fails. The disks are kept near-current, so recovery starts a machine from data that is already there instead of rebuilding one from a backup.
Continuous replication, and what it buys you
The engine underneath ASR is continuous replication. Once you enable protection on a VM, Site Recovery ships its disk writes out as they happen — first into a cache storage account in the source region, then on to replica disks in the target region. From that stream it builds a crash-consistent recovery point every five minutes by default, so the standby trails the live machine by minutes rather than by a night. That trailing gap is your RPO, and minutes is a number no backup schedule reaches, which is why ASR is the tool for the tightest objectives a business will sign. Nothing runs in the target region while it waits: you pay for the replica disks and for the replication itself, not for idle compute. Compute is billed only when machines are actually created and started — at a failover, or at a test failover.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 |
| Typical RPO | Hours to a day (the backup schedule) | Minutes — a recovery point every five minutes |
| Recovery is | A restore — rebuild the machine from a point | A failover — promote the standby and start it |
| You pay for | Stored recovery points | Replica disks + replication; compute only at failover or test failover |
| Answers | The data is gone — get it back | The region is gone — keep running |
The two are not rivals; they are layers. A serious Tier-1 workload carries both — Site Recovery so a regional outage is a switch rather than a catastrophe, and Backup so a bad deploy or a ransomware encryption from three weeks ago can still be rolled back to a clean point. Replication faithfully copies corruption too; that is precisely why you keep the recovery points as well.
The five verbs, in order
The lifecycle of an ASR-protected workload is a fixed sequence of five stages, and mixing up their order is the classic exam trap.3 Replicate is the ongoing state — always running, quietly keeping the standby current. Test failover is the rehearsal you run on an ordinary Tuesday. Failover is the real switch, on the bad day. Reprotect reverses the direction of replication once the roles have flipped. Failback returns you home once the original region is healthy again. Learn them as a loop that always resolves back to where it started: replicate, and eventually replicate again.
- Failover
- Failover — starting machines in the secondary region from the replica disks, so traffic runs there instead of on the failed primary. An unplanned failover is the one you run when the primary is already gone: you cut over from the latest replicated recovery point and accept the RPO gap. A planned failover, the zero-data-loss variant, is a Hyper-V option in Site Recovery; for Azure VMs the same effect comes from choosing to shut the source machines down before the failover begins.
Test failover — the rehearsal most teams skip
Of the five stages, one earns its keep on every ordinary day and is the one almost everyone neglects: the test failover. It spins the replica up in an isolated network — a sandbox with no route to production — so you can boot the standby, log in, push a transaction through it, and confirm with your own eyes that the recovery actually works. And it does none of the harm the name might suggest: production keeps serving, replication keeps running, and nothing about the live system is touched. When you are done you tear the test copy down and the estate is exactly as it was, now with evidence attached.
This is the single most valuable and most-skipped practice in disaster recovery, and the reason is worth saying plainly. A failover you have configured but never run is not a plan — it is a hope with a runbook stapled to it. You do not know that the replica boots, that the application inside it starts, that DNS and dependencies resolve in the target region, or how long any of it takes, until you have watched it happen when the stakes were zero. The first time you find out should never be the real disaster, because that is the one moment you cannot afford to discover that a firewall rule, a missing certificate, or a hard-coded regional endpoint quietly breaks the whole thing. The test failover converts an assumption into a measured, screenshotted fact — and a measured RTO is the only kind a business can trust.
The quarterly rehearsal nobody in production notices
Campux replicates its Tier-1 storefront VMs to the paired region with Azure Site Recovery, and once a quarter it proves the plan rather than trusting it. An engineer runs a test failover: the storefront replica boots in an isolated network, a synthetic order — a fake customer, a fake basket, a card that charges nothing — flows all the way through the isolated copy, screenshots of each step go into the runbook, and then the test instances are torn back down. Production never notices; real checkout serves real customers throughout, and replication never pauses.
The value is in the boring outcome. Every quarter the runbook gains a fresh set of proofs — the replica boots in under two minutes, the storefront answers, the order completes — and a fresh measurement of how long the switch takes. So when a genuine regional incident finally arrives, the on-call engineer is executing a move rehearsed four times that year, not improvising one for the first time under fire. That is the difference between a forty-minute recovery against a signed one-hour RTO, and the nine-hour scramble from a closet that started this whole class.
Play it through
Three minutes. Prove the failover works with a test run at zero risk, then run the real one on the bad day. It plays on its own and stops when it needs your hands.
This class carries no lab. A real Site Recovery drill replicates whole virtual machines into a second region, and even a test failover takes real minutes and bills real compute, so it is not a beginner Cloud Shell exercise. The walkthrough above stands in for it: it takes you through the first three stages — replicate, test failover, failover — at no cost. The two that finish the loop, reprotect and failback, are the section below.
The real switch, then the way home
When the bad day actually comes, you run a failover — the real one this time, not the rehearsal. If the primary is still reachable and you can see the event coming, you tell Site Recovery to shut the source machines down first, so the last writes drain across and you lose nothing. If the region is already gone, you fail over to the latest recovery point that made it out before the lights went out — you may lose the last few minutes, which is exactly the RPO you signed for. Either way Site Recovery creates the machines in the secondary region from the replica disks; you check them, then commit the failover to settle on the recovery point you chose. The secondary region is now live and serving your traffic.
What happens next is the pair of stages beginners forget, and forgetting them is how a recovered business quietly becomes unprotected again. After failover, your machines are running in the secondary region — but nothing is copying them anywhere. You reprotect: turn replication around so the now-live secondary streams its changes back toward the original region, rebuilding a standby in the opposite direction. Only once that reverse replication is healthy can you failback — switch home to the primary region after it recovers. The order is fixed and it is not optional: reprotect before you fail back, because failing back to a region you were never replicating to means cutting over to stale or absent data. Reprotect is the unglamorous stage that keeps the loop closed; skip it and you have merely moved your single point of failure to a new address.
Then the loop resolves. Once you have failed back and reprotected again in the original direction, you are exactly where you started — replicating from primary to secondary, standby waiting, ready for the next event. That is why the lifecycle is drawn as a circle that returns to replicate: disaster recovery is never "done," it is a posture you hold and periodically prove.
The failover you had already run four times
A paired region has a bad hour and your primary is unreachable. You do not improvise: you open the recovery plan, run the unplanned failover you rehearsed last quarter, and watch checkout come up in the secondary region inside the RTO the business signed. Then you do the two things nobody sees — you reprotect so the now-live region is replicating back, and you log the actual recovery time against the objective. Later, when the primary is healthy, you fail back on a planned window and reprotect once more, closing the loop. The heroics happened months ago, on a quiet Tuesday, when you tested the thing until it was boring.
Examination
Four drills, then two situations. Write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B — a minutes-RPO across a whole-region loss is Site Recovery's job. ASR replicates continuously and builds a recovery point every five minutes, so the standby trails the live machine by minutes, and its disks are already sitting in a second region waiting to be started. A is the seductive trap: even several backups a day leaves hours between recovery points, and each one still has to be restored — the slow part — before you serve traffic, so you miss both the RPO and the RTO. C confuses where backup data is stored with a running standby; GRS copies recovery points to the pair, but you still restore from them, which is not keeping the service alive. D loses a whole day of orders. When the number is minutes and the threat is a region, only replication reaches 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.
Isolated, non-committal, and safely routine. Those three are the entire reason test failover exists: it validates the plan in a sandboxed network, proves recovery without the risk of a real cutover, and is safe enough to calendar quarterly — which is exactly why its being skipped is the most common DR failure there is. The two rejects are the dangerous confusions. Test failover does not stop replication — that is its whole point; it runs alongside ongoing replication so you are never unprotected while testing. And confusing it with a real failover (which does promote the secondary and does need reprotect and failback afterward) is how someone runs a production cutover thinking it was a drill. Memorise the sequence and the safety: replicate always, test on Tuesday in an isolated network, fail over only on the bad day.
# campux-retail — storefront ASR runbook
1. Replicate storefront VMs to the paired region,
continuously; confirm RPO stays in minutes.
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 distractors are all healthy lines. Continuous replication holding an RPO measured in minutes is exactly what ASR is for (A). An unplanned failover from the latest replicated point is the correct move when the region is already gone (B). And a quarterly test failover runs deliberately alongside production replication in an isolated network — that non-disruptiveness is the feature, not a fault (D). The test for any ASR runbook: does the loop close — replicate, failover, reprotect, failback — with no stage missing? Line three drops one.
The premise is the trap — that a failover you have never run is the same as one you have. Replication running proves data is being copied; it proves nothing about whether the replica boots, the application starts, DNS and dependencies resolve in the target region, or how long the switch takes. "We'll just fail over" assumes all of that on the one day you cannot afford to be wrong. The drill is not busywork; it is the only thing that turns the plan from a hope into a measured fact.
Price both sides honestly, in the lead's own units. A test failover is a few engineer-hours and a little compute, once a quarter — call it a known, small, calendared cost. A failover that fails for the first time during a real regional outage is the checkout tier down for the length of the outage, revenue burning, and an on-call engineer debugging a firewall rule at 3am with the business watching. You are not spending hours to be thorough; you are buying down the risk of discovering a broken runbook at the worst possible moment.
Offer the smaller version rather than the fight. If quarterly feels heavy, propose twice a year, or a lighter scripted drill — but keep some cadence, because the failure mode of "we'll test it later" is that later never arrives and confidence grows while capability quietly rots. The config not changing is not reassurance; the platform, the dependencies, and the target region all drift underneath you. The whole point of this part is that the rehearsal, not the replication, is what you are actually paying for.
The decision is not a gut call — it is the RTO and RPO you signed, applied under pressure. Failover has a cost: the cutover itself takes time, an unplanned failover may lose the last few minutes of in-flight data, and coming back means reprotect and failback later. A "grey" outage — degraded, not dead — is the hardest case precisely because waiting for the primary to recover might be faster than switching, or might strand you as it slowly gets worse. You resolve it against the clock the business agreed to, not the hope that the status page turns green.
Give the wait a deadline. Set an explicit threshold — "if checkout is still degraded in N minutes, or if the error rate crosses the line where we are effectively down, we fail over" — where N is bounded by your RTO, so waiting can never itself blow the objective. That converts an anxious judgement into a rule you can defend afterward, and it stops the two worst outcomes: failing over reflexively over a blip that self-heals in two minutes, and dithering past the point where recovery was still cheap.
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 continuously and cuts a recovery point every five minutes, so its RPO is minutes — far tighter than any backup schedule. That is why it is the tool for a whole-region outage with minutes of tolerance. You pay for replica disks and replication; compute only at failover or test failover.
- The lifecycle is five stages in order: replicate always, test failover, failover, reprotect, failback — a loop that returns home to replicating again.
- Test failover runs the replica in an isolated network without touching production or pausing replication. A failover you have never rehearsed is a hope, not a plan — and it is the most-skipped practice in DR.
- 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. ↩
- Achievable RPO and the exact replication mechanics differ by scenario (Azure-to-Azure, VMware, or physical) and shift over time. For Azure-to-Azure replication, disk writes stream to the target region continuously, and Site Recovery turns that stream into a crash-consistent recovery point every five minutes automatically; an app-consistent recovery point is optional, off by default, and can be scheduled no more often than once an hour. Treat the specific figures as something to confirm on Microsoft Learn for your workload rather than a guaranteed constant. The direction — a replica trailing by minutes at most, far tighter than a backup schedule measured in hours or a day — is settled. ↩
- Names for the stages are stable, but the exact portal wording and the split between planned and unplanned failover has changed across ASR's "classic" and "modernized" experiences. Learn the sequence — replicate, test failover, failover, reprotect, failback — as the durable shape, and check the current failover options for your setup before a production drill. ↩