Azure SQL Database Point in Time Restore

In this final post in our series on Business Continuity I’m going to look at point-in-time restore, a self-service feature available for Basic, Standard, and Premium databases. In previous posts I described the Azure SQL Database business continuity model which includes point-in-time restore. This model is summarized in the table below. Within this model point-in-time restore is designed for recovering a database from a recent backup after accidental data corruption or deletion.

What is Point in Time Restore?

The Azure SQL Database service protects all databases with an automated backup system. These backups are retained for 7 days for Basic, 14 days for Standard and 35 days for Premium. Point-in-time restore is a self-service capability, allowing customers to restore a Basic, Standard or Premium database from these backups to any point within the retention period. Point-in-time restore always creates a new database.

The database backups are taken automatically with no need to opt-in and no additional charges. You only incur additional cost if you use the restore capability. The new database created by restore is charged at normal database rates.

Together, the automated backup system and point-in-time restore provide a zero-cost, zero-admin way to protect databases from accidental corruption or deletion, whatever the cause.

Understanding Automatic Backups

All Basic, Standard, and Premium databases are protected by automatic backups. Full backups are taken every week, differential backups every day, and log backups every 5 minutes. The first full backup is scheduled immediately after a database is created. Normally this completes within 30 minutes but it can take longer. If a database is “born big”, for example if it is created as the result of database copy or restore from a large database, then the first full backup may take longer to complete. After the first full backup all further backups are scheduled automatically and managed silently in the background. Exact timing of full and differential backups is determined by the system to balance overall load.

Backup files are stored locally in the same data center as your databases with local redundancy. When you restore a database, the required backup files are retrieved and applied. The latest weekly and daily backups are also copied to the paired region in the same geo-political area for disaster recovery purpose. These geo-redundant copies are used to enable geo-restore as described in my last post.

Restoring a Live Database to a Point in Time

Using the Azure Management Portal it’s a simple operation to restore a live Basic, Standard, or Premium database to any point in time within its retention period. Either select the database in the list of databases, or open it in the database dashboard, and choose the restore option.

You will be prompted for a new database name and offered a slider control to pick the restore point within the retention period. Alternatively, you can manually enter the date and time to the nearest minute. Once you confirm the action, the database will be restored.

The time taken to restore the database depends on many factors, including the size of the database, the time point selected, and the amount of activity that needs to be replayed to reconstruct the state at the selected point. For a very large and/or active database restore may take several hours.

Restoring a database always creates a new database on the same server as the original database, so the restored database must be given a new name. The database is restored using the service tier that was applicable at the restore point with its default performance level. You need to ensure you have sufficient DTU quota on the server bearing in mind that the restore creates a new database and that the service tier and performance level of the restored database may be different to the current state of the live database. Once complete, the restored database is a normal fully accessible online database charged at normal rates based on its service tier and performance level.

If you are restoring the database for recovery purposes you can treat the restored database as a replacement for the original database, or use it to retrieve data from and then update the original database.

If the restored database is intended as a replacement for the original database you should verify the performance level and/or service tier are appropriate and scale the database if necessary. You can rename the original database and then give the restored database the original name using the ALTER DATABASE command in T-SQL.

If you plan to retrieve data from the restored database you will separately need to write and execute whatever data recovery scripts you need.

Although the restore operation may take a long time to complete the database will be visible in the database list throughout. If you delete the database during the restore it will cancel the operation and you will not be charged.

Restoring a Recently Deleted Database

If you delete a Basic, Standard, or Premium database the final backup is retained for the normal retention period allowing you to restore the database to the point at which it was deleted. To restore a deleted database in the Azure Management Portal you need to open the Deleted Databases tab and locate the appropriate database entry.

Note that if you have reused the same database name multiple times you will need to pay careful attention to the deletion time on each database to ensure you restore the correct one.

As before you need to provide a name for the new database, but in this case the restore point is fixed to the deletion time of the database. And as before, when restoring a deleted database, it can only be restored to the server that contained the original database. Be mindful of this when deleting a server as you will not be able to restore databases previously located on that server once it is deleted.

Backup/Restore vs. Copy/Export/Import

Point-in-time restore is the recommended approach for recovering Basic, Standard, and Premium databases from accidental data loss or corruption. Point-in-time restore removes the need to use the costly workaround based on copy and export/automated export to create backups that is required with Web and Business databases. This improvement alone may justify upgrading to one of the new service tiers. Backup and restore is lower cost (there are no charges for backups unless they are excessive, whereas you are charged for the database copy needed to ensure a transactional consistent export and for storing the BACPAC file), zero admin (backups are automatic, whereas you must manage or schedule exports yourself) and has a better RPO (you can restore to a specific point in time with much finer (one minute) granularity than is practical with copy/export/import) and a better RTO (restore from backups is typically much faster than import, which involves steps to create the schema, disable indexes, load data, and then enable indexes for each table individually).

Note that copy and export continues to be the recommended solution for long term archival beyond the retention period.

Using APIs to Restore Databases

In addition to using the Azure Management Portal you can also restore databases using PowerShell using the Start-AzureSqlDatabaseRestore cmdlet, and the SQL Database management API Create Database Restore Request.

Summary

Automatic backups and self-service point-in-time restore protect your databases from accidental data corruption or deletion. This zero-cost zero-admin solution is available with all Basic, Standard, and Premium databases. Backup and restore provides a significant improvement over the alternative copy/export/import solution for short term recovery needs. We encourage you to use point-in-time restore as part of your business continuity strategy, and only to use export as needed for longer term archival or data migration purposes.