Configure Application/Crash consistent backup for VM – Azure

How to configure application-consistent backup on Azure native backup? Backup is extremely important for any services that you use on the cloud. Azure native backup takes VM snapshot and transfers to vault for data protection. In the Azure native backup page, have you noticed three different kinds of restore points? Here are the three different kinds of restore points.

• Crash consistent
• Application consistent
• Files-system consistent.

Most of the restore points will be tagged as a file-system consistent backup. Do you know why? Is it enough to recover the application? Nope

Create Crash consistent restore point:

A crash-consistent restore point is only possible if you shut down the VM. In an order to create a crash-consistent restore point, follow the below steps

1. Shutdown the VM
2. Trigger the VM backup.
3. Once the snapshot is complete, you can start the VM.
4. You no need to wait until the snapshot transferring to the vault.

Configure Application consistent – Azure Backup

We can’t halt the VM to create a crash-consistent snapshot on a daily basis. At the same time, our applications should start when the VMs boot after being restored. To address this problem, we need to produce application-consistent snapshots. Now you can imagine, application consistency is extremely important. To ensure transactional consistency, applications need to be quiesced and there should be no unfinished transactions when taking a VM snapshot.

Windows VM vs Linux VM

Windows has the Volume Snapshot Service (VSS) framework to ensure application consistent VM backup, but there is no such generic framework for Linux.  To ensure your Linux VMs are application-consistent, you can use the Linux pre-script and post-script framework to take application-consistent backups.

How the framework works ?

How to Configure pre-script and post-script ?

1.Login to Azure Linux VM in which you would like to configure applicaiton consistent backup.

2. From GitHub, download VMSnapshotScriptPluginConfig.json and copy it to the /etc/azure folder for all VMs you want to back up. If the /etc/azure folder doesn’t exist, create it.

[root@myvm azure]# cat /etc/azure/VMSnapshotScriptPluginConfig.json
{
    "pluginName" : "ScriptRunner",
    "preScriptLocation" : "",
    "postScriptLocation" : "",
    "preScriptParams" : ["", ""],
    "postScriptParams" : ["", ""],
    "preScriptNoOfRetries" : 0,
    "postScriptNoOfRetries" : 0,
    "timeoutInSeconds" : 30,
    "continueBackupOnFailure" : true,
    "fsFreezeEnabled" : true
}
[root@myvm azure]# 

3. Please get pre-script and post-script files from the respective application/database team. For example, If you are running myql database, you will be getting pre-scripts to put the database in read-only mode, and postscript will change it back to read write again.

MySQL database:

[root@myvm azure]# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6
Server version: 5.5.65-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE wordpress2;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> show databases
    -> ;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| wordpress          |
| wordpress2         |
+--------------------+
5 rows in set (0.00 sec)

MariaDB [(none)]> exit
Bye
[root@myvm azure]# 

I have the following pre & post scripts to use for testing purpose.

-rwx------. 1 root root 566 Jun 6 18:02 pre-mysql-backup.sh
-rwx------. 1 root root 569 Jun 6 18:02 post-mysql-backup.sh
drwx------. 2 root root 45 Jun 6 18:38 logs

4. Update the downloaded JSON with pre & postscript file location. (Refer step 2 ).

[root@myvm azure]# cat /etc/azure/VMSnapshotScriptPluginConfig.json
{
    "pluginName" : "ScriptRunner",
    "preScriptLocation" : "/opt/backup/pre-mysql-backup.sh",
    "postScriptLocation" : "/opt/backup/post-mysql-backup.sh",
    "preScriptParams" : ["", ""],
    "postScriptParams" : ["", ""],
    "preScriptNoOfRetries" : 2,
    "postScriptNoOfRetries" : 2,
    "timeoutInSeconds" : 30,
    "continueBackupOnFailure" : true,
    "fsFreezeEnabled" : true
}
[root@myvm azure]# 

5. The framework gives users a lot of power. Secure the framework, and ensure only “root” user has access to critical JSON and script files. If the requirements aren’t met, the script won’t run.

• Pre & Postscript must be set as 700 (Should be owned by root)
• File – /etc/azure/VMSnapshotScriptPluginConfig.json must be set file permission as 600.

6. Trigger the VM backup from the Azure portal. It will trigger the prescript and initiate the VM snapshot. During this phase, it will trigger the postscript once it got consistent backup data. Here is the pre & post scripts logs.

[2020/06/06 19:28:59 UTC] INFO: Starting PRE actions for role master
[2020/06/06 19:28:59 UTC] INFO: Setting read-only status
[2020/06/06 19:28:59 UTC] INFO: PRE for role master finished
[2020/06/06 19:29:09 UTC] INFO: Starting POST actions for role master
[2020/06/06 19:29:09 UTC] INFO: Unsetting read-only status
[2020/06/06 19:29:09 UTC] INFO: POST for role master finished

7. Once the snapshot is done, you can see the new recovery point with application consistent.

We have successfully configured application consistent backup using the pre & post scripts. Hope this article is informative to you.