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 almost running 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 machines sitting in a secondary region, powered off, costing you storage but not compute until the day you turn it on. 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 VMs to a secondary region and orchestrates the switch to that region when the primary fails. It keeps a standby copy near-current and ready, so recovery is a promotion, not a rebuild.
Continuous replication, and what it buys you
The engine underneath ASR is continuous replication. Once you enable protection on a VM, Site Recovery streams its disk writes to the secondary region as they happen, keeping the standby copy trailing the live machine by seconds to a few minutes rather than a night. That trailing gap is your RPO, and because it is measured in seconds — not the hours a backup schedule gives you — ASR is the only tool that meets the tightest numbers a business will ever sign. The replica is not booted while it waits; you pay for the storage its disks occupy and for the replication itself, not for idle compute. Compute is billed only when you actually fail over and the machines start.2
This is the whole economic argument for the tiering that Part F 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 — a near-current copy of the running VM |
| Typical RPO | Hours to a day (the backup schedule) | Seconds to minutes (continuous replication) |
| 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 storage + replication; compute only on 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 — promoting the replica in the secondary region to become the live system, so traffic runs there instead of the failed primary. It can be planned (you initiate it ahead of a known event, with no data loss) or unplanned (the primary is already gone and you cut over from the latest replicated point).
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.
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 you can see it coming (a planned migration, a maintenance window you would rather not sit through) you run a planned failover, which lets replication finish its last writes so you lose nothing. If the region is already gone, you run an unplanned failover, cutting over from the most recent point that replicated before the lights went out — you may lose those last seconds, which is exactly the RPO you signed for. Either way, 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, so the standby trails the live machine by seconds to minutes, and it is already sitting in a second region waiting to be promoted. 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 under 5 min.
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 a sub-five-minute RPO 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 seconds 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 a replicated standby you fail over to. Backup brings the data back; Site Recovery keeps the service running.
- ASR replicates continuously, so its RPO is seconds to 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 storage and replication; compute only on 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; Microsoft quotes crash-consistent and app-consistent recovery points on the order of minutes for Azure VMs, but treat the specific figure as something to confirm on Microsoft Learn for your workload rather than a guaranteed constant. The direction — far tighter than a backup schedule — 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. ↩