Azure SQL Database Geo-Restore

This post continues our series on the Business Continuity/Disaster Recovery (BCDR) capabilities of Azure SQL Database and will discuss the geo-restore feature.

Geo-restore in detail

In the previous post on standard geo-replication we already discussed how the various business continuity features map to the service tiers but as a quick refresher, below is the list of the features and their key recovery characteristics.

Geo-restore is automatically enabled for all service tiers with no extra cost. It’s built using the same technology as the point in time restore with one important difference. It restores the database from a copy of the backup in the geo-replicated blob storage (RA-GRS). For each active database, the service maintains a backup chain that includes a weekly full backup, a daily differential backup, and transaction logs saved every 5 minutes. Of these, the full and the differential backups are also copied to the blob storage. As the blobs are geo-replicated it guarantees that the the daily backups are available even after a massive failure in the primary region. Figure 1 illustrates this process.

Figure 1.  Geo-replication of the daily backups copied to the storage container(s).

If a large scale incident in a region results in unavailability of your database application you can use geo-restore to create a database in any other region. Figure 2 illustrates the recovery process.

Figure 2.  Restore of the database from the last daily backups in the storage container(s).

Factors affecting recovery time

During the recovery you can select the backup of every database you had in the failed region. Each backup is the last daily backup saved for the respective database to the geo-redundant storage (GRS).  While GRS replicates blobs with this a geographic region you can create a restored database in any logical server. In other words, you can restore the database lost in an incident in any region where you can use it. Because geo-restore uses the daily backups, the data loss (RPO) can be up to 24 hrs. If you use the management portal the time of the last backup is displayed as shown on Figure 3.

The size of the database is the main factor affecting the recovery time. The recovery consists of the full restore followed by applying the differential backup. Another factor is available capacity in the region you selected. You can select the region by choosing a target server. After a regional failure you should expect high volume of the geo-restore requests due to the large number of the impacted applications. The service will limit the resources used by the restore operations to ensure that the existing workloads in that region are not impacted. As a result some of the geo-restore requests will be queued, which will increase the recovery time for your databases.

Realistically, only Basic databases should rely on geo-restore as their default recovery method. Given that the maximum size of the Basic databases cannot exceed 2GB and the update rates are quite limited by its performance level, the target 24hr RPO/RTO should be adequate. But if you want to guarantee that all databases can be recovered in the same region with a shorter RTO you should consider upgrading your applications to a higher service tier and use Standard or Active Geo-replication as your disaster recovery solution.

Just like with geo-replication, to manage geo-restore you have a choice between calling REST API, PowerShell or using Azure Management Portal. At the time of this writing both PITR and Geo-restore are initiated in the context of the database as different flavors of restore. This is because both are available under normal circumstances. Geo-restore allows you to choose a target server but does not allow setting the restore point. Point in time restore on the other hand allows you to set a restore point but will only create the restored database in the same server as the original. Figure 3 shows how these options look in Portal.

Figure 3.  Use the Azure Management portal to submit the geo-restore request

Obviously this won’t work during the real failures as the source server will likely not be accessible. We will address this scenario in the next portal update. For now, you have to use REST or PowerShell API to restore a database after a regional failure by specifying the impacted server as a parameter of the call. You can read about the geo-restore REST APII here.

If you initiated a restore operation by mistake and would like to cancel it you can do it by connecting to the target master database and dropping the restored database. Note, the database record for it is created in the master as soon as the restore process starts. So you can drop it without waiting for the restore complete. That way you can avoid any billing impact.

Summary

The combination of Geo-restore, Standard Geo-replication and Active Geo-replication provide you with a range of options to implement a business continuity solution that meets the needs of your application. In addition to the cost and SLO differences we discussed earlier the option you choose will also define what business continuity scenarios are enabled. The following table summarizes these differences:

We encourage you try geo-restore as soon as possible. You will need to sign-up for the preview of the new service tiers. We’re listening closely to feedback so please tell us what you think. You can read more about Geo-Restore in this article.