Contoso Airlines now has a platform that can be seen and that largely operates itself. What is missing is the question of the bad day, the one nobody wants to ask until it arrives: somebody deletes the wrong resource group by mistake, ransomware encrypts a server, an update corrupts the bookings database, or an entire Azure region stops responding. None of those things is solved by a dashboard or an alert. They are solved — or not — by what you prepared beforehand.

This lesson closes the module with the least glamorous and most decisive part of operating in the cloud. You will see the real difference between backup and disaster recovery, the two numbers that govern every decision, Azure Backup and its vaults, protection against malicious deletion, what each PaaS service backs up on its own and what remains yours, and Contoso's full strategy across West Europe and North Europe, with its written plan and its drill. Because a platform you cannot restore is not finished.

1. Backup versus disaster recovery
2. RPO and RTO: the two numbers that govern everything
3. Azure Backup: vaults, policies and workloads
4. Redundancy, soft delete and immutability against ransomware
5. Restoring: whole machine, disks and individual files
6. What each PaaS service backs up and what remains yours
7. Azure Site Recovery
8. Contoso's recovery strategy
9. The written recovery plan
10. The drill: an untested plan does not exist
11. Recovering what was deleted: locks, Bicep and configuration backups
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

They get confused constantly and they solve different problems.

The distinction has a practical consequence many people discover too late: replication is not a backup. If ransomware encrypts the disk in the primary region, geo-replication dutifully replicates the encrypted disk to the secondary in seconds. Replication protects against infrastructure failure; only an immutable backup with history protects against error and attack. You need both.

The whole architecture in this lesson derives from two questions put to the business:

• RPO (recovery point objective): how much data can we afford to lose? It is measured in time. An RPO of 15 minutes means accepting the loss of the last 15 minutes of work.
• RTO (recovery time objective): how long can we be down? From the moment the disaster happens to the moment the service is back.

The conversation always goes the same way: you ask the business and it answers "zero and zero". That is where you have to translate it into money, because both numbers are inversely proportional to cost, and very steeply so. Bringing the RPO down from 24 hours to 1 hour is affordable; from 1 hour to zero demands synchronous replication, which also penalizes the write latency of every transaction. Bringing the RTO down from 8 hours to 1 hour means having the secondary infrastructure already created and being paid for. The right question is not "how much do you want?", it is "how much does an hour of downtime on this system cost, and are you willing to spend less than that to avoid it?".

With that conversation done, Contoso set its levels:

Look at the last row and at the analytics platform's third column: not everything deserves the same level, and deciding that a system has a 72-hour RTO is as legitimate and as deliberate an architecture decision as deciding another one has an RTO of one hour. Applying the maximum level to everything is the fastest way to multiply the bill without improving what matters.

Azure Backup is the managed backup service. There is no backup server, no agent to license, no tapes. Its two containers:

Both live in rg-contoso-seguridad-pro, separate from the resources they protect. That is not cosmetic: if the vault is in the same group as the workload, an accidental deletion of the group takes the data and its backup at the same time.

A backup policy defines the frequency and the retention in a grandfather-father-son scheme:

Contoso's pol-backup-vm-diaria policy: a daily backup at 02:00, 30 daily points, 12 weekly, 12 monthly and 7 yearly. The long retention answers an uncomfortable reality: corruption and ransomware are detected late, sometimes weeks later, and a seven-day retention leaves you with no clean point to go back to.

Two important operational details. Backing up an Azure VM uses disk snapshots, with no agent and with the machine running; for databases inside the VM you need application consistency, which on Windows is provided by VSS and on Linux requires your own pre- and post-scripts. And the operational backup of disks and blobs keeps local snapshots so you can restore in seconds, complementing — not replacing — the vault backup.

The vault's redundancy reuses what you learned in module 2 about Azure Storage:

Contoso uses GRS with cross-region restore enabled on rsv-contoso-pro. This setting has a classic trap: the redundancy can only be set before the first item is protected. After that it is immutable, and changing it forces you to create a new vault and protect everything again, losing the history. It is one of those decisions that costs very little to get right on day one and a great deal to correct a year later.

Now, the part that separates a real backup from an illusion of safety. An attacker who gets hold of credentials with permissions does not attack the data: they attack the backups, because they know that without them the ransom gets paid. Azure Backup's three defenses:

• Soft delete: when a backup is deleted, it does not disappear; it is retained for 14 days — extendable — and can be recovered. In its enhanced form it can be made irreversible, so that not even an administrator can shorten that period.
• Vault immutability: once locked, it prevents reducing the retention, deleting recovery points or stopping protection while retaining the data. The lock is irreversible, and that is exactly its value: if it could be reverted, the attacker would revert it.
• Multi-user authorization (MUA): critical operations — disabling soft delete, reducing retention, removing protection with its data — require the approval of a second principal, protected by a resource guard that lives in another subscription and under another administrator. Compromising a single account is no longer enough.

Round it out with what you know from module 4: strict RBAC on the vault — very few people need the backup contributor role — alerts on delete operations in AzureActivity (07-01), and Microsoft Defender for Cloud watching for anomalous access. The rule to take away: a backup an attacker with permissions can delete is not a backup.

Azure Backup offers three granularities, and choosing the right one changes the RTO completely:

Item-level restore deserves attention because it solves nearly every real request — "I need the configuration file from before the change" — without touching the machine in production: it mounts the recovery point as a temporary drive, you copy, and you unmount. And cross-region restore lets you recover in North Europe from the geo-replicated backup when West Europe is unavailable; without the cross-region-restore-flag enabled in advance, that door simply does not exist on the day you need it.

This is the most expensive misunderstanding in the cloud: assuming that "the service already does backups". Sometimes it does, but it almost never covers what you think.

Three concrete warnings. In Storage, redundancy protects against hardware failure and not against somebody deleting a blob: that is covered by versioning and soft delete, which have to be explicitly enabled on sttarjetascontosopro. In Key Vault, without purge protection a deleted secret can be purged permanently before the soft delete period expires. And in AKS, versioned manifests let you rebuild the platform, but they do not give you back the contents of the persistent volumes.

Site Recovery replicates whole machines — from Azure to another region, or from an on-premises datacenter into Azure — maintaining a consistent recovery point, and it orchestrates the failover.

Its three capabilities: continuous replication with a typical RPO of seconds to a few minutes; recovery plans that define the start-up order by groups, with scripts and manual pauses between them; and, the most valuable of all, the test failover, which brings the machines up on an isolated network in the secondary region without affecting production and without interrupting replication. That is what makes genuine rehearsal possible, and it is the basis of the drill in section 10.

Contoso uses it exclusively for vm-motor-disponibilidad-dev and for two on-premises servers in Barcelona. For PaaS workloads it adds nothing: app-contoso-reservas-pro is recovered by redeploying from Bicep in minutes, and db-reservas has its own failover group. Site Recovery is the tool for whatever is still a machine, and a well-migrated platform needs it less and less.

The pieces and the reason for each one. The region pair West Europe and North Europe is not arbitrary: Azure paired those regions, and that means sequential platform updates across the two, recovery priority and native geo-replication. fg-contoso-reservas keeps the db-reservas replica in North Europe and provides a stable listener endpoint, so the application does not change its connection string when it fails over. fd-contoso-global probes the /salud health endpoint and routes to the healthy region. The storage is GZRS, which combines zone redundancy in the primary with a geo-replica.

And the decision that was argued over most: pilot light, not active-active. In North Europe the plans, applications, slots and configuration all exist, but at minimum scale and with no traffic; when it fails over, it scales up and takes the load. The alternatives and their economic reality:

Contoso ruled out active-active for two reasons, and the second weighed more than the first: it doubled the production bill, and it required solving multi-region writes in the database, with conflicts, latency and a complexity that would have hurt day-to-day reliability in order to protect against an improbable event. The real RTO measured in the last drill was 1 hour and 47 minutes, of which 25 minutes were the human decision to fail over. That is an honest and revealing figure: the slowest part of a recovery is usually not the technical part.

A plan that lives inside Marta Ríos' head is not a plan: it is a single point of failure that takes holidays. plan-recuperacion-contoso is a document versioned in contoso-infra that answers five questions.

Who decides. The failover is declared by the on-call lead together with the operations director, with objective criteria written down in advance — for example, "the health endpoint has been failing from three locations for more than 20 minutes and Azure confirms a regional incident". Deciding with agreed criteria avoids 3 a.m. paralysis.

In what order. The order matters because the dependencies are real: (1) confirm the scope with Azure Service Health; (2) fail fg-contoso-reservas over and verify that the replica accepts writes; (3) scale up the North Europe plans; (4) verify kv-contoso-pro and the managed identities in the secondary region — the most frequent oversight; (5) redirect fd-contoso-global; (6) validate with an end-to-end test purchase; (7) re-enable the functions and integration workflows.

How it is communicated. An incident channel, a notification to passenger support with a message already drafted, a public status page and updates every 30 minutes even when there is no news. Silence is always read as nobody doing anything.

How you fail back. Failing back is more dangerous than failing over, because it is done in a hurry and with the feeling that the worst is over. It is done in a scheduled window, never on the fly, after confirming that the primary region is stable, resynchronizing the data in the reverse direction and verifying that nothing written during the contingency has been lost.

What you need to hand. Contacts, subscription identifiers, the location of the Bicep templates and emergency access. With one nuance learned the hard way: that material cannot depend on the region that is down. Contoso keeps a copy of the plan outside Azure, and an emergency access account whose credentials are held in physical custody.

Every organization has a recovery plan. Very few have one that works, and the difference is exactly whether it has ever been executed. Contoso runs a half-yearly drill to this script:

1. Preparation (two weeks in advance): the date announced, the scope defined and the success criteria written down — target RTO, target RPO, test transaction passed.
2. Freeze: no deployments during the window; an alert processing rule active to suppress the expected noise (07-01).
3. Execution against the clock, following the plan literally, without improvising and without anybody "fixing" on their own initiative something that is not written down. If the plan is wrong, it has to fail in the drill.
4. Validation: buy a real test ticket, issue its boarding pass and check the telemetry in log-contoso-pro. The success criterion is a business one, not a technical one.
5. Controlled failback, timed as well.
6. A blameless post-mortem within the next 48 hours, with concrete actions, owners and dates, which get folded back into the plan.

What Contoso learned the first time it did this, and that no document would ever have revealed:

• The connection string on func-contoso-tarjetas-pro pointed at the primary server by name, not at the failover group's listener. Boarding passes stopped being issued even though the database was available.
• Nobody had permission to scale up the North Europe plans: the RBAC assignment had only been made on the primary production group.
• The certificate for the secondary domain had expired three months earlier, without anybody noticing because it was not being used.
• The first drill took 4 hours and 20 minutes; the third, 1 hour and 47. The improvement came from finding those three faults, not from buying more infrastructure.

That leaves the most common case of all, which is not a regional disaster but an az group delete in the wrong terminal window. The defenses, in order:

• Resource locks: CanNotDelete on every production group and on the vaults. It is the cheapest and most effective measure in this lesson. A ReadOnly lock goes further but interferes with normal operations, so Contoso reserves it for rg-contoso-red-pro.
• A deleted subscription: it can be reactivated within a limited period from billing. A deleted resource group cannot: there is no recycle bin. The only thing that gives you back the data is the backup, and the only thing that gives you back the infrastructure is the code.
• Bicep in contoso-infra (module 5): rebuild the entire infrastructure from the templates, repeatably and in minutes. This is the underlying reason why infrastructure as code is not an aesthetic preference: it is your infrastructure recovery plan.

And the final point, the one almost nobody considers: you have to back up the configuration, not just the data. NSG rules, RBAC assignments, diagnostic settings, alert definitions, policies and WAF rules. If all of that lives only in the portal, restoring the data leaves you with a platform that does not work. At Contoso it lives in Bicep, and whatever does not fit in Bicep is exported periodically with a runbook from aa-contoso-operaciones (07-04) into stlagocontosopro. The secrets in kv-contoso-pro deserve a separate mention: they are backed up with their own mechanism and can only be restored into a vault in the same tenant and geography.

• Confusing replication with backup. The replica copies the corrupted or encrypted data too. You need both things.
• Keeping the vault next to what it protects. Deleting the group takes the data and the backup at once.
• Not enabling cross-region restore when you create the vault. The redundancy cannot be changed afterwards.
• Retention that is too short. Ransomware and corruption are detected weeks later.
• Assuming PaaS does backups. Storage does not protect against deletion without versioning; AKS does not back up your volumes.
• Not testing the restore. A backup that has never been restored is a hypothesis, not a backup.
• Tip: put a CanNotDelete lock on every production group today. It takes a minute.
• Tip: measure the real RTO with a stopwatch in the drill and publish it. The measured number is always worse than the estimate, and that is the value of the exercise.
• Tip: include a business test in the validation — buy and issue — not just a ping. Services can respond and the flow still be broken.

Exercise 1. The business demands an RPO of 0 and an RTO of 5 minutes for db-reservas. Explain what that implies technically, what it costs and what counterproposal you would make, with arguments.

Exercise 2. Ransomware has encrypted vm-motor-disponibilidad-dev and it was detected six days later. Describe the recovery step by step and which preventive measures would have reduced the impact.

Exercise 3. Contoso Miles (centro-coste=CC-2077) is going to production with a PostgreSQL flexible database, blobs of redemption receipts and a Container App. Design its backup and recovery strategy with justified RPO and RTO, stating what each service contributes on its own and what has to be added.

Solution 1: an RPO of 0 requires synchronous replication: every transaction is committed in both regions before answering the user. That adds the round trip between West Europe and North Europe to every write, degrading purchase performance under normal conditions in order to protect against an event that happens every few years; and fg-contoso-reservas, which is asynchronous, does not provide it. An RTO of 5 minutes requires automatic failover with no human decision, with the secondary infrastructure already scaled and running — active-active, with the 100% additional cost from the table in section 8 — and with the added risk of a spurious failover on a transient network problem. Counterproposal: keep the RPO at 5 minutes, which is what asynchronous replication gives without penalizing daily operations, and bring the RTO down to 30 minutes with two cheap measures: pre-agreed decision criteria, automated up to the point of approval — the 25 minutes of deliberation measured are the biggest single term — and a runbook that scales North Europe up automatically once the condition is detected. The argument for the business: quantify the cost of an hour of downtime and compare it with the annual cost of active-active; if the second exceeds the first multiplied by the annual probability of the event, the investment is not justified. And complement it with graceful degradation: a read-only cache that lets passengers look up their bookings during the failover protects the passenger experience for a fraction of the price.

Solution 2: recovery. (1) Isolate: take the machine off the network with an NSG that blocks everything, without shutting it down if you want to preserve memory evidence; do not restore over the compromised machine. (2) Determine the infection date with the telemetry in log-contoso-pro and AzureActivity, looking for the first anomalous indication: six days to detection means the most recent points are probably already encrypted. (3) Choose a recovery point earlier than that date, which is only possible thanks to the 30 daily points retained by pol-backup-vm-diaria. (4) Restore to a new machine in an isolated group, verify that it is clean and only then bring it back in. (5) Check that the vault was not attacked, reviewing AzureActivity for attempts to delete recovery points. (6) Rotate every credential reachable from that machine. (7) Post-mortem and security notification as appropriate. Prevention: vault immutability and irreversible soft delete, which is what stops the attacker deleting the points; multi-user authorization so a single compromised account is not enough; long retention, without which six days of detection latency would leave you with no clean point; Defender for Cloud alerts and alerts on delete operations in the vault; and minimum RBAC, because attacking the backups requires permissions almost nobody should have.

Solution 3: by criticality, a loyalty project does not block ticket sales, so an RPO of 1 hour and an RTO of 8 hours are reasonable and very cheap to sustain; it is worth writing that down and having the business sign it off. PostgreSQL flexible contributes automatic backups on its own: you have to extend the retention to 35 days, enable geo-redundant backups and export the schema with every deployment; a read replica in another region is not needed for that RTO. Receipt blobs: redundancy does not protect against deletion, so you have to enable versioning, blob and container soft delete, and operational backup from bv-contoso-pro; if the receipts have evidentiary value, add a time-based immutability policy as well. Container App: it holds no state, it is rebuilt from the acrcontosopro image and the Bicep template, with the precaution of keeping the tagged images in the registry and its own geo-redundancy. Cross-cutting: the vault in rg-contoso-seguridad-pro, a CanNotDelete lock on the production group, the configuration in Bicep inside contoso-infra, and an annual drill — not half-yearly, given the level — whose success criterion is redeeming test points end to end. Tags: entorno, proyecto=contoso-millas, centro-coste=CC-2077 and propietario.

You can now tell backup from disaster recovery, and you know that replication protects against neither error nor attack because it faithfully replicates the corrupted data. You have mastered the two numbers that govern every decision — RPO and RTO — the conversation with the business that sets them and their translation into money, with Contoso's table of levels that deliberately assigns one hour of RTO to db-reservas and seventy-two to the analytics platform. You know Azure Backup, its two vaults rsv-contoso-pro and bv-contoso-pro, the pol-backup-vm-diaria policy with its grandfather-father-son retention, and why the vault lives separately from what it protects. You know how to choose the redundancy — with the trap that it is immutable after the first item is protected — and how to protect the backups from the attacker themselves with irreversible soft delete, immutability and multi-user authorization, because a backup an attacker with permissions can delete is not a backup. And you know how to restore at all three granularities, including the item-level restore that solves 90% of real cases.

You are clear about the PaaS boundary: what each service backs up on its own and what remains yours, with the three warnings that cost the most — Storage does not protect against deletion without versioning, Key Vault needs purge protection enabled, and AKS does not back up your volumes. You place Azure Site Recovery in its territory, whatever is still a machine, with its test failover. And you understand Contoso's strategy in full: the West Europe and North Europe region pair, fg-contoso-reservas, fd-contoso-global, GZRS storage and the reasoned decision of a pilot light instead of active-active, with its 15% cost and its measured RTO of 1 hour and 47 minutes. Above the technology you carry the two pieces that really decide the outcome: the written plan — who decides, in what order, how it is communicated, how you fail back — and the half-yearly drill, which at Contoso exposed a connection string pointing at the wrong place, some missing permissions and an expired certificate, three things no document would ever have revealed. Plus the locks, Bicep as the infrastructure recovery plan and backing up the configuration, not just the data.

That closes module 7, and it is worth looking back. Contoso Airlines came in with a distributed platform nobody knew how to operate and leaves with a very different one: observable, because Azure Monitor collects metrics, logs and traces, and the diagnostic settings carry everything to log-contoso-pro; investigable, because KQL turns a passenger's complaint into a root cause in five queries and the SeguirLocalizador function puts that capability in anybody's hands; traceable end to end, because Application Insights correlates a booking across the six components that serve it; automated, because aa-contoso-operaciones runs the repetitive work with a managed identity, versioning and monitoring; and now recoverable, with immutable backups, a written plan and a drill that puts it to the test twice a year. The question "what happened to this booking?" has an answer, and so does the question "what if it all disappears tomorrow?".

One conversation remains outstanding, and it is the one Nuria Peña has been asking for over months. Every decision across these seven lessons has had a price: the paired regions, the replicas, the scale sets, the Log Analytics workspace with its ingestion, the North Europe pilot light, the backups with thirty days of retention. Nobody at Contoso knows today, with any precision, how much each piece of the platform costs, or what part of that bill is value and what part is waste. Module 8, Cost Management and Optimization, tackles exactly that: how you estimate before deploying, how you analyze and budget afterwards, what discounts exist and when they pay off, what Azure Advisor recommends and how you build a FinOps culture that optimizes without breaking anything. And it starts where it has to start: learning to estimate the cost before creating the resource, with the pricing calculator, because the hardest bill to correct is the one you have already caused.