# Implement Disaster Recovery and Backup

> Chapter 15 of the Courseiva DP-203 curriculum — https://courseiva.com/learn/dp-203/implement-disaster-recovery-and-backup

**Official objective:** 3.6 — Secure, monitor, and optimize data storage and processing

## Introduction

If you lose all your company's customer data because a data centre caught fire or someone accidentally deleted a database, you could be out of business in hours. That is the problem disaster recovery and backup solve — they are your safety net when the worst happens, ensuring you can get back up and running fast. For the DP-203 exam, you need to understand exactly how Azure handles this, so you can design systems that survive disasters, not just hope they never happen.

## The Head Chef's Backup Kitchen Analogy

A head chef runs a busy restaurant. Their main kitchen is a state-of-the-art space with all the ovens, fridges, and prep stations laid out perfectly. Every day, they cook hundreds of meals from this single kitchen. But the chef knows that a fire, a flood, or even a broken gas main could shut the whole operation down in minutes. To protect against this, the chef doesn't just hope for the best. They have a second, fully equipped kitchen in a different building across town. This is their disaster recovery site. Every night, a sous-chef takes a backup of the day's recipes — the exact ingredient lists, cooking times, and plating instructions — and stores them in a fireproof safe and on a secure cloud drive. If the main kitchen catches fire tomorrow, the chef doesn't panic. They drive to the backup kitchen, pull out the recipes, and start cooking again. The restaurant is closed for maybe an hour, not a week. The key thing is that the backup kitchen is far enough away that the same fire or flood wouldn't hit both places. The chef also tests this plan every quarter by running a 'simulated fire drill' — they actually cook a full service from the backup kitchen to make sure everything works. This is exactly how disaster recovery works in the cloud: you have your primary data centre (your main kitchen), you create backups (your recipes), you store them in a separate region (the other kitchen), and you regularly test your ability to failover (switch kitchens) so that when a real disaster hits, your business keeps running.

## Core explanation

Disaster recovery and backup are two related but distinct concepts that work together to protect your data and keep your applications running. Let's start by defining the key terms.

A **disaster** is any event that makes your primary system unavailable. This could be a natural disaster like an earthquake destroying a data centre, a human error like an admin accidentally deleting a critical database, or a technical failure like a power outage. **Disaster recovery (DR)** is the overall plan and set of procedures you follow to get your systems back online after a disaster. It's about restoring service, not just restoring data.

**Backup**, on the other hand, is the act of making copies of your data so you can restore it if the original is lost or corrupted. Think of backup as the raw material (your data copies) and disaster recovery as the whole process of rebuilding your working system using those materials.

In Azure, the main service for backups is **Azure Backup**. For disaster recovery, the primary service is **Azure Site Recovery (ASR)** . These two services work together but serve different purposes.

**Azure Backup** lets you schedule automatic backups of your virtual machines (VMs), databases (like Azure SQL Database), and files. The backups are stored in a **Recovery Services vault** — a secure container in Azure. You can choose how long to keep backups (retention) and how often to take them (frequency). For example, you might take a backup every day and keep it for 30 days, plus a monthly backup kept for a year. Azure Backup also supports **geo-redundant storage (GRS)** , which means your backup data is automatically copied to a paired Azure region hundreds of miles away. If the primary region where your backups are stored goes down, you can recover from the secondary region.

**Azure Site Recovery (ASR)** is different. It doesn't just back up your data — it replicates your entire virtual machine configuration, including the operating system, applications, and all data, to a secondary region. Replication means the changes made on your primary VM are continuously copied to the secondary VM, so the secondary VM is always up to date (with a small delay, typically a few minutes). If a disaster hits your primary region, you can failover — that is, switch all traffic to the secondary region and start running your application from there. When the disaster is over, you can failback — switch back to the primary region.

ASR is about achieving a **Recovery Time Objective (RTO)** and **Recovery Point Objective (RPO)** .
- **RTO** is the maximum time you can afford to be without your application. If your RTO is 4 hours, you need to be back up and running within 4 hours of a disaster.
- **RPO** is the maximum amount of data you can afford to lose. If your RPO is 15 minutes, you can lose at most 15 minutes' worth of data. ASR's continuous replication typically gives a very low RPO (seconds to minutes), while traditional backups might have an RPO of 24 hours if you only back up once a day.

Now, a common confusion is between **backup** and **archive**. Backup is for active recovery — you need to restore data quickly. Archive is for long-term retention of data you rarely access, like old tax records. Azure Archive Storage is cheaper but has a much slower retrieval time (hours). For disaster recovery, you use backup, not archive.

Another important concept is **redundancy**. Azure offers different levels of redundancy for your storage accounts:
- **Locally redundant storage (LRS)** : three copies of your data in the same data centre. Protects against a single server failure, but not against a whole data centre failure.
- **Geo-redundant storage (GRS)** : three copies in the primary region, then replicated to a secondary region (also three copies). Protects against a region-wide disaster.
- **Read-access geo-redundant storage (RA-GRS)** : same as GRS, but you can read your data from the secondary region even before a disaster happens. This is useful for running reports or analytics on secondary data without impacting the primary.
- **Zone-redundant storage (ZRS)** : three copies across different availability zones within the same region. Each zone is a physically separate data centre with independent power and cooling. Protects against a single zone failure.

For disaster recovery, you typically want GRS or RA-GRS for backups, and you use ASR to replicate VMs to another region.

Finally, **testing** is crucial. Having a disaster recovery plan that you never test is almost as bad as having no plan at all. Azure Site Recovery allows you to run **test failovers** using an isolated copy of your production environment. This lets you verify that the failover works, that your applications start correctly, and that you can restore traffic — all without affecting your live systems. The exam loves to ask about testing and the difference between test failover and actual failover.

## Real-world context

Let's walk through a realistic scenario. Imagine you work as a data engineer for a mid-sized e-commerce company called 'ShopFast'. You have a critical SQL database that holds customer orders, inventory, and payment information. This database runs on an Azure Virtual Machine (VM) in the West US region. Your boss asks you to implement disaster recovery and backup for this database.

First, you would set up **Azure Backup** for the VM. You navigate to the Azure portal, create a Recovery Services vault in the West US region, and enable backup. You configure a daily backup schedule at 2 AM, keeping backups for 30 days. You also enable **geo-redundant storage (GRS)** for the vault, so if West US is destroyed, your backups are safe in East US.

Second, you would set up **Azure Site Recovery (ASR)** to replicate the VM to a secondary region — say, East US. You enable replication for the VM, which creates a replica VM in East US. ASR continuously copies disk changes from the West US VM to the East US replica. You configure your RPO to 5 minutes, meaning you can lose at most 5 minutes of transactions if a disaster strikes.

Now, a real disaster occurs. A massive storm knocks out power to the West US data centre. The primary VM goes offline. Your boss calls you, panicked. You:

1. Go to the Azure portal and open the Site Recovery dashboard for your VM.
2. Run a **failover** to the East US region. This starts the replica VM in East US using the most recent replicated data.
3. Update your application's connection string to point to the new database in East US.
4. Verify that the website is working and orders can be processed.

Total downtime: about 10 minutes. Your RTO was met (you had budgeted for 30 minutes). Data loss is minimal — maybe a few transactions that happened in the last 2 minutes before the outage. Your RPO was met.

Three days later, the West US data centre is restored. You then run a **failback**: you reverse the replication direction and failover back to West US, so ShopFast returns to its primary region.

You also need to **test** this plan regularly. Every quarter, you schedule a test failover. You choose an isolated test network in Azure — a network that is separate from your production network — and run the failover there. The test creates a temporary copy of the VM, verifies the application starts, then cleans up. This reveals any configuration changes that might break the failover process. For example, during one test you discover that the application's IP address is hardcoded in a config file — you fix it to use a dynamic DNS name, ensuring the failover will work smoothly next time.

Key actions an IT professional takes:
- Configure backup policies in Azure Backup (retention, frequency, storage redundancy).
- Set up replication in Azure Site Recovery (source and target regions, replication policy).
- Document the failover and failback procedures step-by-step.
- Run quarterly test failovers and address any issues found.
- Monitor backup and replication health using Azure Monitor alerts.
- Review and update the disaster recovery plan as the application changes.

This real-world example shows how disaster recovery is not just a theoretical concept — it is a set of practical, repeatable steps that you must execute and test to protect your business.

## Exam focus

The DP-203 exam tests 'Implement Disaster Recovery and Backup' as part of the broader objective 'Secure, monitor, and optimise data storage and processing'. Expect about 5-10% of your exam questions to touch on this topic. The questions are typically scenario-based: they describe a business requirement and ask you to choose the correct Azure service or configuration.

Here are the specific concepts the exam loves to test:

- **Azure Backup vs Azure Site Recovery**: The exam will present scenarios where you need to decide which service to use. The key distinction: Azure Backup is for scheduled backup and restore of data. Azure Site Recovery is for continuous replication and orchestrated failover of entire workloads (VMs, applications). If the scenario mentions 'RTO in minutes' or 'automated failover', the answer is Azure Site Recovery. If it says 'backup files once a day' or 'long-term retention', the answer is Azure Backup.

- **RTO and RPO definitions**: The exam expects you to know exactly what these acronyms stand for and how they relate to cost. Low RPO (e.g., 5 minutes) costs more because it requires continuous replication. High RTO (e.g., 24 hours) is cheaper but means more downtime. You must be able to match a business requirement to the correct RTO/RPO target.

- **Recovery Services vault**: Many questions assume you know this is the container for both Azure Backup and Azure Site Recovery. If a question asks where to store backup data, the answer is a Recovery Services vault (not a storage account directly).

- **Storage redundancy options**: LRS, GRS, RA-GRS, ZRS. The exam will test which one to use for backup storage. For example: 'You need backup data to survive a regional outage. What redundancy level?' Answer: GRS or RA-GRS. 'You need to read backup data from the secondary region while primary is healthy?' Answer: RA-GRS.

- **Test failover vs actual failover**: The exam expects you to know that test failover uses an isolated network and does not impact production. Actual failover interrupts production. Questions may ask: 'You need to validate your DR plan without affecting your live application. What should you do?' Answer: Run a test failover.

- **Failback**: You must understand that after a disaster is resolved, you typically fail back to the primary region. The exam may ask about the steps or preconditions for failback.

- **Backup retention policies**: The exam tests your understanding of backup frequency and retention. For example: 'You need daily backups kept for 30 days and yearly backups kept for 7 years. What policy?' You need to know you can define multiple backup schedules (e.g., daily, weekly, monthly, yearly) with different retention windows.

- **Encryption and security**: The exam may ask about encrypting backup data at rest and in transit. Azure Backup encrypts data at rest using platform-managed keys or customer-managed keys stored in Azure Key Vault. You should know that backups are encrypted by default.

Common traps:
- **Choosing archive storage for backup**: Archive is too slow for recovery. Backup needs fast restore, so use hot or cool tiers, not archive.
- **Confusing Azure Site Recovery with Azure Backup**: Remember, ASR is for disaster recovery of entire VMs, not just file/folder backup.
- **Assuming LRS is sufficient for disaster recovery**: LRS protects against a single server failure, not a region-wide disaster. The exam will test this distinction.
- **Forgetting about test failovers**: The exam will often ask, 'What should you do to ensure your DR plan works?' The answer always involves testing.

To prepare, practise scenario-based questions on these topics. Know the exact names of the services and features. Memorise the acronyms RTO and RPO and their definitions. Understand when to use GRS vs LRS. This is a high-confidence area for scoring marks.

## Step by step

1. **Identify Critical Systems** — First, you list all the applications and databases your business cannot afford to lose. For example, your customer database, payment system, and website. This step ensures you prioritise resources for the most important workloads.
2. **Define RTO and RPO** — You decide how much downtime (RTO) and data loss (RPO) your business can tolerate. For a payment system, RTO might be 1 hour and RPO 5 minutes. For a reporting database, RTO might be 24 hours and RPO 1 day. These numbers guide your choice of services.
3. **Set Up Azure Backup** — Create a Recovery Services vault in the same region as your primary workload. Configure backup policies (frequency and retention) for each critical system. Enable geo-redundant storage so backups survive region failures. This step protects your data against accidental deletion or corruption.
4. **Enable Azure Site Recovery Replication** — For workloads that require low RTO (minutes to hours), enable replication via Azure Site Recovery. Choose a target region (e.g., pair West US with East US). ASR continuously copies disk changes, keeping the replica ready for failover. This step ensures you can quickly switch to a backup region.
5. **Run a Test Failover** — Before a real disaster, you run a test failover in an isolated network. This verifies that the replica starts correctly, applications connect, and data is consistent. Fix any issues identified. Repeat this test quarterly to keep your DR plan current.
6. **Document the Failover and Failback Procedures** — Write a step-by-step runbook that any team member can follow during a disaster. Include screenshots, connection strings, and contact numbers. Store it in a central location (e.g., a wiki or SharePoint). Without documentation, even a well-designed DR plan can fail under pressure.
7. **Monitor and Maintain** — Set up alerts in Azure Monitor for backup failures, replication health issues, and storage quotas. Update the DR plan whenever your application architecture changes. Regular maintenance ensures the DR plan remains effective as your systems evolve.

## Comparisons

### Azure Backup vs Azure Site Recovery

**Azure Backup:**
- Scheduled data copies (daily, weekly) for restore.
- RPO typically hours to a day.
- Best for long-term retention and accidental deletion recovery.

**Azure Site Recovery:**
- Continuous replication of entire VMs.
- RPO seconds to minutes.
- Best for low-RTO disaster recovery with automated failover.

### Locally Redundant Storage (LRS) vs Geo-Redundant Storage (GRS)

**Locally Redundant Storage (LRS):**
- 3 copies within a single data centre.
- Protects against single server failure only.
- Cheaper than GRS.

**Geo-Redundant Storage (GRS):**
- 3 copies in primary region + 3 in secondary region.
- Protects against a region-wide disaster.
- More expensive due to cross-region replication.

### Test Failover vs Actual Failover

**Test Failover:**
- Runs in an isolated network; no production impact.
- Used for validation and training.
- Does not interrupt live traffic.

**Actual Failover:**
- Switches production traffic to secondary region.
- Used during a real disaster.
- Causes downtime and must be followed by failback.

### RTO (Recovery Time Objective) vs RPO (Recovery Point Objective)

**RTO (Recovery Time Objective):**
- Maximum acceptable downtime after a disaster.
- Measured in hours or minutes.
- Example: 4 hours means system must be up within 4 hours.

**RPO (Recovery Point Objective):**
- Maximum acceptable data loss measured in time.
- Measured in seconds, minutes, or hours.
- Example: 15 minutes means at most 15 min of data is lost.

## Diagram

_This diagram shows how primary and secondary regions connect via replication and backup, with test and actual failover paths._

```mermaid
flowchart TD
    A[Primary Region: West US] -->|Azure Site Recovery Replication| B[Secondary Region: East US]
    A -->|Azure Backup| C[Recovery Services Vault]
    C -->|Geo-Redundant Storage| D[Backup Copy in East US]
    B -->|Test Failover| E[Isolated Test Network]
    B -->|Actual Failover| F[Production in East US]
    F -->|Failback| A
    G[User Traffic] --> A
    G -->|During Disaster| F
```

## Common misconceptions

- **Misconception:** Backup and disaster recovery are the same thing. **Reality:** Backup is making copies of data for restoration. Disaster recovery is a whole process that includes backup, replication, failover, and failback to restore services, not just data. (The terms are used interchangeably in casual conversation, so beginners assume they mean the same. The exam explicitly distinguishes them.)
- **Misconception:** If I back up my data daily, I only lose at most one day of data, which is fine. **Reality:** Daily backup means an RPO of up to 24 hours. For a busy e-commerce site losing one day of transactions could be catastrophic. You need lower RPO using continuous replication via Azure Site Recovery. (Beginners underestimate how much data loss matters in real businesses. The exam tests understanding of RPO targets.)
- **Misconception:** Geo-redundant storage (GRS) means I can instantly access my backup from the secondary region. **Reality:** GRS only replicates data to the secondary region; you cannot read it unless you initiate a failover or use RA-GRS (which allows read access). This is a common exam trap. (The name 'geo-redundant' sounds like you get automatic access, but you don't unless you pay extra for RA-GRS.)
- **Misconception:** Azure Site Recovery replicates data in real-time with zero data loss. **Reality:** ASR provides low RPO but not zero. There is always a small delay (typically seconds to minutes) between writing data on the primary and replicating it to the secondary. Zero data loss is technically possible but very expensive and complex. (Marketing materials sometimes imply 'real-time', leading beginners to think it's instantaneous. The exam tests realistic RPO values.)
- **Misconception:** Once I set up disaster recovery, I never need to touch it again. **Reality:** You must regularly test failovers, update the plan as applications change, and monitor replication health. A DR plan that is not tested is unreliable. (People set up DR and then forget it, assuming it works. The exam emphasises testing and maintenance.)

## Key takeaways

- Azure Backup is for scheduled copies of data (files, databases, VMs) with configurable retention, while Azure Site Recovery provides continuous replication and orchestrated failover of entire VMs to a secondary region.
- Recovery Time Objective (RTO) is the maximum acceptable downtime; Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time.
- For backup storage, use Geo-Redundant Storage (GRS) or Read-Access Geo-Redundant Storage (RA-GRS) to protect against a regional disaster; Locally Redundant Storage (LRS) only protects against single-device failure.
- Always test your disaster recovery plan using test failovers in an isolated network to verify it works without impacting production.
- Failback is the process of returning to your primary region after a disaster is resolved; it requires replicating changes back from the secondary to the primary.
- Backups are encrypted at rest by default in Azure Backup; you can use customer-managed keys for additional control.

## FAQ

**What is the difference between Azure Backup and Azure Site Recovery?**

Azure Backup is for scheduled data backup and restore (like making daily copies of files). Azure Site Recovery is for continuous replication and automatic failover of entire VMs to a secondary region for disaster recovery.

**Do I need both Azure Backup and Azure Site Recovery?**

Not always. If your RTO is hours (not minutes) and you can tolerate losing up to a day of data, Azure Backup alone may suffice. But for critical applications needing low RTO and RPO, you typically need both: Azure Backup for long-term retention and Azure Site Recovery for fast failover.

**What is a Recovery Services vault?**

A Recovery Services vault is a secure container in Azure that stores your backup data and replication settings for Azure Backup and Azure Site Recovery. Think of it as a locked cabinet for your recovery configurations.

**How often should I test my disaster recovery plan?**

You should test your DR plan at least every quarter. More often if your system changes frequently. The exam emphasises testing because untested plans often fail during real disasters.

**What does failback mean?**

Failback is the process of switching back to your primary region after a disaster has been resolved. It involves reversing replication from the secondary region to the primary and then failing over again. This ensures you return to your normal operational setup.

**Can I use Archive storage for backup?**

No. Archive storage is for data you rarely access (e.g., old logs). Restoring from archive can take hours, which violates typical RTO requirements. Use hot or cool storage tiers for backup so you can restore quickly.

## Check your understanding

1. **Which Azure service would you use to replicate an entire virtual machine to another region for low-RTO failover?**

   Answer: Azure Site Recovery (ASR). It provides continuous replication and orchestrated failover for VMs.

2. **What is the difference between LRS and GRS in terms of disaster recovery protection?**

   Answer: LRS protects only against a single server failure within one data centre. GRS protects against a full region outage by replicating data to a secondary region.

3. **When should you use a test failover instead of an actual failover?**

   Answer: Use a test failover to validate your disaster recovery plan without impacting production traffic. It runs in an isolated network.

4. **What does RPO stand for and what does it measure?**

   Answer: RPO stands for Recovery Point Objective. It measures the maximum amount of data, in time, you can afford to lose during a disaster.

5. **Where are Azure Backup and Azure Site Recovery configurations stored?**

   Answer: In a Recovery Services vault, which is a secure container in the Azure portal dedicated to backup and disaster recovery resources.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/dp-203/implement-disaster-recovery-and-backup