Planning A Disaster Recovery Strategy On Microsoft Azure

Introduction

Previously we talked about Defining Recovery Requirements. In this article, I will discuss Data Backups in Azure. First, we will look at how Azure SQL, Cosmos DB, and the storage account service stores data. Then we will learn about replicating data stored in Cosmos DB, Azure SQL database, and storage account, which is all part of the popular Azure platform as a service. Finally, we will look at how to enable geo-redundancy and multi-region writes in Cosmos DB.

Azure Platform as a Service Data Stores: Azure SQL, Cosmos DB, and Storage Account

Cosmos DB, Azure SQL, and a storage account are all part of the Azure Platform as a Service data store. In this section, we will summarize all three Azure service data storage platforms.

Azure SQL database

A general-purpose relational database provided as managed service, with this type of database we can establish a highly available and high-performance data storage layer for the applications and solutions we are building on Microsoft Azure. We can create modern cloud apps with the SQL Database since it allows both relational data and known relational structures such as graphs, JSON, or XML.

Azure Cosmos DB

Modern applications are required to be highly responsive and always online to achieve low latency and high availability. These applications need to be deployed in data centers that are near to the end-user. It is not straightforward; applications must respond to huge changes in the use of big hours in real-time. Start collecting ever-larger amounts of data and making it available to users in milliseconds. No one enjoys having to wait for data. Microsoft Cosmos DB is a worldwide distributed multimodal database service.

Cosmos DB offers competitive service level agreements for throughput, latency, availability, and consistency, which no other database service can offers.

Microsoft Azure Storage Account is a cloud-based data storage solution for modern scenarios. It offers a massively scalable object store for data objects, a file systems service for the cloud, a messaging store for reliable messaging, and no SQL store.

Azure storage is durable and highly available. In the event of transitory, hard with failures, redundancy ensures that our data is safe. It is also safe to read data from Azure storage because it is encrypted. It can be scaled up or down. To satisfy the data storage and performance needs of today's applications, Azure storage is designed to be enormously scalable.

Planning A Disaster Recovery Strategy On Microsoft Azure

Data GEO-replication in the Azure SQL

Now we will talk about data geo-replication in the Azure SQL database, which makes full database backups, weekly differential database backups every 12 hours, and transaction log backups every five to ten minutes automatically. Database changes are automatically replicated to our secondary databases in the same or different Azure regions using Azure active geo-replication for SQL databases. For backup and restore, there is also a manual approach. For use with Azure SQL databases, an import-export service is available. We believe that by exporting databases as backpack files, a database can be reconstructed in the future.

SQL Database Business Continuity features

Temporal tables are a feature that allows you to access row versions from any point in time.
Building automated backups and point-in-time restore can be used to restore the entire database to a certain point in time. In the event of a data center outage or an application upgrade, active geo-replication allows you to create readable copies and manually failover to any of them.
In the event of a data center failure, the application's auto-failover group allows it to immediately recover.
A long-term backup policy allows backups to be kept for up to ten years.

Compare Geo-replication with failover groups

Geo-replication	Failover Groups
No automatic Failover	Auto failover

When we compare geo-replication to failover groups, we can see that geo-replication is superior. Primarily, there is no automated failover in the case of geo-replication. It means that if one of the databases in a certain area fails, we must manually fail over to the second region to gain access to the data.

Geo-replication	Failover Groups
No failover for multiple databases simultaneously	failover for multiple databases simultaneously
Connection String update require after failover	No connection String update require after failover

There is no failover for many databases at the same time in a Geo-application. The last significant distinction is that in the event of geo-replication, following a failover out of failover, we must manually change Connection String. Groups is a SQL database feature that lets us manage replication and failover of a group of databases on a SQL database server or all databases in a single instance to a different region.

Its additional level of abstraction, which is built on top of an active geo-replication feature, is intended to make large-scale deployment and management of geo-replicated databases easier.

Data GEO-replication in the Azure Cosmos DB

The emphasis in this section is on some of the features available in a Cosmos DB that enable high availability and disaster recovery. Backups of Azure Cosmos DB are kept in a different storage service, which I duplicated globally to defend against regional calamities. Every four hours, Cosmos DB takes a backup of our database, and only the two most recent backups are stored at any given moment.

Azure Cosmos DB persists even if the container or databases are destroyed. For the past 40 days, the existing snapshots of a certain container or database. So do not worry if you mistakenly deleted your database; there is a chance you can get it back. If the data size is less than 100 terabytes.

Global Distribution Basics

Azure Cosmos DB ensures that the data is available for operations within 30 minutes after the additional region is introduced. Therefore, if you decide to add another region, you can be assured that your data will be accessible after 30 minutes. When configuring two or more regions, there are two frequent circumstances. The first is to provide end-users with low-latency data access no matter where they are on the planet.

For the first scenario, the second scenario adds regional resiliency for business continuity and disaster recovery. For the second case, it is recommended that we deploy above the application and Azure Cosmos DB in the areas where the application’s users are situated to give low latency to end-users. As a result, other locations are recommended for business continuity and catastrophe recovery, depending on the region. In the first module, we discussed pairs.

Multi-master Support

Multi-master is another fantastic feature of the Cosmos DB. When an account is replicated over many regions, each area acts as a master region, participating in our right anywhere model equally. For Cosmo DB accounts, this feature can be activated via Azure Portal.

Multi-master in Azure Cosmos DB delivers high availability, single-digit millisecond write latency, scalability with building compressions if necessary, and customizable conflict resolutions. Support. Multi-master is made up of numerous master regions that do not all take part in the active butter model in the same way.

It is utilized to make sure that info is accessible whenever we need it. Updates to a single area may be synchronously propagated to all other regions, which then become our master regions. In a multi-master architecture, Azure Cosmos DB regions acting as master regions operate automatically to transform the data of all replicas and maintain global resiliency and data integrity.

Read Region priorities

Another interesting feature is Azure Cosmos DB. It is referred to as "regional priorities." With an automatic failover option, we may prioritize which regions should be read first using Dragon Drop.

Data GEO-replication in the Azure Storage Account

Geo-replication of data in an Azure storage account. It is worth noting that data in an Azure storage account is always duplicated to provide durability and high availability. Azure automatically stores data in an Azure storage account three times across various complete domains within the same Azure region. When geo-replication is turned on, the data is duplicated three times in various regions.

Locally Redundant Storage (LRS)

Within a single data center, locally redundant storage replicates the data three times. All replicas in a storage account using locally redundant storage may be lost and unrecoverable in the event of a data center disaster or cure. As a result, two more ways are suggested.

Use zone-redundant storage
Use Geo-redundant storage

Use Zone-redundant Storage

Zone-redundant Storage replicates data among free storage clusters in a single region synchronously. Each storage cluster has its availability zone and is physically segregated from the others. Data access and administration are still possible if one of the availability zones becomes inaccessible when data is stored in a storage account utilizing zone-redundant storage replication.

Use Geo-redundant storage

If geo-redundant storage is required, the data is replicated to a secondary region hundreds of miles away from the primary region. When geo-redundant storage is set on a storage account, data is preserved even in the event of a complete regional outage. It is replicated to the secondary region asynchronously, which means that there is a delay between when data is written to the primary area and when it is read from the secondary region. When critical information on an account is lost, there is usually some data loss. It is critical to comprehend the ramifications of initiating account failover. It means we must accept the fact that during a failover, some data may be lost and will not be saved.

Summary

We learned about the Azure platform as a service data store including Cosmos DB, Azure SQL, and storage accounts in this article. For these services, we learned various data geo-replication ideas.