Business Continuity And Disaster Recovery In Azure For SQL Database

In an organization or enterprise catering to hundreds of thousands of clients in real-time, working in a rapid environment, a failure in the system for some small duration can be critically hazardous for the entire company no matter how magnanimous the customers. We might not always be able to predict when the next disaster might be but, we can prepare ourselves and our system from these unsolicited disasters. For times like these, Azure has provided services for Enterprise-scale business continuity and disaster recovery. Today, in this article, we’ll learn to dive deep into these features and functionalities in Azure.

Business Continuity

Business Continuity can be defined as the ability of an organization to make sure that the operations and the business functionalities of its core do not get affected by an unexpected event and disaster. The planning for this business continuity is called Business Continuity Planning or also Resiliency Planning.

Recovery Time Objective (RTO)

Recovery Time Objective can be understood as the time duration and level of service within which after the disaster, the business must be continued in order to avoid critical consequences because of the breakage. In layman’s terms, RTO is the time taken to recover from the time of disruption in the service after which if passed, would be unacceptable for the organization since the loss would be hazardous.

Recovery Point Objective (RPO)

Recovery Point Object can be defined as the maximum amount of data an organization could bear to lose in a disaster. It responds to the time before the disasters within the limit up to which, the data recovery point or backup has to be set up.

Estimated Recovery Time (ERT)

It can be explained as the estimated time taken for the database to be operatable after a failover request. The maximum, ERT is Recovery Time Objective.

I.e., Max (ERT) = RTO

There are basically, two purchasing Models in Azure SQL Database. DTU Model and vCore Model.

Database Transaction Unit (DTU)-based Model: This model is based on a bundled measure of Compute, Storage, and I/O resources. The compute sizes are expressed in elastic pools for elastic database transaction units (eDTUs) and in DTUs for single databases. It is great for users who want just want simple, preconfigured resource options.

vCore-based Model

Choosing to compute and store resources independently is allowed by this model. In order to save cost, Azure Hybrid Benefit for SQL Server is enabled by the vCore-based model. It is great for customers who value flexibility, control, and transparency.

Automated Backup

Automated backup can be understood as a backup model in which the system automatically backs up the data with little or almost no human intervention to the backup facility such that it can save the time and complexity that arises with manual backing up. Mostly, its database backups lie in automated backup and it is an important part of the disaster recovery strategy.

Automated Backup Frequency

In the case of SQL Database and SQL Managed Instance, both of them use SQL Server technology in order to create transaction log backups every 5 to 10 minutes, differential backups every 12–24 hours, and full backups every week. The frequency of transaction log backups is based on the compute size and the amount of database activity.

Restore

Azure Backup enables us to restore SQL Server databases. Similar to the point-in-time restore service provided with the Windows OS, Azure Backups support point-in-time restore of existing database and also point-in-time restore of the deleted database. We also have the functionality of Geo-restore where we can restore a database to another geographic region. Furthermore, restore from long-term backup is also available. The Automatic Backup Long Term Retention is possible for up to 10 years which is performed by leveraging automatic backups and is stored in Read-access geo-redundant storage (RA-GRS).

Built-in High Availability and Disaster Recovery

High Availability

High Availability refers to a continuously operational system that is available for an extremely long duration of time.

Disaster Recovery

Disaster Recovery refers to the protocols which enable the system to recover critical infrastructures from disasters. The services of HA and DR in Azure can be classified into two tiers,

Basic, Standard, General Purpose

It behaves like Failover Cluster Instance. Remote storage provides data redundancy within a data center and the backup files are in a different location with geo-redundancy. The failover decisions based on SQL and Service Fabric. The recovery time depends on spare capacity and the connectivity redirection is built-in, in the system.

Premium and Business Critical Tier

This tier is based on Always On Availability Groups. Three secondary replicas are automatically created with four replicas always kept available. The files are backed up in a different location with georedundancy. Here, at least one secondary must sync for commits and the automatic failover is based on SQL and Service Fabric. The recovery time in this tier is extremely fast and the connectivity is redirection built-in with reading scale-out from one of the replicas is available.

Zone Redundancy

To Read the Full Article, Check it out at: https://bit.ly/3gl7ZpE