Backup and DR - VMs edition

Backup and DR: Prevention is Better than Cure: In today's digital world, our data is the most valuable treasure. From crucial documents to precious memories, everything is stored on our devices. But what happens when disaster strikes unexpectedly? This is where the importance of backups and disaster recovery readiness comes into play. In my latest article (the first was about Cloud Identity access), we will learn step by step how to keep our data safe with Backup and DR.

The Backup and DR service works thanks to 2 essential components, the Management Console and the Backup/Recovery Appliance, which we will explain shortly.

Our journey begins with the creation of 2 projects in our lab environment, which will be inspired by one of my favorite movies, Back to the future

To avoid disturbing our colleagues, we will keep our lab environment tidy and start by creating a folder: Back-2-the-future.

To avoid disturbing our colleagues, we will keep our lab environment tidy and start by creating a folder: Back-2-the-future.

Inside this folder, we create 2 projects, the first called "linea-temp-01"

And our second project will be "linea-temp-02".

Once the projects are created, we must activate the GCE API, either through the console or by command line in the terminal.

gcloud services enable compute.googleapis.com

Activating this API will not only allow us to create the Virtual Machines we want to backup but also to create our VPC to communicate our projects through VPC Peering.

Once our projects are paired, we can continue our journey.

For this article, I have created 3 e2-micro type Virtual Machines (VMs) in the "linea-temp-02" project, operating under the Linux operating system. These VMs are located in the zona de Santiago de Chile. (southamerica-west-1-a. Remember, our goal is to create a backup of these VMs in the "linea-temp-02" project.

Once our environments are ready, we can navigate through the hamburger menu (I like when they call it that) and look for the “Backup and DR” section.

And as usual, we will enable the service API.

The Backup and DR service works with 2 key components that we named at the beginning of the article:

• Management Console: Provides us with a graphical interface for all our backup and disaster recovery (DR) activities.
• Backup and Recovery Appliance: Helps us manage the capture, movement, and storage of our data.

In our console, after activating the API, we will first configure our Management Console.

We will have to choose the region where our console will be located, the VPC it will use, and finally, activate the PSA (Private Service Access).

Once our PSA is active, we will receive a message with a nice green background ticket.

Now it's time to configure our Back and Recovery Appliance, which operates on a VM, so an instance will be created in our project and a Service Account will be automatically created with the name of our appliance.

And before we can finish configuring our components, we must select what type of appliance we need: In this article, we stick with the first option, Standard for Compute Engine Machines.

The long-awaited moment has arrived, but first, we must wait about 40 minutes for our Management Console to be created.

After waiting about 25 minutes, a green background ticket indicates that the console has been created.

We click on LOG IN TO THE MANAGEMENT CONSOLE to see our welcome screen and a tutorial that I recommend watching if this is your first time delving into Backup and DR.

And our long-awaited console makes its appearance:

To start creating our backups, we first need a template, which we access from the menu:

Create Template.

In this section, we can create our template, assigning policies for snapshots, OnVault, etc.

I will create a snapshot policy by clicking on the + Add button.

From here, we can configure our policy, defining frequency, windows, retention, priority, etc. For this example, I assigned a descriptive name (snapshot every 24 hours, with 7 days retention and medium priority).

In the Advanced Policy Settings section, it is possible to configure our settings in more detail:

And our policy is created for the template.

A good practice is to assign a descriptive name to our template, in this case, create a snapshot every 24 hours with a 7-day retention, create it on a VM located in Chile, and store the snapshot in a US region.

We can create as many templates as our business requires. In this example, I created 2 templates, Tier 1 and Tier 2.

After defining our backup plan, we select from the top menu "Backup & Recovery", then define the type of application we are going to work with, in this case: Compute Engine.

Remember the name of our appliance? The Backup and Recovery service created a service account with the following minimum roles (principle of least privilege):

This service account will be the one we use to embark on our time travels, like the flux capacitor in this case.

To make travels across projects possible, it is necessary to assign this service account to the project where we have the VMs we want to backup, in this example: "linea-temp-02".

Having added the service account, we can return to our console, click on Next, and select our project and the zones where the VMs are located.

For this occasion, we will select our 3 VMs, Biff, Doc, and Marty, to which we will apply a backup from a template, which we created earlier.

For Marty and Doc, we select Tier 1 from our template, and for the villain Biff, the Tier 2 template.

And select whether we want a capture of all disks or just the boot disk.

Then, the Backup and DR service will create a bucket in GCS to store the metadata of the VMs.

If we have done well, we will see a green checkmark.

And in the App Manager section, we have a view of our applications and their status.

In the Dashboard, we can also see a summary, where we see our 3 managed instances.

To test our configuration, we go to the App Manager section, select a VM, in this case, Doc Brown, and click on Manage Backup Plan.

We deploy our snapshot policy and Run Now!!!

If we go to the Monitor and Jobs menu, we will see on our screen how the snapshot is being created with the status: Running.

Then we can return to our Dashboard and see the green color that usually leaves us calm....

At this point, we can perform our first Recovery, for this we go to the Backup & Recovery section and click on Recover.

We select the target application and Next. (for this example, we select the villain Biff Tannen)

In this screen, which I found very similar to the Guitar Hero, game, we can select the point in time when we want to perform our recovery. In this case, we have only one, as we have created only one snapshot.

On our left, we see a box which will provide us with information about the snapshot, let's click on Mount.

Here we will define whether we want the snapshot to be mounted on an existing VM or on a new VM, the type of hardware, the name of the instance, etc. In this case, the name of the instance is: beef-tannen-ha-viajado.

To verify that everything has gone well and that we have not traveled to another timeline, we go to the Monitor menu and then to Jobs.

Our Dashboard will show us that we have a service Succeeded and another in Running state:

After waiting a moment, we will have the green of life with 2 Jobs as Succeeded.

And finally, our villain Beef has traveled from timeline 2 to timeline 1, from Chile to the USA. We see him next to the Delorean that was our VM created at the time of configuring Appliance:

Thank you for completing this long journey together, and I hope it has been very useful for your future projects.

Erick Mercado - Cloud Engineer

Axmos.