Two numbers the business signs before the disaster
The response half of this class assumed there was still a service to bring back. The recovery half begins the morning there is not — a disk fails, a region floods, an engineer runs a delete against the wrong subscription, ransomware quietly encrypts a file share — and it begins not with a tool but with two numbers that decide everything after them. The first is how much data you can afford to lose, measured in time; the second is how long you can afford to be down, measured in time. Get the business to sign those two numbers in daylight and the whole of backup and recovery becomes an engineering problem with a budget. Skip them, and you will be inventing the answer at three in the morning while revenue burns — which is exactly how Campux lost its founding nine hours.
- RPO
- Recovery Point Objective — the maximum data loss the business will tolerate, expressed as a span of time. An RPO of one hour says: if disaster strikes, we accept losing up to the last hour of changes. RPO is set by how often you take a recovery point — it is a backup-frequency question.
- RTO
- Recovery Time Objective — the maximum downtime the business will tolerate before service is restored, expressed as a span of time. An RTO of four hours says: we must be back within four hours of the disaster. RTO is set by how fast you can restore — it is a recovery-speed question.
Keep the two apart or you will invert them under pressure, which is the single most common mistake on both the exam and the job. The trick that never fails: RPO points backward, RTO points forward. RPO looks back from the moment of disaster to your last good recovery point — that gap is the data you lose. RTO looks forward from the moment of disaster to the moment service returns — that gap is the time you are down. Tighter objectives cost more, always: an RPO of five minutes means near-continuous replication, not a nightly backup; an RTO of fifteen minutes means a warm standby you pay for while it sits idle. The engineering is easy once the numbers exist. Extracting the numbers from a business that wants "zero and zero" for free is the actual skill, and it is the skill Part F returns to when it writes the plan.
The vault — where recovery points live
Azure's backup and recovery services do not scatter recovery points across your subscription; they gather them into a vault — a managed, access-controlled container that holds backup data separately from the resource it protects. That separation is the whole point, because a disk you back up onto the same disk is a diary you burn with the house. There are two vault types, and telling them apart is exactly the distinction the AZ-104 outline probes and the one the wrong-blade panic teaches on the job.
- Vault
- A dedicated Azure resource that stores recovery points and orchestrates backup and recovery jobs, isolated from the workloads it protects so that losing the workload does not lose the backup.
The older and broader of the two is the Recovery Services vault (RSV). It is the home of the classic Azure Backup workloads — Azure VMs, Azure Files shares, and SQL Server or SAP HANA running inside a VM — and, separately, it is also where Azure Site Recovery orchestrates the region-to-region replication of the next part. One vault, two jobs: keep copies, and keep a standby. The newer Backup vault covers the workloads that arrived later — Azure Blobs, Azure managed disks, Azure Database for PostgreSQL, and AKS. You do not choose between them by preference; the workload dictates the vault, and knowing which lives where is the difference between finding the right blade in ten seconds and thrashing for ten minutes. Both let you set the vault's storage redundancy — LRS keeps copies in one datacentre, ZRS spreads them across zones in the region, GRS replicates them to the paired region hundreds of miles away. GRS is the default for a Recovery Services vault, and for anything you would genuinely miss, it is the setting you want — set it while the vault is empty, because once backup data exists some redundancy choices lock.1
| Vault | Protects | Also does |
|---|---|---|
| Recovery Services vault | Azure VMs · Azure Files · SQL Server / SAP HANA in a VM · on-prem via the MARS agent or MABS | Hosts Azure Site Recovery — the region-to-region replication and failover of Part E |
| Backup vault | Azure Blobs · Azure managed disks · Azure Database for PostgreSQL · AKS | The newer workloads; operational and vaulted backup tiers |
Whichever vault a workload lands in, the machinery is the same shape: a policy decides when a recovery point is taken and how long it is kept, a restore reads one back, and a guardrail called soft delete stands between a deleted backup and permanent loss. The next three sections take those in turn.
The policy — schedule is RPO, retention is reach
Azure Backup is the service that turns your RPO into a schedule. You attach a backup policy to a protected item, and the policy carries two decisions that beginners routinely collapse into one. The first is the schedule — when a recovery point is taken: daily for most workloads, or, with an enhanced policy, several times a day. The schedule is your RPO made concrete; a once-a-night job means that, at worst, you lose everything since last night, so its RPO is twenty-four hours, no matter what number you wished for.
The second decision is retention — how long each recovery point is kept before it is aged out: keep dailies for a month, a weekly point for twelve weeks, a monthly for a year, a yearly for seven. Retention is not housekeeping; it is how far back in time you can reach, and it matters more than beginners expect, because the ransomware you eventually need to recover from was often quietly encrypting files for weeks before anyone noticed. A policy that keeps only three days of points is useless against a compromise that started a fortnight ago — the clean copy has already been aged out. Schedule sets what you lose in the everyday case; retention sets whether you survive the slow disaster.
- Schedule
- The cadence of recovery points — daily, or several times a day on an enhanced policy. This is the RPO you actually get, not the one you asked for.
- Retention
- How long each daily, weekly, monthly, and yearly point is kept. This is your reach into the past — sized against threats that hide for weeks, not against last night.
- Full vs incremental
- The first recovery point is a full copy; every one after transfers only the blocks that changed, which is what makes frequent points affordable in time and storage.
- On-demand backup
- A point you trigger by hand the moment protection is configured — so you hold a recovery point immediately and have watched a job succeed, rather than trusting the first scheduled run.
Set retention against the threat model, not against a round number that feels tidy. The honest question is never "how many days looks reasonable" but "how long could something be wrong before we notice, and can we still reach a clean point when we do." Answer that and the retention rules write themselves; skip it and you will discover the gap on the one day the whole apparatus was built for.
The restore — the half nobody rehearses
A backup exists to be restored, and the restore is the half everyone skips until the disaster. The verbs matter: a successful backup job proves data went in; only a restore proves it can come out, and the two are not the same claim. The restore options differ by how much you lost, and choosing among them under pressure is easier if you have named them in advance.
A backup you never restore is a rumour.
- Item-level
- File- or item-level restore — someone deleted one spreadsheet or one folder. You browse a recovery point and pull back exactly those items to their original place or an alternate one; fast, surgical, and the most common restore you will ever run.
- Full VM
- Full-machine restore — a whole VM is gone or corrupted. You either restore the disks and build a new VM from them, or create a replacement VM directly from the recovery point; slower, and the one that eats into RTO.
- Cross-region
- Restore in the paired region — where the vault is GRS and Cross Region Restore is enabled, you can restore in the secondary region even while the primary is unavailable; the backup equivalent of not keeping the only spare key inside the burning house.
Cross-region restore is the one with a prerequisite worth memorising, because it is invisible until you need it and then it is too late to turn on. It is not automatic with GRS: the vault must be geo-redundant and have Cross Region Restore switched on, an opt-in you make while the estate is calm, not during an outage.2 With it enabled you can browse and restore the secondary-region copy on demand — the difference between "the primary region is down but we can still recover" and "the primary region is down and so is our only copy of the recovery path."
Notice what Azure Backup does not give you: it does not keep a second copy of your application running and ready to serve traffic. Restoring a VM from last night's recovery point might take an hour, and it brings back last night's data — fine for an RPO of a day and an RTO of hours, useless for a checkout system that must survive a whole-region outage with minutes of tolerance. That workload needs Azure Site Recovery, which is the next part. Backup is the right tool for the Tier-2 data that can wait a day; it is the wrong tool for the revenue organs, and knowing the boundary is the judgement this class is really teaching.
The catalogue and the file share, protected at Tier-2 grade
Campux does not protect everything the same way, because it cannot afford to and should not want to. Checkout and the orders database — the revenue organs — get the minutes-RPO treatment that Part E builds. But the product catalogue and an Azure Files share the merchandising team edits by hand are Tier-2: annoying to lose, not fatal, and comfortable with a whole day's RPO. So the reader gives them the honest, cheap machinery of this part — a single Recovery Services vault, GRS so a regional incident does not take the only copy, a daily backup policy with dailies kept a month and a monthly point kept a year, and soft delete left on so a deleted recovery point survives a fortnight past its deletion. When a merchandiser overwrites the wrong price file on a Thursday, the fix is a four-minute item-level restore from Wednesday night, not a crisis.
The discipline is in the honest rating, not the tooling. Campux writes down, in one line, that the catalogue carries a twenty-four-hour RPO and a few hours of RTO — and that this is a choice, priced and adequate, not a compromise nobody dared name. The failed disk in the closet took whatever it wanted because no one had decided in advance what any of it was worth. Nothing since has been allowed to.
Soft delete — surviving a hostile administrator
Every guardrail so far protects data against accident and hardware. Soft delete protects the backups themselves against a person — and that is a different and nastier threat. Picture the modern ransomware playbook: the attacker breaches the estate, and before encrypting anything they go looking for the backups and delete them, so that when the ransom note lands you have no clean copy to recover from and no choice but to pay. Soft delete is the answer to exactly that move.
When someone deletes backup data — maliciously or by mistake — Azure does not destroy it immediately. It holds the deleted recovery points in a soft-deleted state for a retention window, during which they can be undeleted, and the default window is fourteen days at no extra charge (extendable up to 180 days, with cost beyond the first fourteen). The window matters because it has to outlast the time between the deletion and the moment a human notices something is wrong. Azure has moved this from an option to a default: soft delete is now enforced by default on Recovery Services vaults under a "secure by default" posture, and in the regions where that is generally available it can no longer simply be switched off — which is the platform quietly agreeing that the person who wants soft delete disabled is more often the attacker than the administrator.3
There is a teardown edge that catches everyone once. A vault that still holds soft-deleted items refuses to be deleted; you must stop protection and let the items clear — or wait out the window — before Azure will release the vault. This is the guardrail working as designed: the same rule that stops an attacker wiping your backups also stops you from tidying a vault away in a hurry, and discovering the difference in the portal is a rite of passage. When someone on your team proposes disabling soft delete "to save a bit of money" or "to unblock a delete," the right instinct is to slow down and ask what it is actually protecting against — because the saving is a rounding error and the exposure is the whole recovery story.
The delete that did not become a disaster
An automation script with too much scope removes a protected item, or a colleague deletes the wrong recovery series. On an estate without soft delete, that is a silent, permanent hole you find at the worst possible moment. On yours, the points sit in a soft-deleted state for two weeks, you undelete them, and the incident is a five-minute footnote instead of a headline. You did nothing heroic — you left a default on and understood why it was there. That is the shape of most of the good decisions in this domain: unglamorous guardrails, kept, whose value only shows on the one day you needed them.
Examination
Four drills, then two situations. Write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B — data loss is RPO, downtime is RTO. "Lose at most the last fifteen minutes" is about data: it points backward from the disaster to the last good recovery point, which is the definition of RPO. "Trading again within two hours" is about time down: it points forward from the disaster to service restored, which is RTO. A and C are the same inversion that sinks people on the exam and, worse, on the job — where inverting them means you build a fifteen-minute-recovery system that only backs up every two hours, precisely backward from what the business asked, and you discover it mid-disaster. D confuses retention, which is how far back your recovery points reach, with the objectives themselves. The habit that immunises you: RPO points back, RTO points forward, said until the words arrive before the panic does.
B — the Recovery Services vault does both. VM backup and Azure Site Recovery are the two jobs a Recovery Services vault was built for, which is exactly why it is the answer whenever a scenario pairs "back up VMs" with "replicate to another region." A is the seductive trap: the Backup vault is newer, but newer is not broader — it serves blobs, managed disks, PostgreSQL, and AKS, and it does not do Azure VM backup or Site Recovery. Choosing by recency instead of by workload is how you land in the wrong blade wondering where the option went. C mistakes a storage feature for a backup service; soft delete protects data, it does not schedule or orchestrate it. D invents a split that does not exist. The exam-durable fact: VMs, Files, and Site Recovery live in the Recovery Services vault; the newer workloads live in the Backup vault.
Retention is reach, the daily schedule is a 24-hour RPO, and soft delete holds deletes for a default 14 days. Those three are the load-bearing facts of this part: retention decides whether a clean copy still exists when a weeks-old compromise surfaces; the schedule — not the wish — sets the RPO you actually get; and soft delete is the free guardrail that survives a hostile delete. The two rejects are the confusions to burn out. Schedule and retention are different decisions — one is when points are taken, the other is how long they are kept — and collapsing them is how people build a fortnight of retention on a nightly job and think they have a fifteen-minute RPO. And soft delete does nothing to your RPO; it protects backups from deletion, it does not change how fresh they are. Mix those up and you will size the wrong thing against the wrong threat.
# campux — product catalogue backup policy
1. Vault: Recovery Services vault, GRS,
soft delete left on (default 14 days).
2. Schedule: daily recovery point, 02:00.
3. Retention: keep daily points for 3 days;
no weekly or monthly points.
4. Restore drill: item-level restore rehearsed
quarterly to an alternate location.
Line three — the retention is too short to reach a clean copy. Retention is your reach into the past, and three days of it means that a compromise which began two weeks ago has already aged out every clean point; when you go to restore, the oldest thing you can reach is itself already encrypted. The schedule is fine for a Tier-2 catalogue and the vault is right; the fix is to keep dailies for a month and a monthly point for a year, so the clean copy still exists when a slow disaster finally announces itself. The distractors are all plausible and wrong: GRS and soft delete are complementary, not exclusive (A); a daily point is exactly correct for a day-RPO workload (B); and restoring to an alternate location is the safer rehearsal, since it proves recovery without touching the live copy or losing it for forensics (D). The test for any retention line: can it still reach a good point after a threat that hid for weeks? Three days cannot.
Concede the instinct, then price both sides. Watching the bill is the right habit — Class Thirty-Two rewards exactly this reflex — so start by agreeing with the impulse before disagreeing with the target. Then put real numbers on it: the default fourteen-day window is free, so for most estates the "saving" is zero or a rounding error, while the thing it defends is the entire recovery story. Do not argue from principle; argue from the invoice, which is the language the proposal is written in.
Name the exact threat it removes. Soft delete exists for one nasty move: an attacker breaches the estate and deletes the backups before encrypting, so that when the ransom lands you have no clean copy and no choice but to pay. Disabling it does not save money so much as remove the one guardrail between a bad Tuesday and writing a cheque to a criminal. That is why Azure now enforces it by default and, in many regions, will not let you turn it off at all — the platform has decided the person who wants it disabled is usually the attacker.
Redirect the cost hunt somewhere real. Close by keeping your colleague on side: the money is not in the soft-delete window, it is in over-long retention on low-value workloads, in Tier-1 protection accidentally applied to disposable data, in orphaned recovery points for resources long gone. Offer to hunt those together. You have protected the guardrail and honoured the goal — and shown that "cut cost" and "keep soft delete" were never actually in conflict.
The trap is "newest equals best." With a failed disk, the freshest recovery point is the right one, because everything up to the failure was healthy. Corruption inverts that instinct: every recovery point taken after the corruption started already contains the corruption. Restore the newest one and you have faithfully recovered the poison — service comes back and the data is still wrong. The freshness that saves you in a hardware failure is precisely what damns you in a slow logical one.
Find the last clean point, not the last point. The real task is to locate when the corruption began — the monitoring signal says roughly eleven days — and restore the most recent recovery point from before that moment. This is where retention earns its keep: if the policy only kept a few days, that clean point has already aged out and you have nothing to reach; because it keeps weeks, you can. Restore a candidate to an alternate location first, verify the records are sound, and only then decide how to bring it into production.
Then own the cost of the choice. Restoring an eleven-day-old clean copy means consciously accepting the loss of eleven days of legitimate changes mixed in with the corruption — an RPO the business did not sign up for, forced by a threat that hid. Say that out loud, quantify what those days contained, and decide with the owner whether some of it can be replayed or reconciled. The engineering was picking the right point; the seniority is naming the data loss honestly instead of pretending the restore made everyone whole.
Five things worth carrying out of this part
- Recovery starts with two signed numbers, not a tool: RPO (how much data you can lose — points back) and RTO (how long you can be down — points forward). Tighter numbers cost more, always.
- Recovery points live in a vault, isolated from what they protect. The Recovery Services vault holds VMs, Files, and Azure Site Recovery; the newer Backup vault holds blobs, disks, PostgreSQL, and AKS. Workload dictates the vault.
- A backup policy is two decisions: the schedule is the RPO you actually get, and retention is how far back you can reach — size retention against threats that hide for weeks, not against last night.
- The restore is the half nobody rehearses. Item-level for a deleted file, full-VM for a lost machine, cross-region from the paired region — but cross-region needs GRS with Cross Region Restore switched on in advance.
- Soft delete holds deleted recovery points for a default fourteen free days, defeating the attacker who deletes your backups before encrypting. Azure now enforces it by default; do not switch it off to save a rounding error.
- Storage-redundancy names and defaults shift, and once backup data exists in a vault some redundancy settings can no longer be changed — set them while the vault is empty. Treat LRS / ZRS / GRS as the stable trio (one datacentre, one region's zones, the paired region) and confirm the current defaults and the "can't change after the first backup" rule on Microsoft Learn before you commit a production vault. ↩
- Cross Region Restore is an opt-in on top of geo-redundant storage: the vault must be GRS and have the Cross Region Restore setting enabled, and the exact list of workloads it supports grows over time. Enable it before you need it and verify current support on Microsoft Learn; a DR plan that assumes cross-region restore without checking the vault setting is a plan that quietly fails in the outage it was written for. ↩
- Soft-delete behaviour is in active motion. Microsoft has moved to "secure by default": soft delete is enforced by default on Recovery Services vaults and, in regions where that is generally available, can no longer be disabled; the default window is fourteen days (free), extendable to 180 (charged beyond fourteen). Some of this is still rolling out — Backup-vault enforcement and the always-on rules vary by region and API version — so treat fourteen days and "on by default" as the settled direction and confirm the exact current defaults for your region before you rely on them. ↩