Cold Disaster recovery on Google Cloud for applications running on-premises

Get Cooking in Cloud

Priyanka Vergadia
Google Cloud - Community
6 min readNov 3, 2019

--

Introduction

“Get Cooking in Cloud” is a blog and video series to help enterprises and developers build business solutions on Google Cloud. In this second miniseries I am covering Disaster Recovery on Google Cloud. Disasters can be pretty hard to deal with when you have an online presence. In the next few articles, we will elaborate on how to deal with disasters like earthquakes, power outages, floods, fires etc. If you are interested in the prior mini series covered, checkout this.

Here is the plan for the series.

  1. Disaster Recovery Overview
  2. Cold Disaster recovery on Google Cloud for on-premise applications (This article)
  3. Warm Disaster recovery on Google Cloud for on-premise applications
  4. Hot Disaster recovery on Google Cloud for on-premise applications
  5. Cold Disaster recovery for applications in Google Cloud
  6. Cold Disaster recovery for applications in Google Cloud
  7. Warm Disaster recovery for applications in Google Cloud
  8. Hot Disaster recovery for applications in Google Cloud
  9. Disaster recovery on Google Cloud for Data: Part 1
  10. Disaster recovery on Google Cloud for Data: Part 2

In this article, you will learn to set up a cold DR pattern for your applications that are deployed on-premises. So, read on!

What you’ll learn

  • Disaster Recovery for different applications
  • Cold DR pattern with an example
  • Steps to be taken before a disaster hits
  • Steps to be taken during a disaster
  • Steps to be taken after a disaster

Prerequisites

  • Basic concepts and constructs of Google Cloud so you can recognize the names of the products.

Check out the video

Cold Disaster Recovery on Google Cloud

Disaster Recovery (DR) for different Applications

Your DR plan would depend on your specific application and recovery goals. Let’s consider a few scenarios

  • If you run batch processing workloads, they tend to be non-mission critical and don’t need to be designed for High Availability. In such cases you would use Preemptible VM instances in conjunction with Google Cloud Storage. And.. that’s your DR plan!
  • If you have a video streaming solution, then starting from the search to actually streaming content, the entire experience needs to be HA or, the customer might turn to your competitor.
E-commerce website
  • If you run an e-commerce site, then the actual purchasing pipeline needs to have HA but the email process that sends notifications to customers can tolerate a bit of a delay. This, is a mix of hot (purchasing) and warm or cold (notification) patterns.

Let’s learn Cold DR pattern with an example

Mane-Street Art is a company that runs their applications on-premise and are building a DR infrastructure on Google Cloud. They are now working out a DR plan, with a low budget and are okay with a bit high RPO and RTO values. This means they need to set up a Cold DR pattern.

Note: If you are unfamiliar with the terms used here (RTO, RPO, DR Patterns) checkout the previous blog to get an overview.

In cold DR pattern Mane-street art needs minimal resources in the DR Google Cloud project — just enough to enable the recovery scenario. When a disaster occurs, the failover strategy requires a mirror of the production environment to be started in Google Cloud.

In any DR pattern you need to understand what steps need to be taken before a disaster hits, what happens when a disaster hits and what needs to happen after the disaster has passed.

Cold DR Pattern — How does it work?

Steps to be taken before a disaster hits

Visual for “Steps to be taken before a disaster hits in a Cold DR pattern”
  • Create a VPC network
  • Then configure the connectivity between the on-premises network and the Google cloud network.
  • You need a Cloud storage bucket as the target for our data backup.
  • For your on-premise machine to upload database backups to google cloud, you will need a service account key, to authenticate your machine within an automated script.
  • You would use IAM policies to restrict access to the right users as well as ensuring that the service account has the minimal permissions required
  • Make sure uploads-and-downloads, to-and-from the cloud storage bucket are working. Then you finally script the data transfer
  • Create a scheduled task to run the script.
  • Create custom images that are configured for each type of server in the production environment.
  • Configure DNS to point to your internet facing web services.
  • Create a Deployment manager template that will create servers in your Google cloud network using the previously configured custom images.

Steps to be taken when disaster hits

Visual for “Steps to be taken during a disaster in a Cold DR pattern”
  • When a disaster hits, all you need is to execute the deployment manager template, which will create a google cloud deployment automatically.
  • Apply the most recent database backups and transaction logs from cloud storage bucket
  • Test that the application works as expected by simulating a user in the recovered environment.
  • Then finally, point cloud DNS to the web server on google cloud.

Steps to be taken after the disaster has passed

Visual for “Steps to be taken after a disaster has passed, in a Cold DR pattern”

When the production environment is running on-premises again, and it can support production workloads, reverse the steps that you followed. Typically it goes something like this:

  • Take a backup and transaction logs of the database running on Google cloud
  • Copy and apply the backup file to the database in a production environment.
  • At this stage you should prevent connections to the application in Google cloud or you can stop the connections after the database has been successfully restored and apply any transactions that occurred after the backup was taken.
  • In our example case we need to stop connections to the global load balancer. From this point your application will be unavailable until you finish restoring the production environment.
  • Configure Cloud DNS to point to your on-premises web service.
  • Ensure that the process you had in place to copy data to Cloud Storage is operating as expected.
  • Then finally, delete your deployment.

Conclusion

If you are running your application on premise, have a constrained budget, and can work with high RTO and RPO values, then a cold DR pattern is the way to go. You learned how to approach recovering the environment from failure in a Cold DR scenario. Stay tuned for upcoming articles, where you will learn to set up more DR patterns that makes sense for your business.

Next steps

--

--

Priyanka Vergadia
Google Cloud - Community

Developer Advocate @Google, Artist & Traveler! Twitter @pvergadia