Merge pull request #32931 from WilliamDAssafMSFT/20250123-azure-sql-db-rpo-rto

20250123 RTO RPO

Author: JamesJBarnett

azure-sql/database/automated-backups-overview.md

@@ -5,7 +5,7 @@ description: Learn how Azure SQL Database automatically backs up all databases a
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: mathoma, danil, dinethi
-ms.date: 01/13/2025
+ms.date: 02/03/2025
 ms.service: azure-sql-database
 ms.subservice: backup-restore
 ms.topic: conceptual
@@ -138,11 +138,11 @@ Automatic backups on secondary replicas:
 
 This table summarizes the capabilities and features of [point-in-time restore (PITR)](recovery-using-backups.md#point-in-time-restore), [geo-restore](recovery-using-backups.md#geo-restore), and [long-term retention](long-term-retention-overview.md).
 
+For information on recovery times, see [RTO and RPO](business-continuity-high-availability-disaster-recover-hadr-overview.md?view=azuresql-db&preserve-view=true#rto-and-rpo).
+
 | Backup property | PITR | Geo-restore | LTR |
 |---|---|---|---|
 | **Types of SQL backup** | Full, differential, log. | Most recent geo-replicated copies of PITR backups. | Only the full backups. |
-| **Recovery point objective (RPO)** | 10 minutes, based on compute size and amount of database activity. | Up to 1 hour, based on geo-replication. <sup>1</sup> | One week (or user's policy).|
-| **Recovery time objective (RTO)** | Restore usually takes less than 12 hours but could take longer, depending on size and activity. See [Recovery](recovery-using-backups.md#recovery-time). | Restore usually takes less than 12 hours but could take longer, depending on size and activity. See [Recovery](recovery-using-backups.md#recovery-time). | Restore usually takes less than 12 hours but could take longer, depending on size and activity. See [Recovery](recovery-using-backups.md#recovery-time). |
 | **Retention** | 7 days by default, configurable between 1 and 35 days (except Basic databases, which are configurable between 1 and 7 days). | Enabled by default, same as source.<sup>2</sup>| Not enabled by default. Retention is up to 10 years. |
 | **Azure Storage**  | Geo-redundant by default. You can optionally configure zone-redundant or locally redundant storage. | Available when PITR backup storage redundancy is set to geo-redundant. Not available when PITR backup storage is zone-redundant or locally redundant. | Geo-redundant by default. You can configure zone-redundant or locally redundant storage. |
 | **Configure backups as [immutable](/azure/storage/blobs/immutable-storage-overview)** | Not supported | Not supported | Not supported | 

azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview.md

@@ -5,7 +5,7 @@ description: Learn how Azure SQL Database supports cloud business continuity and
 author: rajeshsetlem
 ms.author: rsetlem
 ms.reviewer: wiassaf, mathoma
-ms.date: 01/05/2024
+ms.date: 02/03/2025
 ms.service: azure-sql-database
 ms.subservice: high-availability
 ms.topic: conceptual
@@ -80,7 +80,6 @@ From a database perspective, there are four major potential disruption scenarios
 | Rare datacenter or availability zone outage, possibly caused by a natural disaster event, configuration change, software bug or hardware component failure. | To mitigate datacenter or availability zone level outage, enable [zone redundancy](high-availability-sla-local-zone-redundancy.md#zone-redundant-availability) for the database or elastic pool to use [Azure Availability Zones](/azure/reliability/availability-zones-overview) and provide redundancy across multiple physical zones within an Azure region. Enabling zone redundancy ensures the database or elastic pool is resilient to zonal failures with up to 99.995% high availability SLA. |
 | Rare _regional outage_ impacting all availability zones and the datacenters comprising it, possibly caused by catastrophic natural disaster event. | To mitigate a region-wide outage, enable disaster recovery using one of the options: </br> - Continuous data synchronization options like [failover groups (recommended)](failover-group-sql-db.md) or [active geo-replication](active-geo-replication-overview.md) that allow you to create replicas in a secondary region for failover. </br> - Setting backup storage redundancy to geo-redundant backup storage to use [geo-restore](recovery-using-backups.md#geo-restore).  | 
 
-
 ## RTO and RPO
 
 As you develop your business continuity plan, understand the maximum acceptable time before the application fully recovers after the disruptive event. The time required for an application to fully recover is known as the Recovery Time Objective (RTO). Also understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering from an unplanned disruptive event. The potential data loss is known as Recovery Point Objective (RPO).
@@ -91,8 +90,7 @@ The following table compares RPO and RTO of each business continuity option:
 | --- | --- | --- |
 | High Availability </br>(Using zone redundancy) | Typically less than 30 seconds | 0 |
 | Disaster Recovery </br>(Using failover groups with [customer managed failover policy](failover-group-sql-db.md#failover-policy) or active geo-replication ) | Typically less than 60 seconds | Equal to or greater than 0 </br> (Depends on data changes before the disruptive event that haven't been replicated) |
-| Disaster Recovery </br>(Using geo-restore) | Typically minutes or hours | Typically minutes or hours |
-
+| Disaster Recovery </br>(Using geo-restore) | Typically minutes or hours, dependent on Azure storage replication | Typically minutes or hours, dependent on size of database backup |
 
 ## Business continuity checklists
 
@@ -107,7 +105,7 @@ Regardless of which business continuity features you use, you must prepare the s
 
 ## Restore a database within the same Azure region
 
-You can use automatic database backups to restore a database to a point in time in the past. This way you can recover from data corruptions caused by human errors. Point-in-time restore (PITR) allows you to create a new database on the same server that represents the state of data prior to the corrupting event. For most databases, restore operations take less than 12 hours. It can take longer to recover a very large or very active database. For more information, see [database recovery time](recovery-using-backups.md#recovery-time).
+You can use automatic database backups to restore a database to a point in time in the past. This way you can recover from data corruptions caused by human errors. Point-in-time restore (PITR) allows you to create a new database on the same server that represents the state of data prior to the corrupting event. For recovery times, see [RTO and RPO](#rto-and-rpo).
 
 If the maximum supported backup retention period for point-in-time restore isn't sufficient for your application, you can extend it by configuring a long-term retention (LTR) policy for the database(s). For more information, see [Long-term backup retention](long-term-retention-overview.md).
 

azure-sql/database/disaster-recovery-drills.md

@@ -4,10 +4,10 @@ description: Learn guidance and best practices for using Azure SQL Database to p
 author: AbdullahMSFT
 ms.author: amamun
 ms.reviewer: wiassaf, mathoma
-ms.date: 12/18/2018
+ms.date: 02/03/2025
 ms.service: azure-sql-database
 ms.subservice: high-availability
-ms.topic: conceptual
+ms.topic: how-to
 ---
 # Performing disaster recovery drills - Azure SQL Database
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
@@ -28,7 +28,7 @@ Depending on how you [designed your application for business continuity](busines
 
 ## Geo-restore
 
-To prevent the potential data loss when conducting a disaster recovery drill, perform the drill using a test environment by creating a copy of the production environment and using it to verify the application's failover workflow.
+To prevent the potential data loss when conducting a disaster recovery drill, perform the drill using a test environment by creating a copy of the production environment and using it to verify the application's failover workflow. For more information, see [Geo-restore for Azure SQL Database](recovery-using-backups.md#geo-restore).
 
 ### Outage simulation
 
@@ -61,12 +61,13 @@ To simulate the outage, you can disable the web application or virtual machine c
 
 Complete the drill by verifying the application integrity post recovery (including connectivity, basic functionality testing, or other validations required for the drill signoffs).
 
-## Related content
+## Planning for an outage
+
+- To learn about faster recovery options, see [Active geo-replication](active-geo-replication-overview.md) and [Failover groups](failover-group-sql-db.md).
+- Review [disaster recovery guidance](disaster-recovery-guidance.md) and the [high availability and disaster recovery checklist](high-availability-disaster-recovery-checklist.md). 
 
-To learn more, review: 
+## Related content
 
-* [Continuity scenarios](business-continuity-high-availability-disaster-recover-hadr-overview.md).
-* [Automated backups](automated-backups-overview.md)
-* [Restore a database from the service-initiated backups](recovery-using-backups.md).
-* To learn about faster recovery options, see [Active geo-replication](active-geo-replication-overview.md) and [Failover groups](failover-group-sql-db.md).
-* Review [disaster recovery guidance](disaster-recovery-guidance.md) and the [high availability and disaster recovery checklist](high-availability-disaster-recovery-checklist.md). 
+- [Continuity scenarios](business-continuity-high-availability-disaster-recover-hadr-overview.md)
+- [Automated backups](automated-backups-overview.md)
+- [Geo-restore for Azure SQL Database](recovery-using-backups.md#geo-restore)