Quick Note — Recommend a Backup and Recovery Solution for Databases
AZ-305 › Unit 3 › Design solutions for backup and disaster recovery › Recommend a backup and recovery solution for databases
Quick Note — Recommend a Backup and Recovery Solution for Databases
Database backup is the last line of defense for stateful workloads in Azure. When a developer drops the wrong table, a ransomware payload encrypts a production database, or a regional outage takes a primary down, the speed and granularity of your recovery determine whether the business loses minutes, days, or its reputation. This lesson teaches you to recommend the right backup and recovery solution across the database services you will see on AZ-305: Azure SQL Database, Azure SQL Managed Instance, Azure Cosmos DB, Azure Database for PostgreSQL Flexible Server, SQL Server on Azure VMs, and SAP HANA on Azure.
Retrieval target
- Recommend a Backup and Recovery Solution for Databases
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Point-in-Time Restore (PITR) — Azure SQL | Built-in automatic backup for Azure SQL Database and Azure SQL MI: full weekly, differential every 12–24 h, transaction log every 5–10 min. Default retention 7 days, configurable up to 35 days. Restore to any point in the window creates a new database; no extra storage cost for backups within the retention window. |
Long-Term Retention (LTR) — Azure SQL | Extended retention beyond PITR's 35-day cap. Configurable policy: keep the weekly / monthly / yearly full backups in RA-GRS blob storage for up to 10 years. Restoring an LTR backup creates a new database from that snapshot — slower than PITR (download from blob), used for audit, compliance, and legal holds, not for routine recovery. |
Geo-Restore (Azure SQL) | A built-in DR feature that lets you restore a database from the most recent geo-replicated backup into any other Azure region. RPO ~1 h (geo-replication lag) and RTO ~12 h (varies by DB size). Always available, even after the source region is unrecoverable. Different from active geo-replication / failover groups — Geo-Restore restores from backup; the others maintain a live replica. |
BACPAC export | A logical, schema + data export of a SQL DB into a single .bacpac file stored on Azure Blob. Not a backup in the recovery sense — captures one point in time, no transaction-log fidelity. Useful for migrations, dev/test seeding, archival snapshots. Restoring imports the schema and bulk-loads data into a fresh DB. Use only when a full PITR/LTR backup chain isn't appropriate. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.