Disaster Recovery of Azure Blob Storage

-

 

Disaster Recovery of Azure Blob Storage

In this post we will try to understand various approaches available to restore Azure Blob storage in case of any disaster reported in the region where the service was hosted. 

 

First, we need to understand the importance of having a disaster recovery approach. It is important as there are chances of unfortunate situation either technical or natural which can happen in the environment where our services are hosted. And based on how important the service is for our end-users, we can have one or the other approach or a combination of approaches.

 

These are the approaches we are going to discuss broadly.

·       Bring-up new blob using ARM templates

·       Enable Geo-replication on the storage account

·       Create snapshots of the blobs

 

Now, let's talk about them individually one at a time.

Bringing-up new blob using ARM templates

This is the easiest and cleanest way to recover from the disaster reported, i.e., keep an ARM template script ready before hand to spin-up a new service on an on-demand basis. Now looking on where we want to create the new services in the new environment or other environment, we can create a new service, but that mean we will not have the older data available. And in that case, we are ensuring that our system is running up for the new files to be inserted but there will not be any historical data available, which can be a very important issue for most of the applications. And as we are not having the historical data available this approach might not be even considered as a disaster recovery approach. 

 

Enable Geo-replication on the storage account

Another best option available in Azure is to enable Geo-replication on the service, that means the data will be replicated in various other regions or even different geographies depending on the need/ configuration we enable on the source/ primary blob storage service. This will ensure that a copy of our data is available in other region/ geography and the data can be recovered from there whenever a need arise. 

As we are having multiple copies of the same data in various regions the cost of storage will increase proportionately. 

 

Create snapshots of the blobs

Another interesting feature available is to create snapshots of the blobs which we need to be recovered at a later stage. We have to just call an ARM Rest API to ensure that a snapshot of the blob is created and stored separately (ideally in other region), so that in case a need arise we can use that to restore in our main storage service.

 

The limitation in this approach is that we have to do this operation using some script and we don't have an option to do it within Azure automatically. Having said that we can still automate it using various other services like Azure Automation Runbook to automate the same i.e., system will keep creating snapshots as per our setup, and whenever required the same can be used and restored.

 

Another important point to note in this approach is that only one blob can be snapshotted at a time and not the complete service nor the complete container. So, one need to be very much sure what blob they need to create snapshot for.

 

If we have a blob with the following URI.

https://mystorage.core.blob.windows.net/containername/myblob

The snapshot URI’s will look similar to as indicated below. Each snapshot for a given blob is differentiated by its unique timestamp which is associated in the URI.

https://mystorage.core.blob.windows.net/containername/myblob/snapshot=2021-01-11T15:00:00.1840000Z

 Extra:

We spoke about real disaster recovery approaches i.e., in case of issues in the region within the service. But there are chances where due to technical approach the file got accidentally deleted or removed, how do we overcome that.

 

Well, there is an approach for that as well i.e., using the soft delete feature in Azure Blob service, in this the file or the blob will not be deleted permanently or other way to understand the same is that it's not really a hard delete instead it's just a soft delete of that file and the same can be looked upon and used in case we need to.

Hope you liked the post, do provide inputs in the comment, also if you think the article will be helpful for any of your friends and relatives then please do share the article with them.

And don't forget to subscribe for the new post available so that you get notified on your mailbox.

Happy Learning. 📚

Comments

Post a Comment

Popular posts from this blog

Disaster Recovery of Azure API Management (APIM)

-
Image
Disaster Recovery of Azure API Management (APIM)     In this post, we will try to understand how we can apply a disaster recovery approach for Azure API Management aka. APIM. So, first of all, we will have to understand the importance of it. It's very important for an application using APIM to have a strong disaster recovery approach, as in case of any issue because of disaster reported, the system using the APIs underneath should be accessible for the users/ systems, and since the APIM is used as the fore front of the applications (mostly)  it's  important to restore the APIM service ASAP in case of any disaster reported, so that the application consuming the APIs underneath it  is  not having issue connecting to the APIs.       There are 2 broader options which one can think of:   Have a stand-by service in one or more regions   Service back-up and restore features    Let's  talk about both the approaches (one at a ...
Read more

API Aggregation Using Azure API Management

-
  API Aggregation Using Azure API Management         There are cases where we need to call multiple APIs from the client at the same time in order to proceed further with the processing from the client application. Now as oppose to calling those APIs individually  i.e.,  making separate HTTP requests for all those multiple APIs what if we can make one HTTP request and get all the responses aggregated in one response as opposed to multiple response isn't it going to be super cool.       So,  in this post we will try to understand how we can aggregate/ merge multiple API responses from the backend and provide one single request and response from the Azure API Management (APIM) to the calling client application.       To do this first of all we need to understand our APIs request body which we want to merge using APIM, so let say we want to call 2 APIs and  their   URI  are like this.       ...
Read more

API Response Compression in .Net Core

-
Image
API Response Compression in .Net Core If you are here, I am sure you must have used (consumed/ produced) APIs and indeed its been the case in modern web/ mobile application where APIs are used very frequently.  Data transfer size in case of APIs is a very big concern as the volume of data which can be transferred via APIs are not really meant to have huge data as because of following reasons: Data transfer time over network can be a big constraint if the size of data is huge APIs response time are expected to be fast and quick and if the volume of the data is huge obviously the response time of the API will be impacted as well, and no client application consuming the APIs will expect the response time of an API to be beyond a few seconds (at max). So how do we really solve this problem. Well we all understand that API is not really meant to perform huge data transfers but just in case we still have to do how to do it effectively. And there comes API compression frameworks at our re...
Read more