A program for backing up VMware virtual machines. Free backup of virtual machines based on VMware ESXi Configuring backup parameters for virtual machines

Let's look at and compare two methods for backing up VMware virtual machines.

Initial data

The test bench consists of two ESXi hypervisors on a Fujitsu Primergy BX2560 M2 server connected via SAN (two 8 Gbit/s ports) and LAN (two 10 Gbit/s ports). ESXi and VSCA version 6.5. For ESXi, the disks were presented by the Fujitsu ETERNUS DX8700 S2 storage system. As a backup storage system we use an EMC Data Domain 6300 connected via SAN (four 8 Gbit/s ports). To perform a backup, in order to save time, we will use the ready-made Backup Exec tool. The system management server is installed on a physical HP ProLiant BL460c Gen8 server and also has a network connection via SAN and LAN with two ports.

Three virtual machines were created for testing: VM1 (146Gb), VM2 (157GB) and VM3 (284Gb). The testing procedure will look like this: we will perform FULL Backup of each system three times, after which we will calculate the average backup speed (Gb/min) for each method.

The Backup Exec system has four ways to access virtual machine data, for a physical server these are SAN, LAN (NBD), NBDSSL and the fourth, if the Backup Exec server is installed on a virtual machine, HotAdd. Let's test the option when Backup Exec is installed on a separate physical server and compare the pros and cons of performing backups over SAN and LAN.

Setting up Backup Exec is quite simple and consists of the following steps:

1. Select an existing or create a new task to perform a backup of virtual machines
2. Open properties for this task
3. Go to tab Virtual Machines > VMware subsection
4. Mark the connection method we need (it is permissible to activate all four methods at once and set their order of use)

METHOD ONE: BACKUP VIRTUAL MACHINES OVER SAN

In order for Backup Server to backup ESXi virtual machines over a SAN, it must first present the same LUN(s) that were presented to ESXi. In this case, Backup Server, using the vStorage API, requests information from vCenter in which LUN the VMDK of the virtual machine is located, takes a snapshot of the disk and picks it up over the SAN.

The result of this experiment is average.

METHOD TWO: BACKUP OF VIRTUAL MACHINES OVER LAN (NBD)

In this mode, Backup Server requests from vCenter information about which ESXi the virtual machine we need is located on, takes a snapshot and transfers it over the local network from the ESXi server to the Backup Server.

The result of the second experiment is average.

CONCLUSIONS, PROS AND CONS

If you build a modern infrastructure from scratch using network equipment with a bandwidth of 10 Gbit/s, then using backup in the mode of connecting to data via a local network (NBD) will most likely be more cost- and time-effective. In the case when the network between ESXi and Backup Host is 1 Gbit/s, and the necessary equipment for connecting via SAN is already available, then the first method will be more efficient and faster.

The main advantage of performing a backup over a SAN is that data transfer does not load the local network and is performed at a fairly high speed, but in the case of a 10 Gbit/s network this is no longer such a clear advantage, since even with relatively large volumes of information the backup window does not take much time.

The main advantage of performing backup over LAN is the ability to use cheaper equipment as a data storage system. And as the test showed, building a modern network on 10 Gbit/s equipment will provide faster backup than an 8 Gbit/s SAN.

Restoring virtual machines with thick disks via SAN is performed quite quickly, but it is better to refuse recovery with thin disks because this often ends with an error or crash.

From general practice, we can say that to restore virtual machines it is better to always use a local network and not overwrite the old virtual machine, but try to restore it to a new location.

The information used in the article is taken from official sources.

To organize an automatic backup system for virtual machines running on a VMWare ESXi server, we will use a free utility MKSBackup, which you can download (at the time of writing, the latest available version is MKSBackup 1.0.4 dated January 24, 2013). This utility is a kind of front-end that integrates with various backup scripts, including GhettoVCB(VM backup script written in perl and maintained by enthusiasts). GhettoVCB allows you to create online backups of running virtual machines. A VM backup is created by creating a snapshot of it.

Important. GhettoVCB does not work with virtual machines that have their own snapshots. To perform a backup of a virtual machine, all snapshots must be deleted (for example, through Snapshot Manager).

MKSBackup is one of the few backup tools that allows you to perform online backup of virtual machines. MKSBackup can be used to backup virtual machines running on both commercial editions of VMware ESXi and free VMware Hypervisor. The utility is developed in Python and is cross-platform. The MKSBackup utility does not have a graphical interface, works via the command line, and is configured through configuration files.

Naturally, the convenience and manageability of the solution for organizing backup of VMWare virtual machines based on MKSBackup is lower than that of commercial products, but is largely compensated by its free nature, ease of configuration and speed of deployment.

Installing the MKSBackup backup script

Configuring virtual machine backup settings

The next step is to configure the backup settings for virtual machines running on the ESXi server. Configuration is carried out by editing the mksbackup.ini configuration file (located in the C:\Magik folder by default).

Open the mksbackup.ini file in any text editor. The structure of the file consists of several sections, the name of each section is enclosed in square brackets.
Section:

In this section you can set email notification parameters. We are not interested in this, so we will leave it

Next section. This section represents the backup task and describes the various parameters that ensure the launch of a backup of virtual machines in the Windows environment. In our example, the task looks like this:

Program=ghettovcb host=10.10.1.89 port=22 login=root password=LI&f3ccc23 local=C:\magik\vmware global_conf=ghettoVCB.conf vm_list=vm1_https winXPtest destination=C:\magik\$(vm) scp_bin="D: \Install\Putty\pscp.exe" -scp -r

Let's take a closer look at the task parameters:

program– backup program, leave ghettovcb

host– name/ip of the ESXi host on which the virtual machines are running

port– port for access (default port 22 – SSH protocol)

login– username with access rights to the ESXi server (by default this is root, but for security purposes it is better to create a separate user on the ESXi server)

password– user password

local– local directory in which the backup script and its configuration are stored

global_conf– file with ghettoVCB script settings

vm_list– a list of virtual machines for which you need to create a backup copy. If you need to back up all virtual machines, this parameter should be left empty. If you need to exclude some virtual machines, use the vm_exclude parameter.

destination– the parameter allows you to specify the type of operation to be performed. It could be

• backup – perform a simple backup (no need to specify a destination)
• copy – perform a backup and copy the resulting files to the specified directory
• move - perform a backup and move the resulting files to the specified directory

Let's focus on the move option, as it is more optimal. In this case, local backups of virtual machines will be created on the ESXi host, which will then be transferred to the computer running the script.

mon-sun – it is assumed that the script can be executed daily (we will leave it this way, since we will set the frequency of running the backup through the Windows scheduler).

In addition, we will indicate the directory into which VM backups will be moved (C:\magik). The $(vm) parameter indicates that a separate directory with its name will be created for each virtual machine, where the virtual machine files will be stored.

Note. A detailed description of the script's configuration settings and its syntax is provided on the developer's website.

scp_bin– path to the scp utility

Important. Make sure the SSH daemon is enabled on the ESXi server.

VM_BACKUP_VOLUME=/vmfs/volumes/msa2000/backup VM_BACKUP_ROTATION_COUNT=3

VM_BACKUP_VOLUME– a directory on the ESXi server in which copies of virtual machines will be saved (naturally, there should be enough free space on the VMFS partition)

VM_BACKUP_ROTATION_COUNT– the number of local copies to be stored (in our example, the last 3 backup copies will be stored)

All that remains is to use the plink utility (also included with Putty) to save the host key in the local ssh cache. For example, like this:

PLINK.EXE [email protected] ls /

Running a backup of virtual machines on a VMWare ESXi host

Let's test the backup script. To do this, open a command prompt with administrator rights and run the command:

C:\Magik\MKSBackup\mksbackup.exe -v -c C:\Magik\mksbackup.ini backup VMWARE_FROM_WINDOWS

Where is the key –v indicates that detailed information should be displayed, -c path to the settings file mksbackup.ini, backup– means that you need to start a backup, at the end the name of the task from the file is indicated mksbackup.ini(in our example, the task is VMWARE_FROM_WINDOWS).

If everything is configured correctly, the utility will begin to display detailed information about the backup process to the console (the backup process is quite lengthy, so you shouldn’t expect it to finish quickly).

The backup process can be tracked by the appearance of snapshot creation/deletion events in the VMware vSphere console.

During script execution, folders containing virtual machine files will appear in the destination directory.

After performing a test copy, you can move on to automating the backup process. To do this, let's create a new Windows scheduler task.

Let's create a task named “Backup ESXi”, which runs on Fridays and runs the command: C:\Magik\MKSBackup\mksbackup.exe -v -c C:\Magik\mksbackup.ini backup VMWARE_FROM_WINDOWS

In the task settings, do not forget to specify that it needs to be run with administrator rights (the “Run with highest privileges” option).

Note. If the task will be run under a different account (not the one under which testing was performed), you must remember that the cache of the new account will not contain the required key. To solve the problem, you need to run the above plink command from a new account.

Disadvantages of this given method of backing up virtual machines:

• rather low backup speed
• a large amount of free space required to store VM backups

These disadvantages are compensated by its free nature, but for large solutions it is preferable to use commercial backup products, such as Veeam or HP DataProtector.

The task arose of organizing backups of Hyper-V virtual machines from individual virtualization hosts (without a cluster) on several remote sites. Due to the fact that one of the inputs of this task is the presence of very modest and unstable communication channels, the idea of ​​​​using a single backup server on a central site disappeared on its own. Because it’s one thing when you can consolidate backup copies into one central location, taking into account block changes, while reducing the load on the network, for example, with the same System Center DPM, and quite another thing if, in a short time, you need to perform a complete recovery of a VM at a certain point in time through these same weak channels. Thus, it was necessary to think about how to organize backup of virtual machines directly on a remote site, provided there was no increase in the ongoing costs of licensed software and existing equipment.

It so happened that at these remote sites, in addition to the virtualization host, there is an old server that was previously decommissioned, but quite working IBM System x3200, which can be used as a file server to store backup copies of virtual machines. The idea arose to install additional disks on this server and deploy it as a base OS Linux with package QUADStor, with the help of which, in turn, create a virtual disk with support for block deduplication and using the protocol iSCSI present this disk to the virtualization host Hyper-V, and already on the virtualization host, using the product, configure “hot” backup of virtual machines to this same iSCSI disk. The end result should be “cheap and cheerful”. In this note I will describe the procedure for setting up such a design.

Preparing a file server based on Debian Linux with QUADStor

The disk basket of our future IBM System x3200 file server in the existing configuration supports no more than 4 SAS/SATA 3.5" drives. Considering that the controller in this server model is also very modest (LSI Logic SAS1064ET) and, to put it simply, can only “strip” or “mirror”, we will create two mirrored pairs of disks - the first on two existing low-capacity SATA disks for the Linux operating system, and the second on two additionally installed low-cost 1TB SATA disks for storing VM backups (for the QUADStor virtual disk).

So, without any special frills, we install the OS on the first pair of mirrored disks Debian GNU/Linux 8.6 (Jessie). We leave the second mirrored pair of large disks unallocated.

Let's move on to installation and configuration.

Installation procedure QUADStor for different Linux distributions is described in the documentInstallation/Upgrading on RHEL/CentOS 5.x, 6.x, SLES 11 and Debian 6.x, 7.x . Based on the fact that in our case we are using Debian, we install the pre-required packages: