Backing up the Basis.DynamiX virtualization system using RuBackup

Hello to everyone who cares about data and is not going to lose it. Today we will look at the topic of backup of virtual machines (VMs) on the Basis.DynamiX virtualization platform (hereinafter referred to as DynamiX). To do this, we will use the backup system (BSS) RuBackup.

In this article I will tell you how to install, configure and use RuBackup to create backup copies (RC) of VMs on the DynamiX platform, and also discuss some difficulties that may arise during the work.

First of all, the article will be useful for administrators of the DynamiX virtualization platform who need to configure backup in the system. The article is also suitable for beginners who want to understand how RuBackup works in general.

Don't forget about the links at the end of the article, they will be useful!

Configuring RuBackup to work with the DynamiX virtualization system

Let's start with an overview of the basic architecture RuBackup and the capabilities that this system provides for backing up virtual machines in DynamiX (versions 3.8.8 – 4.0.0). In this part, I propose to discuss some technical features of the process.

How does RuBackup work?

To understand the issue, let’s consider the general architecture of RuBackup outside the context of working with DynamiX.

In a simplified form, RuBackup works according to the following scheme: the main server (media server), the client and the modules required by the user (in our case, rb_module_dynamix) are installed on a virtual (or physical) machine.

The server interacts with clients, coordinates SRK tasks and stores backup copies on resources available to it: file systems, block devices, tape library cartridges and cloud services.

The client is responsible for backing up resources (for example, DynamiX VMs) and transferring them to the server for storage.

Storage of backup data (archives) is implemented in the form of storages, where each storage is included in a specific pool. A pool is a logical combination of backup storage devices of the same type. Each pool belongs to a specific media server.

During normal operation, the RuBackup server and client run on the host as background processes (daemons).

RuBackup supports full, incremental and differential backups.

A full backup is a backup of all the data in the original set, regardless of whether the data has changed since the last full backup was performed.

An incremental backup only saves data that has changed since the previous incremental backup was performed, or, if there is none, since the last full backup was performed.

A differential backup only saves data that has changed since the previous full backup.

Figure 1 shows the RuBackup architecture.

A more detailed description of the key concepts, architecture and overall operation of RuBackup can be found in the technical documentation [1].

Installing RuBackup and the DynamiX module

First of all, it is worth emphasizing the philosophy of the RuBackup team: we strive to make the backup process accessible and convenient for everyone. That is why we decided to provide a trial license that allows you to back up up to 1 TB of data for free. This allows users to get acquainted with the product and evaluate its capabilities in practice. You can try RuBackup using this link [2].

The process of installation and initial configuration of RuBackup is described in more detail here [3]the installation process for the DynamiX module is here [4]. There you can also find information about supported operating systems.

For RuBackup to work, the server requires PostgreSQL with certain settings, as well as additional packages (for example, mailutils, libcurl, etc.), correct configuration of the “.bashrc” file and opening of the necessary ports. Detailed information about supported PostgreSQL versions and a list of required packages is provided here [2].

To install, you need to obtain six packages:

• rubackup-common__amd64_signed.deb – common RuBackup libraries;

• rubackup-client__amd64_signed.deb — RuBackup client;

• rubackup-dynamix__amd64_signed.deb – module for working with DynamiX;

• rubackup-server__amd64_signed.deb — RuBackup server;

• rubackup-common-gui__amd64_signed.deb – RuBackup common graphics libraries;

• rubackup-rbm__amd64_signed.deb – RuBackup graphical manager (RBM).

Note: although RuBackup can be used without a graphical interface, further demonstration of the functionality will be shown using the example of using the RBM graphical manager.

After installing the packages using the “dpkg” utility, you need to run the “rb_init” utility to configure RuBackup. Without this setting, the system will not work, so it is important to perform it correctly. The installation guide describes a simple installation scenario – “All in one”, where the RuBackup server and client are on the same host.

Starting from version 2.1, it is possible to work with RuBackup via the REST API, which is also described in detail in the installation manual [3] and administration [1].

Setting up the DynamiX module

Almost every module in RuBackup requires additional configuration, and the module for DynamiX is no exception. For correct operation, you need to fill out the configuration file rb_module_dynamix.config, which appears in the /opt/rubackup/etc directory after installing the rubackup-dynamix__amd64_signed.deb package. More details about the parameters of the DynamiX module are described here [4].

Main module parameters:

• url – DynamiX WEB URL (aka REST API URL);

• login_url – URL for authorization within DynamiX;

• client_id – “Application ID” from login_url;

• client_secret – “API Key” from login_url;

• hypervisor_backup_path — disk path for backup on the DynamiX hypervisor;

• local_backup_path — disk path for backup on the RuBackup client;

• backup_disk_timeout, restore_disk_timeout — disk backup and restore timeouts in minutes;

• allow_work_with_incompatible_versions – yes/no parameter for trying to work with unsupported versions of DynamiX.

To get the client_id and client_secret values, you need to log in to the login_url (for example, https://sso-.ru) and create an access key. Figure 2 shows the DynamiX admin portal interface.

Shown here are the “Application ID” fields for the login_url field and the “API Key” for the client_secret field. It is important that the user creating the keys has administrative rights on the DynamiX platform.

Now let's take a closer look at the “hypervisor_backup_path” and “local_backup_path” parameters. The RuBackup client is not located on DynamiX hypervisors, so it does not have direct access to virtual machine disks. For backup, an NFS directory is used that connects the DynamiX hypervisors with the host on which the RuBackup client is running. This is shown in Figure 3.

“local_backup_path” is a directory on the RuBackup client, which is connected via NFS to the “hypervisor_backup_path” directories on hypervisors. The paths to these directories must be specified in the rb_module_dynamix.config configuration file. If there are several hypervisors, they must also be connected via NFS.

The NFS directory must have anonymous access configured with full rights to the destination directory. Otherwise, DynamiX will not be able to save VM disks to this directory, and RuBackup will not be able to create backup copies of them.

The size of the NFS directory must correspond to the volume of simultaneously backed up and restored data. For example, if the directory size is 100 GB, and two backup tasks are running simultaneously for two VMs with 80 GB disks, one of the tasks will fail due to lack of space in the directory (80 + 80 > 100).

The configuration file has a number of required and optional parameters. Optional parameters are commented out. An example of a completed file is shown in Figure 4.

Using RuBackup for DynamiX backup

So, the setup is complete. Now we have a virtual machine with the RuBackup client and server installed. The client communicates with the DynamiX hypervisor via NFS. Let's launch the RuBackup server and client and look at the log file “/opt/rubackup/log/RuBackup.log” (Figure 5).

If an error occurs at this stage and the module is unavailable, check the configuration file settings are correct and make sure that access to the DynamiX platform is configured correctly. To ensure that the module is configured correctly, run the module with the “-t” option. After making sure that the check is completed successfully, you need to restart the RuBackup client service.

Next, using the “rbm&” command on the RuBackup server, open RBM, go through authorization and in the “Objects” window we will see a list of clients. You need to select the client on which the DynamiX module was installed. If you select the simplest setup with client and server on the same host, then one client will be available. Figure 6 shows the selected client.

As you can see, RuBackup supports many settings and configurations. For now, let's focus on a simple virtual machine backup. To do this, we will find the desired VM in the DynamiX interface, for example a VM, as in Figure 7.

To create a backup copy of this VM, select the client “rb-nfs” (the client name may be different) and click on the arrow button above the client. In the “Resource” field, fill in the virtual machine ID. This can be done through the list by clicking on the icon with three dots to the right of the “Resource” field.

As you can see above, you can also choose many different settings in the Urgent RK interface. To configure the module backup parameters, you need to click on the icon with three dots to the right of the “Resource type” field.

The “local_backup_path” and “hypervisor_backup_path” parameters duplicate the parameters of the same name from the rb_module_dynamix.conf configuration file, but with the following condition: if values ​​for these parameters are specified for the backup, then when executing the backup task they are used, and not the values ​​from the configuration file. If the parameters are not specified (empty), then the values ​​from the configuration file are used.

Let's start the backup by clicking the “Apply” button in the upper right corner of the Urgent RK interface (Figure 8). After this, the backup process will begin, and a task will appear in the “Objects” tab.

After successful completion of the task, the RK will appear on the “Repository” tab.

As can be seen from Figure 11, in the repository the backup copy of the backed up virtual machine has ID 46. The ID of VM 2110 is displayed in the “Resource” column.

To restore the RC, right-click on the RC and press the “Restore” button, as shown in Figure 12.

Next, the Centralized Recovery of the Republic of Kazakhstan window will open. In it you must specify the “Extraction directory” and activate the “Restore to target resource” option.

The specified directory must have 110% of the space of the original VM size, since VM disks, configuration text files, and service information will be unpacked into this directory.

Activating the “Restore to target resource” option is necessary to start the process of deploying the VM to the DynamiX platform. If the parameter is not activated, the VM RK will be unpacked in the specified directory. It will contain the VM disks and a text file with the configuration.

An example of the Centralized Recovery of the Republic of Kazakhstan window with filled fields is shown in Figure 13.

Next, you need to click the “Apply” button in the upper right corner – a new task with the “Restore” type will be displayed in the “Objects” field. We are waiting for completion.

After some time, the task will change to Done status, and a new VM restored from the backup will appear on the platform.

As can be seen from Figure 14, the VM was restored as a full-fledged new VM with a new name (the prefix “_1” was added to the original name) and with a new ID on the platform. Then it can be used as the original VM. You can log in to the VM using account data from the backed up VM.

DynamiX Module Recovery Options

Before restoring the RC, you can set specific settings for the module that change the recovery logic.

During the recovery process, in the “Centralized Recovery” window, after clicking on the icon with three dots opposite the “Recovery options for module” field, the following window will open:

If you clear the “Use default settings” checkbox, you can change the settings.

When the “restore_to_original_vm” parameter is enabled, the RK will be restored to the original VM from which the RK was made. A new VM will not be created. The ID and name of the original VM will be preserved, only the content at the time of creation of the RC will be restored.

The “local_backup_path” and “hypervisor_backup_path” parameters, as in the case of backup settings, duplicate the parameters of the same name from the rb_module_dynamix.conf configuration file.

Conclusion

In the article, I looked at how to use the RuBackup backup system, including installing and configuring the DynamiX module. Gave examples of performing a virtual machine backup.

RuBackup also offers many additional features and settings for more detailed configuration. For example, you can use backup rules and strategies, as well as perform incremental and differential backups. These methods can reduce the size of backups and increase backup speed.

Useful links

1. https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20sysadmin%20guide%202.2.0.pdf — System administrator’s guide to working with RuBackup

2. https://www.rubackup.ru/go/ — Trial version of RuBackup with a limit of 1 TB

3. https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20installation%20guide%202.2.0.pdf — RuBackup Installation Guide

4. https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20Dynamix%202.2.0.pdf — Manual for working with the DynamiX RK module