Zones defend a building; region pairs defend a city
The five parts before this one gave you the machinery — the two numbers, the vault, backup and restore, the replicated standby. This last part is where the machinery stops being the point and judgement takes over, because no service decides for you which workload deserves which defence. Start with the physical facts, held plainly. An Azure region is a geographic cluster of datacentres. Inside many regions are availability zones — physically separate datacentres with independent power, cooling, and network, a few kilometres apart, close enough for synchronous replication. Spreading a workload across zones (zone-redundant) means a single datacentre burning down is a non-event; the surviving zones carry the load. That is your defence against local failure, and it is why Campux's checkout database runs zone-redundant.
But a zone strategy does not survive the loss of an entire region — a flood, a fibre cut, a regional service incident that takes every zone at once. Microsoft is explicit about this: availability zones do not protect against a full-region outage.1 What defends against losing a whole region is a second region, hundreds of miles away, holding a copy of your data or a standby of your service. The classic form of that is the region pair: two regions in the same geography that the platform treats as partners — geo-redundant storage (GRS) replicates your data to the pair automatically, some platform updates are staged one region at a time across the pair, and in a broad outage recovery is prioritised so at least one of the two comes back first. East US pairs with West US; North Europe with West Europe.
- Zone
- Availability zone — a physically separate datacentre inside a region, with its own power, cooling, and network. Zone redundancy defends against the loss of a single datacentre; it does not defend against the loss of the region.
- Region pair
- Two regions in the same geography the platform pairs for geo-redundant storage, staged updates, and prioritised recovery. A pair defends against the loss of an entire region — the catastrophe zones cannot survive.
Zone redundancy defends against losing a building; region pairing defends against losing a city. Serious resilience uses both — zones for the everyday failure, the pair for the regional catastrophe — which is precisely Microsoft's own guidance for anything mission-critical: multi-zone and multi-region. One caveat worth carrying onto a real project: the pairing model is in flux. Microsoft has been moving toward an availability-zone-first design, and some newer regions ship without a designated pair, expecting you to reach a second region yourself. The exam still tests the classic pairs; a live project needs you to check whether your region actually has one.2
Honest tiers — sort the estate, then price each one
The instinct, meeting all of this for the first time, is to protect everything to the maximum. It is a natural instinct and it is wrong, because resilience is bought in real dollars — idle standby compute, cross-region egress, replication licensing — and a business that spends checkout-grade money protecting its analytics scratch pad has misread its own risk. The professional move is the boring one: sort every workload into a small number of tiers, attach an honest RPO and RTO to each, and protect each to exactly that level. No more, no less.
Protect everything, and you have decided nothing.
Three tiers is usually enough. Tier 1 is the revenue organs — the systems whose loss stops the business trading, owed an RPO of minutes and an RTO under an hour. Tier 2 is the important-but-survivable — annoying to lose, not fatal, content with a day of RPO and a few hours of RTO. Tier 3 is the disposable — data you would happily regenerate, owed nothing at all, on purpose. The point of the tiers is not the labels; it is that the mechanism follows the number, never the reverse. A minutes-RPO forces near-continuous replication (Azure Site Recovery, §5 of the previous part); a day-RPO is met by a plain nightly Azure Backup; a defence against a single datacentre failing is zone redundancy. Choose the number the business will sign, then reach for the tool that can actually produce it.
| Tier | RPO | RTO | Mechanism | Campux example |
|---|---|---|---|---|
| Tier 1 · revenue-critical | Minutes | Under an hour | Zone redundancy + Azure Site Recovery replication to a second region, test-failed-over quarterly | Checkout & the orders database |
| Tier 2 · important | ~24 hours | A few hours | Daily Azure Backup, GRS vault, restore on demand | Product catalogue & marketing site |
| Tier 3 · disposable | Unbounded | Unbounded | None, deliberately — the data regenerates | Analytics scratch data |
Read the table as an argument, not a menu. Each row spends money in proportion to what losing the workload actually costs, and the Tier 3 row spends nothing on purpose. That last row is the one beginners want to fill in with "a minimum backup, just in case" — and doing so is how a resilience budget quietly drains until the one workload that mattered gets cut in the next cost review. Honest tiers are what keep the important protection funded.
The plan — and the sentence that makes it real
The tiers become an asset the moment they are written down. The artifact has a name — the BCDR plan — and it is a plain document, often a single page, that maps each workload to its tier, its agreed RPO and RTO, and the mechanism that meets them. It is not a diagram to admire; it is a decision the business owns, signed in daylight, so that when the disaster comes the response is execution rather than invention.
- BCDR
- Business Continuity and Disaster Recovery — the plan that maps each workload to an agreed RPO and RTO and to the mechanism (zone redundancy, backup, replication) that meets them, including the tiers you consciously leave unprotected.
The clause in bold is the part that separates a plan from a wish-list. A BCDR document that protects everything has not made a single decision; it has written a budget and called it a strategy. The discipline — the actual skill no service configures for you — is choosing, and then writing down what you chose not to protect and why. One sentence does more work than any architecture diagram: we accept total loss of the analytics scratch data because it regenerates nightly and costs nothing to rebuild. That sentence proves a human weighed the trade-off and signed it, which is exactly what turns a lost Tier 3 workload, on the bad day, into a choice everyone agreed to rather than a failure pinned on you.
Then the part that keeps the plan honest: you test it. A backup you have never restored is a rumour; a failover you have never run is a slide. Teams that do this for real revisit the plan every quarter and rehearse at least the Tier 1 restore or failover each time — small, scoped, calendared. Proposing that cadence in your first ninety days is one of the higher-credibility moves available to you, because it converts "we think we're covered" into "we've proven it, and it takes this many minutes."
The nine-hour outage, priced and prevented
The founding wound: a single disk failed in the server closet, and Campux was dark for nine hours while someone drove in, sourced a replacement, and rebuilt from a backup nobody had ever tested. This part is where that stops being possible. You sit the business down and force the two numbers, tier by tier. Checkout and the orders database — the revenue organs — get an RPO of minutes and an RTO under an hour: the database runs zone-redundant so a single datacentre failure is invisible, and the storefront replicates to the paired region with Azure Site Recovery, test-failed-over quarterly so the runbook is proven, not hoped. The product catalogue and the marketing site — annoying to lose, not fatal — get daily Azure Backup with an RTO of a few hours; cheaper, and honestly rated. The analytics scratch data gets no protection at all, on purpose, because paying to protect data you would happily regenerate is itself a finding in Class Thirty-Two's cost review.
Then the part that turns a plan into an asset: they test it. A quarterly test failover brings the checkout tier up in an isolated network, a synthetic order flows through, screenshots go in the runbook, and the replica is torn back down — production never noticed. When a real Azure regional incident finally arrives eighteen months later, the on-call engineer runs a rehearsed failover, not an improvised panic; checkout moves to the paired region in forty minutes against a signed RTO of one hour, and the monthly report carries the sentence that renews budgets: the last unplanned outage cost us nine hours; the last regional incident cost us forty minutes and no data. The disk in the closet took whatever it wanted. Nothing since has been allowed to.
The recovery you rehearse
All five parts of this class converge on a single, unglamorous act: proving the recovery before you need it. Everything else — the vault, the policy, the tiers, the signed plan — is scaffolding around that one moment when a file is gone and you get it back without anyone becoming a hero. So the class ends where the confidence actually comes from: your hands on a real restore, at trivial cost, on the cheapest workload that still teaches the whole flow.
The lab below is deliberately small. It is not a region-scale failover — that needs replicated VMs and target-region compute, which is neither free nor beginner-safe. It is the everyday loss instead: a deleted file, pulled back from a recovery point in a vault. That is the restore you will run most often in a career, and running it once for real is worth more than reading about failover ten times.
Back up a file share, delete a file, restore it from the vault
You will create a Recovery Services vault, protect a small Azure Files share with a backup policy, and take an on-demand recovery point so you hold a real one in hand. Then you stage the disaster — delete a file, confirm it is genuinely gone — and restore it from the vault to its original place, watching the loop close end to end. The whole thing runs in one sitting for pennies, and the teardown reminds you that soft delete will refuse to release the vault until its protected data is cleared.
Open the lab — Back up & restore a file share →The recovery nobody had to be a hero for
A partner deletes a critical folder, or a region has a bad hour. You do not panic and you do not improvise: you open the vault, find the right recovery point, run the restore or the rehearsed failover, and watch service return inside the RTO the business signed off. Afterward you note the actual recovery time against the objective, and if the gap is uncomfortable you tighten the plan before the next one. Backup and DR is the least glamorous work you will do and the work that most reliably keeps you employed — because the day it pays off, it pays for the entire year.
Resilience is a number you buy, not a feature you enable
Zoom out one last time before the drills. You can now build a vault, set a policy, run a restore, reason about failover, and place a workload against zones and pairs. The thing that ties all of it together is a disposition, not a service: the difference between a nine-hour outage and a forty-minute one was a decision made months earlier, not a heroic night. A backup you never restore silently rots — a retention rule drifts, an agent stops, a share falls out of policy — and you discover it on the worst day. The test failover and the trial restore are the feedback loop that keeps the plan honest; without them, confidence grows while capability decays.
And the real constraint is rarely storage — it is RTO, how fast you can restore under pressure, which is why a plan that lives in one engineer's head fails the week they are on leave. The plan has to be a written, tested runbook the on-call can execute cold. That is the whole argument of this class, and of the whole track that began with detecting an incident: the engineer who ships is asked "is it backed up?" The engineer who gets trusted with more is asked "when did we last restore it — and how long did it take?" — and had the screenshots ready. Carry that question into Class Thirty-Seven, where the databases underneath all of this get their own dedicated treatment.
Examination
Four drills, then two situations. Write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
A — zones defend a building, not a city. Zone redundancy spreads a workload across physically separate datacentres in one region, so a single datacentre failing is a non-event: the surviving zones carry the load. What it cannot survive is the loss of the whole region — a flood, a fibre cut, a regional incident that takes every zone at once — which is exactly what Microsoft states and what B gets dangerously wrong. Believing zones protect against a regional outage is how a DR plan quietly fails on the one day it is tested for real. C misreads zones as a maintenance-only feature; D confuses zones (inside a region) with regions themselves. The defence against losing a region is a second region — a pair, or your own cross-region choice.
B — the tool follows the number. A 24-hour RPO is met by a nightly backup; a few-hours RTO is met by an on-demand restore; a GRS vault means you can still restore if the region is lost. That is Tier 2, priced honestly. A over-protects: ASR replication buys a minutes-RPO the business did not ask to pay for, and idle standby compute is not free. D is the same error in its purest form — "tighter is always safer" ignores that near-zero RPO is the most expensive number in the class, and spending it here starves the Tier 1 protection that actually matters. C confuses Tier 2 with Tier 3; a catalogue you would have to rebuild by hand is not disposable. Match the mechanism to the signed number, never the reverse.
Tiered numbers, matched mechanisms, and an explicit "not protecting this." Those three are what makes a document a plan rather than a wish-list: workloads sorted and priced, each tier given a tool that can genuinely deliver its RPO and RTO, and — the clause that proves a human actually chose — a written statement of what you are leaving unprotected and why. The two rejects are the classic self-deceptions. Protecting everything to the tightest setting is not caution; it is the refusal to decide, and it drains the budget that keeps the important protection funded. And "the jobs report success, so we've never needed to test" is the exact false confidence that turns a backup into a rumour — a job proves data went in, only a restore proves it comes back out.
# campux-retail — BCDR plan (tier summary)
1. Checkout DB (Tier 1): RPO 5 min, RTO 30 min —
zone-redundant + ASR replication to the paired
region, test failover run quarterly.
2. Storefront VMs (Tier 1): RPO 5 min via Azure
Site Recovery replication to West US.
3. Product catalogue (Tier 2): RPO 24 h, RTO 4 h —
a nightly Azure Backup gives an RPO of 5 minutes.
4. Analytics scratch (Tier 3): no protection —
regenerated nightly, accepted total loss.
Line three — the mechanism cannot deliver the number it claims. A backup that runs once a night means that, at worst, you lose everything since last night's recovery point: the RPO of a nightly schedule is 24 hours, not five minutes. The line even states the correct objective (RPO 24 h) and then contradicts it in the same breath — the copy-paste error that reads fine until the disaster, when the business expecting five-minute freshness discovers a day-old catalogue. A five-minute RPO requires near-continuous replication, not a nightly job; the fix is to delete the false clause, because 24 hours is the honest and adequate number for a Tier 2 workload.
The distractors are all plausible-sounding and wrong, which is the point. Zone redundancy and ASR are complementary, not exclusive — one defends the building, the other the region, and Tier 1 rightly uses both (A). ASR replicating to the paired region is exactly its normal design (B). And a Tier 3 workload carrying no protection is not an error — it is the plan making a real decision, honestly recorded (D); demanding a "minimum backup" for data you regenerate nightly is how resilience budgets get quietly wasted. The test for any BCDR line: can the named mechanism actually produce the named number? Line three fails it.
The trap is the premise — that "protect everything maximally" is a strong requirement. It is actually the refusal to make the one decision DR requires. Near-zero RPO and RTO across every workload means continuous replication and idle warm standbys for the analytics scratch pad and the marketing site as well as checkout — a bill that, when it lands, gets the whole resilience budget questioned in the next cost review, and the first thing cut is usually the protection that genuinely mattered. Agreeing cheerfully and building it would be the junior move; so would telling the owner they are wrong. Do neither.
Reframe money as risk, in the owner's own terms. "Zero data loss on checkout is worth almost any price, and I'll build it. Zero data loss on data we regenerate nightly costs the same and protects nothing — and that money comes out of the budget that keeps checkout protected. So let's spend where the loss actually hurts." Then make it concrete: propose three tiers, put a dollar-shaped consequence on each ("an hour of checkout down is roughly this much; a day of catalogue staleness is a shrug"), and let the owner rank — because they will rank correctly the moment the trade-off is theirs to see, which it never was while the answer was "everything."
Leave with signed numbers, not a vibe. The deliverable of the meeting is a one-page tier table with an RPO and RTO per tier and one line naming what you will not protect and why. That document is what turns "not losing data is the point" into a plan you can actually build and, more importantly, into a decision the business owns — so that when the disaster comes and something in Tier 3 is lost, it is a choice everyone signed, not a failure they pin on you.
A strong answer concedes before it argues. The predecessor did real work — backups exist and run, which is more than many shops manage — and opening with that keeps the room on your side. So say it plainly: "We're in a genuinely good starting position; backups are configured and succeeding." Then the pivot, framed as method not blame: a successful backup job proves data went in; only a restore proves it can come out, and no one has tested the coming-out. That gap is a property of the setup, not a fault of the person — the same blameless logic Class Thirty-Six installed: any failure a competent human can leave behind is a missing guardrail, here the missing restore test.
Convert the rumour to evidence cheaply. Propose a scoped, no-drama trial restore: pick one non-production item, restore it to an alternate location so nothing live is touched, time it, and screenshot the result. This costs almost nothing and produces two facts leadership actually needs — a proven recovery, and a measured RTO to compare against whatever objective they assumed. If the restore works, you have upgraded "we think we're covered" to "we've proven it and it takes N minutes." If it fails, you have found the most important bug in the estate before a real disaster did.
Turn the finding into a cadence, not a one-off. Close by proposing that the trial restore becomes a quarterly test — a Tier 1 restore or failover each quarter, calendared, with the times logged against the signed RPO and RTO. That reframes the whole thing from "auditing my predecessor" to "building a habit the team owns," which is the version leadership funds and the version that survives you leaving too. The person who left set up backups; the person who tests restores is the one who actually gave the business disaster recovery.
Five things worth carrying out of this part
- Zone redundancy defends against losing a single datacentre; it does not survive the loss of an entire region. That is what a second region — a region pair, or your own cross-region choice — is for. Serious resilience uses both.
- Sort every workload into a small number of honest tiers, attach a signed RPO and RTO to each, and protect each to exactly that level — no more, no less. The mechanism follows the number, never the reverse.
- Tier 1 (minutes / under an hour) earns zone redundancy plus ASR replication; Tier 2 (a day / a few hours) earns a daily backup; Tier 3 earns nothing at all, on purpose, because the data regenerates.
- The BCDR plan is the artifact — one page mapping each workload to its tier, numbers, and mechanism. What makes it a plan and not a wish-list is the written line naming what you deliberately chose not to protect, and why.
- A backup you have never restored is a rumour and a failover you have never run is a slide. Test the Tier 1 recovery quarterly, log the actual RTO against the signed one, and you have removed the need for heroics before the bad day.
- Microsoft's own reliability guidance is explicit that availability zones do not protect against a full-region outage, and that mission-critical workloads should be both multi-zone and multi-region. If data-residency rules forbid a second region, the recommendation is in-region zone redundancy plus a backup-and-restore plan with recovery objectives set to match a region-wide disruption. ↩
- Region pairing is the part of this class most in flux. Microsoft has been moving toward an availability-zone-first model, and some newer regions ship without a designated pair, relying on zones plus your own cross-region choices instead. The exam still tests the classic pairs (East US / West US, North Europe / West Europe), so learn them — but on a real project, check whether your chosen region actually has a pair rather than assuming it, because that assumption is exactly where a DR plan quietly fails. ↩
- The tier numbers in Table 1 (minutes, ~24 hours, unbounded) are a teaching shape, not a standard. Real estates run four or five tiers, and the exact RPO/RTO per tier is a business decision, not an Azure default. Treat the three-tier structure as durable and the specific numbers as an example to be re-signed for every workload. ↩