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 agreed maximum gap between the latest recoverable data and a disruption. A one-hour RPO needs a tested method that can recover to within one hour. Backup frequency matters, but failed jobs and replication delay can leave the latest usable point older than the schedule suggests.
- RTO
- Recovery Time Objective — the target maximum time to restore service after a disruption. A four-hour RTO needs a recovery procedure tested under realistic conditions. Restore time is one part of it; approvals, infrastructure, data validation, and traffic switching also take time.
Use a timeline to keep them apart. The age of the latest verified clean recovery point when failure occurs is an observed recovery gap; compare it with the RPO. The time from disruption to restored service is the observed downtime; compare it with the RTO. A tighter objective usually needs more frequent recovery points, replication, automation, or ready capacity. Choose the architecture from the business requirement, then test whether it meets that requirement.
The vault — where recovery points live
Azure Backup uses vaults to manage backup policies and recovery jobs. Check where the backup data actually resides: an Azure Files snapshot backup remains in the file share's storage account, while a supported vaulted backup copies data into vault storage. This distinction matters for regional resilience. A vault's geo-redundant setting does not move snapshot-only Azure Files data to another region.
- Vault
- A managed Azure resource for backup configuration and recovery. Whether the protected data is stored in the vault or as a workload snapshot depends on the backup tier and workload.
A Recovery Services vault supports Azure VM backup, Azure Files backup, and SQL Server or SAP HANA backup in Azure VMs; Azure Site Recovery also uses it for supported replication scenarios. A Backup vault supports other workloads, including Azure Blobs, managed disks, PostgreSQL, and AKS, subject to each workload's support matrix. Select the vault and backup tier for the workload and required recovery path. Vault storage can use LRS, ZRS, or GRS where supported, but GRS does not by itself make a workload restorable on demand in another region. Check Cross Region Restore support and enable it where required. Set redundancy before protecting data, because some choices then 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, success, and retention
A backup policy sets when Azure Backup attempts recovery points and how long it retains them. The schedule is a design input to the RPO, not proof that the objective is met: a failed job, an unclean point, or cross-region replication delay can make the latest usable point older. Check job success, point age, and restore tests against the agreed RPO.
Retention determines how long recovery points remain available. If corruption started two weeks before anyone noticed, three days of retained points may leave no clean copy. Set retention against a realistic detection delay and compliance needs. The schedule determines when jobs run; successful, clean points determine what can be restored.
- Schedule
- When backup jobs run. Check completed, usable recovery points to learn the achieved point age; the schedule alone is not the RPO you achieved.
- 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
- Supported workloads can reduce later backup transfer by capturing changes after a baseline. The exact method depends on the backup type and workload.
- On-demand backup
- A manually triggered job. Confirm it completes and creates a usable point; then test restoration separately.
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.
For supported workloads, Cross Region Restore lets you access secondary-region recovery points on demand when the vault uses GRS and the feature is enabled. Check the workload, region, network, and permission limits before relying on it.2 Secondary copies can lag: Microsoft documents up to 36 hours of secondary-region RPO for some Azure VM backup policies. Run a regional restore drill and compare its actual point age and duration with your targets.
Backup does not keep an application running in standby. A service with a short regional recovery target may need replication, a ready secondary environment, or other architecture described in Part E. Backup can still be essential for that service, especially for corruption or deletion. Test the complete service recovery path; neither backup nor Site Recovery alone proves that checkout is usable.
The catalogue and the file share, protected at Tier-2 grade
In this fictional case, Campux protects the product catalogue stored in an Azure Files share. The team selects an Azure Files vaulted backup tier in a Recovery Services vault because it wants a separate backup copy. It verifies that the chosen region and workload support the required restore path, sets vault redundancy before protection, and configures daily recovery points with retention long enough to reach a clean copy after a delayed discovery. The team then restores a sample file to an alternate location and measures the result. A snapshot-only Azure Files backup would remain in the source storage account; the vault's GRS choice would not provide the same separation.
Campux's business owner agrees the catalogue's RPO and RTO before an incident. A daily schedule is only a candidate for a roughly day-long RPO; backup job results and a restore drill must show what the team can actually achieve. The drill's measured recovery time is compared with the RTO, including file validation and returning the share to use.
Play it through
Three minutes. In a fictional Azure Files vaulted-backup scenario, corruption starts after Wednesday's 11pm point and is discovered Thursday at 6am. Choose a point from before the damage, test the restore, and plan a repeat drill. The seven-hour point age is an example; it does not measure how many edits were actually lost.
The activity above is a simulation. To test a real restore, use the separate lab: Back up and restore an Azure file share. Check which backup tier its steps configure, restore a file to an alternate location, verify it, and remove test resources using the documented teardown steps. Actual time and charges depend on the selected resources.
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.
Soft delete can retain deleted backup data for a recovery window, commonly 14 days without an additional soft-delete storage charge; supported configurations can extend the window up to 180 days with associated costs. New vaults commonly have soft delete enabled, but enabled and always-on are different settings. Always-on is a stronger, irreversible protection where supported. Check the current vault type, region, and security settings before relying on either mode.3
Vault deletion requires handling protected items and retained backup data according to the vault's current security settings. Do not weaken soft delete merely to make teardown quicker. If cost is the concern, inspect the actual storage bill and retention policy first, then adjust protection only with the data owner's approval and a tested recovery plan.
The delete that did not become a disaster
An over-scoped script deletes a protected item. The engineer checks the vault's soft-delete state and retention window, confirms the affected backup data remains recoverable, and follows the supported undelete procedure. They then test a restore before closing the incident. Soft delete buys a recovery opportunity; the time required and the outcome still depend on the vault configuration and a successful restore.
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, usable point age, and soft delete serve different jobs. Retention determines how far back you can look for a clean copy. A daily schedule cannot support a 15-minute RPO by itself, and even a daily RPO depends on successful, usable points. Soft delete helps recover deleted backup data for its configured window; it does not make a recovery point fresher. Verify the vault's current security setting rather than assuming soft delete is always-on.
# campux — product catalogue backup policy
1. Azure Files vaulted backup in a Recovery
Services vault; GRS and soft delete enabled.
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. If corruption began two weeks ago, a policy retaining only three days cannot reach a pre-corruption point. Agree retention based on how long a problem might remain hidden, then test restoration from a point old enough to matter. GRS and soft delete protect different risks. For Azure Files, confirm that this policy uses vaulted backup; a snapshot-only backup remains in the source storage account regardless of vault GRS. Restore drills should use an alternate location when possible.
Start with the invoice and the data owner. Azure documents no additional soft-delete storage charge for the standard 14-day window in supported scenarios, but check the current workload and configuration before quoting a saving. A longer window or other stored backup data may cost more. The question is whether the measured saving justifies reducing protection against accidental or malicious deletion.
Check the actual protection and cost. Soft delete helps recover backup data deleted by mistake or by an attacker. It is one safeguard, not a guarantee against ransomware; also consider access control, immutable backups where supported, monitoring, and restore tests. Enabled-by-default and irreversible always-on are different states. Verify what the vault uses and compare any storage charge with the protection it provides before changing it.
Review the bill together. Measure stored data and retention by workload, then ask the data owner whether each policy still matches its recovery target. Do not assume the soft-delete window is the dominant cost or disable a safeguard based on an unmeasured saving.
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
- Business and service owners agree RPO and RTO before an incident. Compare verified recovery point age and actual restoration time with those targets.
- Choose the vault and backup tier by workload. Azure Files snapshot data stays in its storage account; vaulted backup stores a separate copy managed by the Recovery Services vault.
- A policy sets backup attempts and retention. Completed, clean recovery points show the achieved point age; retention determines how far back a clean point might remain available.
- Test the exact restore path: files, VM, or supported cross-region recovery. GRS alone does not guarantee on-demand secondary-region restore.
- Soft delete can retain deleted backup data. Check the vault's actual settings; enabled by default and irreversible always-on are different protections.
- 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. ↩
- Microsoft documents soft delete as enabled by default for new Recovery Services vaults and describes always-on soft delete as a separate setting that cannot be reversed once enabled. Supported retention ranges and charges vary by vault and workload. Check the current vault configuration and product documentation before relying on either protection. ↩
Back up a VM and a file share, and restore one file without restoring the world.
Play the lesson above to stamp this class.