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 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.
If you want to learn more about Azure SQL Database and the services provided for Business Continuity and Disaster Recovery from Microsoft MVP, Watch this Video of our SQL Server Virtual Conference,
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
C# Corner is organizing a week-long virtual annual event - Azure Summit.
Check out our
link to know more about the Summit.
General Purpose (Public Preview)
It is currently in preview. The remote storage here is zone redundant. There is guaranteed compute capacity in other availability zones and the database is resilient to the zonal outage. It is only available with Gen5 to compute hardware.
Premium and Business Critical
Here, the replicas are automatically created across zones and have “Synchronous Replication”. The increased network latency may increase the commit time. The database is resilient to the zonal outage and the feature is free for Business Critical & Premium. It is only available with Gen5 to compute hardware.
It is a feature of Azure SQL Database which allows readable secondary databases of individual databases to be created on a server in the same or another data center. It leverages the Always On availability group technology which is designed as a solution for Business Continuity. It allows asynchronously to replicate committed transactions and up to four secondaries are supported in the same or different region. These secondaries can be used for read-only traffic and are guaranteed to never have a partial transaction.
Auto - Failover Groups
The auto-failover groups is a feature in Azure SQL for SQL Database which allows us to manage the duplication and failover of groups of databases located on the server or even those managed on other regions. It only one secondary server or instance in a different region and secondaries can be used for read-only traffic. The listener end-points always remain unchanged during failovers. By default, the system is configured with an automatic failover policy and the failover of the read-only listener is disabled.
Today, we dove deep into the Business Continuity and Disaster Recovery services and features needed for enterprise-grade systems. Azure provides these amazing functionalities which always come in handy at times and give us peace of mind in the long run. We learned what Business Continuity and Disaster Recovery are and the processes we can obtain with Automated Backup, Built-in High Availability and Disaster Recovery, Zone Redundancy, Active Geo-Replication, and Auto – Failover Group.