The backup domain in AZ-104 may not account for a large portion of the exam, but in real-world work it is treated as extremely important due to the principle that "losing data means losing everything." In this post, we will explore the two core protection tools Azure provides — Azure Backup and Azure Site Recovery — using easy analogies.
---
Why Do We Need Backup and Disaster Recovery?
Imagine this: your laptop, which contains an important report you spent months writing, suddenly breaks down. If you never copied that file somewhere else, all your work is gone. The same is true in cloud environments. Data can be lost for many reasons — server failures, accidental deletions, ransomware attacks, and more.
Azure provides two tools to guard against this.
Azure Backup: Regularly copies important data and stores it in a safe location. It's like keeping a copy of important documents in a safe. Azure Site Recovery: Goes beyond data copying and keeps an entire service ready to keep running from a different region. It's like having a backup office ready to resume operations immediately, even if headquarters burns down.
---
Recovery Services Vault
What Is It?
Recovery Services Vault is a central repository that collects and manages all backup data created by Azure Backup and Azure Site Recovery in one place. Think of it as a bank vault. The vault itself doesn't generate money, but it serves as a secure place to store valuable things.
Key Features
Redundancy Options: You can choose how securely your data is stored.
| Option | Description | Analogy | |--------|-------------|--------| | LRS (Locally Redundant) | 3 copies within the same datacenter | Three safes in the same building | | ZRS (Zone Redundant) | 3 copies across different availability zones in the same region | Three different bank branches in the same city | | GRS (Geo Redundant) | Copies to another region hundreds of km away | A separate safe in a different city |
To protect against disaster-level failures (e.g., a complete datacenter blackout), choosing GRS is the safe option.
Soft Delete: Even if you accidentally delete a backup, it is not actually deleted and is retained for 14 days. Think of it like the recycle bin for email. If you request recovery within 14 days, the data can be restored.
---
Azure Backup
Concept: Creating Periodic Copies
Azure Backup captures the state of data at a specific point in time and stores it in the Recovery Services Vault. It's like the habit of copying important documents every evening and putting them in a safe. If a document gets corrupted or incorrectly modified, you can revert to the version you copied yesterday.
What Can Be Backed Up
Azure Backup can protect a variety of targets.
| Target | Method | Use Case | |--------|--------|----------| | Azure VM | Full VM backup via Recovery Services Vault | Back up an entire web server and restore it if something goes wrong | | Azure Files | Snapshot-based backup | Preserve the state of a shared file storage at a specific point in time | | SQL Server in VM | Full/differential/log backup | Manage granular recovery points for a database | | Azure Blob | Operational backup (continuous protection) | Near-real-time protection for object storage |
Backup Policy: How Often and How Long to Retain?
A backup policy defines "when to back up" and "how long to retain." For example, you could create a policy like this:
Run backup every night at 11 PM Retain daily backups for 30 days Retain Sunday backups for 12 weeks Retain the first-day-of-month backup for 12 months Retain the January 1st backup for 3 years
This allows you to restore not just yesterday's state, but the state from a month ago or even a year ago.
RPO (Recovery Point Objective): Backup frequency is related to RPO. RPO means "how many hours of data loss can you tolerate in the event of a failure?" If you back up only once a day, up to 24 hours of data can be lost. If you can tolerate no more than 1 hour of data loss, you need to back up every hour.
VM Backup and Restore
How to Configure Backup: Open the Recovery Services Vault in the Azure portal and enable backup. Select a backup policy (define frequency and retention period). After that, snapshots are automatically created according to the policy and stored in the Vault.
Restore Options: When a problem occurs, you can recover in three ways depending on the situation.
Create New VM: Create a completely new VM from the backup. Useful when the original server is completely broken. Like moving to a new house. Restore Disk: Restore only the disk and attach it to an existing VM. Like keeping the house as is and only replacing the furniture. File Recovery: Select and restore only specific files. Like taking just one important document out of a safe. Useful when you only need to recover a single accidentally deleted file, without restoring the entire VM.
---
Azure Site Recovery (ASR)
Concept: Always Ready to Run from an Alternate Location
Azure Site Recovery goes beyond simple backup — it is a disaster recovery service that replicates VMs to another region in near real-time. It's like having a backup office in Busan ready to immediately take over operations if the Seoul headquarters becomes unavailable due to a sudden disaster.
If Azure Backup is the tool for "not losing data," Azure Site Recovery is the tool for "not stopping the service." Be sure to remember this distinction.
Core Concepts
Replication Policy: Defines how frequently the state of the source VM is copied to the secondary region, and how many recovery points to retain.
Failover: When a failure occurs in the primary region (e.g., Korea Central), a replicated VM in the secondary region (e.g., Korea South) is started to continue service. Like having calls automatically routed to a branch office number when the headquarters phone line goes down.
Failback: After the primary region is restored, this is the process of moving the service that was running in the secondary region back to the primary region. Like returning from the branch office to headquarters after construction is complete.
Test Failover: You can rehearse the DR plan without affecting the actual production environment. Like a fire drill to verify that real emergency exits work. Since attempting a failover for the first time during an actual disaster is very risky, periodic testing is important.
RPO vs RTO — Two Key Metrics
When creating a disaster recovery plan, you must always consider these two metrics.
RPO (Recovery Point Objective) "How much data loss (in hours) can you tolerate when a failure occurs?"
For example, if the RPO is 1 hour, data created within the last hour must be guaranteed to be recoverable. The shorter the RPO, the more frequently you need to replicate.
RTO (Recovery Time Objective) "How long (in hours) can the service be down after a failure before it must be restored?"
For example, if the RTO is 4 hours, the service must resume within 4 hours of a failure. The shorter the RTO, the more infrastructure you need to enable a fast switchover (e.g., VMs always on standby).
For services like financial platforms where data loss and downtime are critical, RPO and RTO must be set very short. For lower-priority cases like internal development servers, they can be set more loosely.
!RPO versus RTO
Backup Vault vs Recovery Services Vault — Which Should You Use?
Having two types of Vaults can be confusing. Here is a simple way to tell them apart.
| Item | Recovery Services Vault | Backup Vault | |------|------------------------|-------------| | Protected Targets | Azure VM, SQL Server, Azure Files, MARS agent | Azure Blob, Azure Disk, PostgreSQL | | Primary Use | Traditional workload backup and disaster recovery | Latest cloud-native workload backup | | Release | Existing (older) service | Relatively newer service |
For exam questions, if the scenario says "back up or replicate a VM," think Recovery Services Vault. If it says "back up Blob storage or managed disks," think Backup Vault.
!Recovery Services Vault versus Backup Vault
Exam Key Points Summary
Let's connect what we've learned to real exam question scenarios.