Share via

Disaster Recovery for Azure DB

Vignesh RS 0 Reputation points
2025-08-25T09:43:04.3566667+00:00

Hi Everyone,

 

I would like to get some clarifications regarding Disaster Recovery (DR) and operational failure scenarios for our Hyperscale database.

 

Database details:

  • Size: ~110 GB
  • vCore: 4
  • Compute tier: Provisioned
  • Hardware type: Gen-5
  • Region: East US
  • Current storage: Zone redundant

I have the following questions:

  1. Migration from Zone Redundant to Geo-Redundant Hyperscale:
    Since Azure does not support direct conversion from Zone redundant to Geo redundant, we will need to create a new Hyperscale DB with Geo redundancy and migrate data from the existing Zone redundant DB. Could you all please help us getting clarification on the following:
    • How long would this migration typically take for a ~110 GB database?
    • What options/tools are available for this migration, and what is the recommended approach?
  2. Backup availability during Azure outages:
    In the event of an Azure-side issue such as a server outage or downtime:
    • How long does it usually take for backups of a Hyperscale DB to become available?
    • In what format will the backup be provided (e.g., .bak file or another format)?
    • How would we restore that backup in a different region if required?
  3. Point-in-Time Restore (PITR) precision:
    If there is accidental data deletion or an operational error (for example, a wrong query executed at 10:50 AM), can we use PITR to restore the database to 10:49 AM? In other words:
    • Is PITR precise enough to select a restore point up to the minute?
    • Would this restore include all data committed up to 10:49 AM and exclude the erroneous changes at 10:50 AM?
    1. Restore time for large Hyperscale DBs:
      For a Hyperscale database of around 110 GB:
      • Approximately how long would it take to restore using PITR?
        • Approximately how long would a geo-restore operation take?

Your guidance on these questions will help us plan our DR strategy effectively.

 

Thank you for your support.

 

Azure SQL Database
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Amira Bedhiafi 36,716 Reputation points Volunteer Moderator
    2025-08-25T11:43:46.34+00:00

    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.

    0 comments
  2. Marcin Policht 54,995 Reputation points MVP Volunteer Moderator
    2025-08-25T11:46:59.81+00:00
    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.

    1. 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.

    1. 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.

    1. 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

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.