Geo-restore Azure SQL Database

This article explains how to use geo-restore to recover your Azure SQL database to another Azure region.

What is Geo-restore? Geo-restore is a disaster recovery (DR) strategy that uses automated backups stored in a geo-redundant storage (GRS) account. It allows you to restore your database to any Azure region, independent of where your database is located. This is crucial for business continuity in case of a regional outage.

When to use Geo-restore

  • Disaster Recovery (DR): When your primary Azure region becomes unavailable due to a major disaster or outage, geo-restore provides a way to bring your database back online in a different, healthy region.
  • Regional Failover: You can proactively initiate a geo-restore to a secondary region to test your DR plan or to failover your application to a different region.

How Geo-restore works

Azure SQL Database automatically creates backups of your databases. By default, these backups are stored in locally redundant storage (LRS) within the same region. However, you can configure your database to use geo-redundant storage (GRS). With GRS, your backups are replicated to a secondary region, making them available for geo-restore.

When you initiate a geo-restore, Azure SQL Database copies the most recent geo-redundant backup from the secondary region to the primary region (or any other region you specify) and then restores it as a new database. This process can take some time depending on the database size and network latency.

Steps to perform a Geo-restore

Prerequisites:

  • Your Azure SQL database must have geo-redundant backup storage enabled.
  • You need appropriate permissions to create a new SQL database in the target region.

Using the Azure Portal:

  1. Navigate to your SQL database resource in the Azure portal.
  2. In the left-hand menu, under "Data management," select Backups.
  3. Select the Restore tab.
  4. Choose the Restore from an earlier backup option.
  5. Under the Region dropdown, select the desired target region for your restored database.
  6. Select a Restore point (date and time).
  7. Provide a New database name for the restored database.
  8. Configure other settings such as compute + storage and server.
  9. Click Review + create, and then Create.

Using Azure CLI:

You can use the following Azure CLI command to perform a geo-restore:


az sql db restore --dest-name <new-database-name> --resource-group <resource-group-name> --server <server-name> --name <original-database-name> --region <target-region> --time <restore-point-in-utc>

Replace the placeholders with your specific values:

  • <new-database-name>: The name for your restored database.
  • <resource-group-name>: The resource group containing your original server.
  • <server-name>: The name of the logical server where the database will be restored.
  • <original-database-name>: The name of the database you want to restore.
  • <target-region>: The Azure region where you want to restore the database (e.g., "East US", "West Europe").
  • <restore-point-in-utc>: The date and time (in UTC) up to which you want to restore. Format: YYYY-MM-DDTHH:MM:SSZ

Using Azure PowerShell:

You can use the following Azure PowerShell command:


Restore-AzSqlDatabase -From `
    -ResourceId <original-database-resource-id> `
    -DeletionDate <restore-point-in-utc> `
    -ResourceGroupName <resource-group-name> `
    -ServerName <server-name> `
    -TargetDatabaseName <new-database-name> `
    -Edition <target-edition> `
    -ServiceObjectiveName <target-service-objective> `
    -Region <target-region>

Note: The exact parameters might vary slightly based on your PowerShell version and specific restore scenario. Refer to the official Azure PowerShell documentation for the most up-to-date syntax.

Considerations for Geo-restore

  • Cost: Geo-redundant storage incurs additional costs compared to locally redundant storage.
  • RPO/RTO: Geo-restore relies on geo-replicated backups. The Recovery Point Objective (RPO) is determined by the replication latency, and the Recovery Time Objective (RTO) includes the time to copy data and provision the new database.
  • Firewall Rules: After restoring to a new region, you will need to configure firewall rules for the new server to allow access from your applications and users.
  • Application Dependencies: Ensure that all application dependencies (e.g., connection strings, DNS records) are updated to point to the newly restored database in the secondary region.
Testing your DR plan Regularly test your geo-restore process to ensure it functions as expected and to validate your RTO and RPO.

Next Steps

↑