Understanding Business Continuity Features in Azure SQL Databases

In this article we look at business continuity features present in Azure SQL databases ranging from Point in time restore to active geo-replication.

Azure SQL Database is a service provided by Microsoft in the form of cloud database. Azure is a cloud computing platform, which enables organizations to create backups and store their relational data on a large scale on cloud. Azure also helps in scaling the size of business’s database based on their changing storage requirements.

Business Continuity Features in Azure SQL Databases

Azure can help in business continuity by supporting and preserving the database of an organization. It ensures to prevent the database against all damages and disasters by providing backups from its clouds.

SQL Database Features That Promote Business Continuity

SQL Database offers several features for business continuity, like automated backups and the creation optional database replication. Each of these options have different characteristics based on their ERT (estimated recovery time) and also the potential data loss recovery for the recent transactions. Once a user is able to understand these options, he/she can choose amongst them – or like, most scenarios, implement them together to tackle different scenarios. As a user develops his/her business continuity plan, he/she needs to understand the acceptable maximum time required before the application is fully recovered after the disruptive events – this is called the recovery time objective (RTO). The user also needs to understand that the maximum amount or ration of time intervals or recent data updates on the application which can be tolerated to be lost when recovering the data after a disruptive event – this is the users’ RPO (recovery point objective).

Situation criteria in which the user should use the active geo-replication and the auto-failover groups:

  • Depending on how critical the mission is.
  • Has an SLA (service level agreement) which doesn’t follow the downtime of 24 hours or more.
  • Financial liability due to Downtime.
  • When there is a higher chance of data change and it is not acceptable to lose even an hour of data.
  • When potential financial liability and business loss is higher than the price of geo-replication.
  • Preparing for an outage

Regardless of the availability of business continuity feature user must:

  • Identify and prepare a target server, consisting of server-level firewall rules, permissions of master database level and logins.
  • Determining a plan for redirecting clients and their applications in the direction of the new server
  • Document other dependencies, like alerts and auditing settings.
  • If the user does not prepare properly, bringing their applications online after a SQL Server fix can take additional time which would likely also require some troubleshooting which is a bad combination in the time of stress.

Perform a Geo-Restore

If a user is using automated backups along with geo-redundant for storage replication as his/her recovery mechanism, they can initiate database recovery using the geo-restore. It usually takes in about 12 hours for the recovery to initiate – with data loss for around one hour which is determined by the time when the backup will be replicated or created in the last hourly differential. Till the time recovery completes, users will be unable to use any data in the concerned database as it will be unable to record or respond to any transactions or queries. This setting will restore the database to its last available point in time, but restoring the geo-secondary in any point of time is not supported currently by Microsoft Azure.

Author Introduction:

Victor Simon is a data recovery expert in DataNumen, Inc., which is the world leader in data recovery technologies, including access recovery and sql recovery software products. For more information visit www.datanumen.com