Disaster Recovery for Azure DB

Thank you for reaching to Microsoft QA -  

Migration from Zone Redundant to Geo-Redundant Hyperscale: 

For a database of approximately 110 GB, the migration duration typically depends on the method used and network conditions. Based on Azure documentation and community experience 

Estimated Time: Between 30 minutes to 2 hours  

Database Copy or Geo-restore operations in Hyperscale are snapshot-based and generally complete within an hour. 

Network latency and region pairing (e.g., East US to paired region) may influence duration. 

Migration Options & Recommended Approach -  

Since Azure does not support direct conversion from Zone Redundant to Geo-Redundant for Hyperscale, you must create a new Hyperscale DB with geo-redundancy and migrate data. Here are the supported and recommended methods: 

Database Copy 

Use Azure PowerShell or CLI to create a new Hyperscale DB with -ZoneRedundant and -BackupStorageRedundancy Geo parameters. 

Recommended for same-region migrations. 

Example PowerShell command: 

New-AzSqlDatabaseCopy -ResourceGroupName "RG" -ServerName "SourceServer" -DatabaseName "SourceDB" -TargetServerName "TargetServer" -TargetDatabaseName "GeoRedundantDB" -ZoneRedundant -BackupStorageRedundancy Geo 

Geo-Replica Creation 

Create a geo-replica of the existing DB in a paired region with geo-redundant backup. 

Ensures minimal downtime and high availability. 

Requires at least one high availability replica. 

Point-in-Time Restore (PITR) 

Restore the database to a new Hyperscale instance in the target region using PITR. 

Useful for precise recovery scenarios (e.g., rollback to a specific minute). 

Backup Availability During Azure Outages 

Speed of Availability 

Backups in Hyperscale are snapshot-based, meaning they are virtually instantaneous and do not depend on the size of the database. Even for large databases (e.g., 110 GB or multi-terabyte), restore operations within the same region typically complete within minutes, not hours. 

 

Impact of Region or Redundancy Changes  If restoring to a different region or changing the storage redundancy (e.g., from zone to geo-redundant), the restore becomes a size-of-data operation, and time increases proportionally with database size. 

3. Point-in-Time Restore (PITR) precision: 

      a. Point-in-Time Restore (PITR) in Azure SQL Database—including the             Hyperscale tier—is precise enough to restore to a specific minute. 

      b. select a restore point such as 10:49 AM, and Azure will restore the database             to include all committed transactions up to that exact time. Any changes             made at or after 10:50 AM—including erroneous updates—will be excluded             from the restored database. 

           How It Works 

         PITR uses transaction log backups and snapshot-based storage to 

Create a geo-replica of the existing DB in a paired region with geo-redundant backup. 

Ensures minimal downtime and high availability. 

Requires at least one high availability replica. 

Point-in-Time Restore (PITR) 

Restore the database to a new Hyperscale instance in the target region using PITR. 

Useful for precise recovery scenarios (e.g., rollback to a specific minute). 

Backup Availability During Azure Outages 

Speed of Availability 

Backups in Hyperscale are snapshot-based, meaning they are virtually instantaneous and do not depend on the size of the database. Even for large databases (e.g., 110 GB or multi-terabyte), restore operations within the same region typically complete within minutes, not hours. 

 

Impact of Region or Redundancy Changes If restoring to a different region or changing the storage redundancy (e.g., from zone to geo-redundant), the restore becomes a size-of-data operation, and time increases proportionally with database size. 

3. Point-in-Time Restore (PITR) precision: 

      a. Point-in-Time Restore (PITR) in Azure SQL Database—including the             Hyperscale tier—is precise enough to restore to a specific minute. 

      b. select a restore point such as 10:49 AM, and Azure will restore the database             to include all committed transactions up to that exact time. Any changes             made at or after 10:50 AM—including erroneous updates—will be excluded             from the restored database. 

           How It Works 

         PITR uses transaction log backups and snapshot-based storage to reconstruct the database state. 

You specify the exact timestamp during the restore process in the Azure portal, CLI, or PowerShell. 

The restored database will reflect the state as it was at the selected time, ensuring rollback to a clean state before the error occurred. 

 

Restore time for large Hyperscale DBs: 

Point-in-Time Restore (PITR) 

Estimated Duration: Typically under 30 minutes, even for databases over 100 GB. 

Why: PITR in Hyperscale uses snapshot-based backups and log replay, which are optimized for fast recovery. The restore time is largely independent of database size due to the architecture of Hyperscale. 

Geo-Restore 

Estimated Duration: Generally 30 minutes to 2 hours, depending on:  

Region pairing (e.g., East US to its paired region) 

Network latency 

Replication lag 

Why: Geo-restore involves restoring from a geo-replicated backup, which may take longer due to cross-region data transfer and snapshot availability. reconstruct the database state. 

You specify the exact timestamp during the restore process in the Azure portal, CLI, or PowerShell. 

• The restored database will reflect the state as it was at the selected time, ensuring rollback to a clean state before the error occurred. 

 

1. Restore time for large Hyperscale DBs: 

Point-in-Time Restore (PITR) 

Estimated Duration: Typically under 30 minutes, even for databases over 100 GB. 

Why: PITR in Hyperscale uses snapshot-based backups and log replay, which are optimized for fast recovery. The restore time is largely independent of database size due to the architecture of Hyperscale. 

1. Geo-Restore 

Estimated Duration: Generally 30 minutes to 2 hours, depending on:  

Region pairing (e.g., East US to its paired region) 

Network latency 

Replication lag 

Why: Geo-restore involves restoring from a geo-replicated backup, which may take longer due to cross-region data transfer and snapshot availability. 

1. Migration from Zone-Redundant to Geo-Redundant Hyperscale

AFAIK, Azure does not support in-place conversion from Zone-Redundant to Geo-Redundant storage once the database is created. You need to create a new Hyperscale database with geo-redundant backups and migrate your data.

To implement active Geo-Replication (geo-secondary), create an asynchronous secondary in another region, then fail over. This minimizes downtime and keeps near-real-time data sync. To perform a database copy, use CREATE DATABASE ... AS COPY OF ... to copy to a new geo-redundant Hyperscale database. Restore backups into a new GRS-enabled Hyperscale instance in another region. Data movement tools (like BACPAC export/import, Azure Data Factory, SSIS) are viable but slower and more manual.

So the recommendation would be to use Active Geo-Replication, since it offers continuous replication, minimal downtime, and facilitates controlled failover.

Regarding an estimated Time for ~110 GB Database, Hyperscale allows fast copy/restore operations within the same region, even for multi-terabyte databases—often taking only minutes. When changing redundancy or moving across regions, operations become size-of-data, so expected duration is proportional to data volume. For ~110 GB, you can reasonably expect the migration (initial copy or seeding geo-replica) to complete within tens of minutes to a few hours, depending on network throughput and IOPS.

2. Backup availability during Azure outages

Hyperscale uses storage snapshots and begins protection immediately upon creation, even with large data volumes—no delay for initial backup creation. These backups are automated, continuous, and managed by Azure—they’re not .bak files and can't be downloaded directly. To extract data externally, you'd use BACPAC exports or data movement technologies—not backup restore.

If using Geo-Redundant Storage or Geo Zone-Redundant for backups, the service supports Geo-Restore to a different region in case of primary region failure. This restores the latest transactionally consistent copy, typically with minimal data loss, depending on GRS replication lag.

3. Point-in-Time Restore (PITR) precision

Hyperscale does support PITR, with RPO of 0 minutes and typical restores completing within 60 minutes, though larger or high-activity databases may take longer. PITR is precise to the minute (e.g., 10:49 AM) and will include all committed transactions up to that point, excluding later ones—yes, you can avoid changes made at 10:50 AM.

4. Restore times for ~110 GB Hyperscale

Within the same region (PITR), Hyperscale restores are very fast, often finishing in minutes even for multi-terabyte databases. For 110 GB, expect a few to tens of minutes, depending on workload. For Geo-Restore (cross-region, with redundancy change), it's a size-of-data operation—duration depends largely on the largest files and network speed. Using region-pairing can shorten time. With 110 GB, estimate under an hour, but could stretch to a few hours depending on throughput.

So, to summarize:

1. Migration:
   • Use Active Geo-Replication to establish a geo-redundant secondary in target region. Then fail over when ready.
   • This minimizes downtime and maintains near-real-time data sync.
2. Backup strategy:
   • Enable Geo-Redundant Storage (GRS or GZRS) for backups if you require cross-region recovery.
   • Understand that Azure manages backups internally—no downloadable .bak files.
3. Error recovery:
   • Use PITR, selecting a minute-level timestamp (e.g., 10:49 AM) to avoid unwanted changes and recover just before an incident.
4. Restoration expectations:
   • PITR in-region restores are very fast.
   • Cross-region restores and migrations may take longer but typically remain within acceptable timeframes for your size.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Hello Vignesh !

Thank you for posting on Microsoft Learn.

For migrating from Zone-redundant to Geo-redundant (backup storage), you can’t flip this in-place for Hyperscale. You must create a new DB with the desired backup storage redundancy (Geo/GZRS) and move to it.

https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-change-settings?view=azuresql

A recommended approach is to create a secondary (can be in the same region for migrations) with Geo backup redundancy, let it synchronize, then do a planned failover and point your app to the new primary. This is supported for Hyperscale. https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview?view=azuresql

Or you can use a database copy to a new DB created with Geo backup redundancy.

In-region Hyperscale copy is fast when redundancy matches, but because you’re changing redundancy (ZRS to GRS) the copy becomes a size-of-data operation (still parallelized). https://learn.microsoft.com/en-us/azure/azure-sql/database/database-copy?view=azuresql

With AGR, initial seeding + catch-up depends on throughput and write rate and with size-of-data copy, time depends mostly on the largest page-server file and available bandwidth. For Hyperscale, these operations are parallelized expect minutes to a few hours in typical cases run one test copy to measure in your environment.

Regarding backups during an Azure outage, Azure manages backups but you don’t get a .bak. You restore from Azure-managed snapshots/logs. https://learn.microsoft.com/en-us/azure/azure-sql/database/recovery-using-backups?view=azuresql

If you want to restore in another region, you can use Geo-restore (Portal/CLI/PS) to any server in any region from the most recent geo-replicated backup even if the primary region is down.

Geo-restore RPO is minutes to 1 hour because replication to the secondary region is asynchronous so RTO is minutes to hours depending on size/load. If you need much lower RPO/RTO, use failover groups/active geo-replication instead of relying on geo-restore.

https://learn.microsoft.com/en-us/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview?view=azuresql

For the PITR precision and regarding your question "can I restore to 10:49 (to avoid a 10:50 mistake)?"

Yes, hyperscale supports PITR to a specific timestamp within retention and backups are essentially continuous (storage snapshots + log). RPO for PITR is 0 minutes, and most PITR completes within 60 minutes regardless of DB size. (Time selection is in UTC in the portal/API)

https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tier-hyperscale-frequently-asked-questions-faq?view=azuresql

The restored DB is transactionally consistent at that timestamp, it includes all committed data up to 10:49 and excludes changes that occurred at/after 10:50.