Many businesses, as well as home users, are increasingly using virtual machines to perform various tasks and increase the efficiency of their activities. While previously virtual machines were used mainly by enthusiasts, now the quality of desktop and server virtualization platforms has allowed them to be used by professionals on a large scale. The ability to run multiple virtual systems on a single physical computer has many benefits, including savings on hardware, easier maintenance, and reduced energy costs in large data centers. In addition, an important advantage of virtual machines is their easy portability to another physical platform and a simple procedure for backing them up. But just like conventional operating systems, virtual environments require high attention to backing up critical data. When running virtual machines in an enterprise production environment, many companies plan entire strategies for backing up and restoring virtual infrastructure after failures, which are called Disaster Recovery.

Many commercial virtualization platform vendors offer enterprise users built-in virtual machine backups, such as VMware Consolidated Backup (VCB) for the ESX Server platform. However, in the SMB (Small and Medium Business) sector, where the number of used virtual machines is small, there are practically no backup tools provided by the platform manufacturer. As a result, small companies have to involve system administrators to write various scripts, as well as use standard operating system utilities that provide archiving and restoring files and folders with vital data.

General information about data backup

Simultaneously with the virtual infrastructure planning process, you must also initiate the process of developing a backup and disaster recovery plan (Disaster Recovery Plan). First of all, it is necessary to highlight the most critical elements of the IT infrastructure that are potentially susceptible to damage from internal and external sources, such as power outages, hard drive failures, virus threats, and others. After that, it is necessary to consider the frequency of backup of virtual machines of various categories, depending on the degree of criticality. The company's virtual production servers, which operate in full public availability mode, should be backed up quite often and regularly and have the property of being quickly recoverable in case of failure. Internal servers of the organization that do not require such high attention and quick recovery, can be archived less often, with a longer recovery time. Next, you need to determine which storage devices will be used for archiving (IDE or SCSI drives from other servers, SAN devices, etc.).

When choosing a backup frequency, keep in mind that some types of backups have the property of fast backups, but slower restores. Conversely, it is possible to perform a longer backup with a shorter recovery time. The following are the main types of data backup that can also be applied to virtual machines:

• Normal (full) archiving (full backup)
  This type of archiving creates a complete copy of all stored data. The process of creating such backup quite long, but it does not take much time to restore, because it does not require multiple restore tasks. A full backup resets the file and folder backup markers that are used to determine which files to back up. These markers are used to check the status of files during incremental and differential backups.
• Incremental backup
  This type of backup involves copying files and folders that have changed since the last backup. Therefore, if you perform two incremental backups in succession and do not modify the file in between, it will not be added to the recovery image.
• Differential backup
  This backup includes all changes that have occurred to files and folders since the last full backup. Accordingly, with two consecutive differential backups, a file that has not changed between them, but has changed since the last full backup, will be archived both times.

In order to explain how these types of archiving differ, we will give an example of combining types of backup. When using full and incremental backups, the backup time is significantly reduced, but the recovery time is increased. For example, if we did a full backup on Monday and rolled incremental backups daily, and the system was damaged on Friday, we will need to restore the full backup on Monday and successively all incremental backups until Friday, which will take a very long time. Combining full and differential activation, on the contrary, requires more time for archiving, but less for restoration, since it will be necessary to restore only the full backup copy of Monday's data and roll Friday's differential archive onto it.

These, of course, are not all types of archiving that can be used when backing up data, however, the listed types are among the most commonly used. It is obvious that for servers with high restore time criticality it is more reasonable to use differential backup in combination with full backup rather than incremental backup. The first is suitable for external servers of the organization, the second - for internal ones, which are allowed more downtime.

Since, basically, a virtual machine is a folder with files, you can use the built-in backup tools of the host operating system, if you use a virtualization platform on top of a host system, such as, for example, Microsoft Virtual Server or VMware Server. V Microsoft Windows For these purposes, you can use the utility ntbackup. When using bare-metal (bare metal) platforms, such as ESX Server or Virtual Iron, you need to use the tools of the virtualization system manufacturer or third-party products.

In addition, virtual machines can be backed up by creating guest system images using software such as Acronis True Image. It is also worth noting that there are situations when it is necessary to back up not the entire virtual machine, but some data in the guest system. In this case, when writing batch scripts for archiving, you can use the utilities for mounting virtual disks to the host system. For VMware platforms, this utility is the VMware Disk Mount application.

Backing up and restoring virtual machines on the VMware ESX Server platform

VMware's pilot product, the ESX Server platform, is a key element of virtual infrastructure in an enterprise's production environment. Virtual Infrastructure VI3 (Virtual Infrastructure 3) is a set of products and tools that allow a fleet of virtual machines to efficiently perform their tasks and function smoothly in various conditions, including such force majeure factors as sudden load spikes, power outages and equipment damage. One of the most important tools for implementing a Disaster Recovery strategy is the VMware Consolidated Backup (VCB) backup tool. VCB can be used to create backups of individual ESX servers, as well as in conjunction with the VMware Virtual Center virtual server fleet management tool. VCB provides the following features:

• creation of archive copies of virtual machines with various types of archiving using a special VCB Proxy Host proxy server, which removes the burden of creating backups from the production server of the company where the virtual machines are running
• does not require installation of additional agents on ESX servers
• provides ample opportunities for integration with third-party backup products, support for various packages is already built into VCB
• supports file-level archiving for guest Windows systems(you can create archive copies individual files and folders inside the guest system), as well as archiving at the level of virtual machine images for any guest OS

Creating backup copies of virtual machines using VCB occurs by creating instant snapshots of virtual machines without stopping their work. VCB also supports SANs. If the virtual machines are located on a SAN storage device, the backup procedure is as follows:

Snapshots of virtual machine states created during operation using an agent located on the VCB proxy server are stored on backup media, from where they can then be restored in the event of a failure of the running guest system or equipment damage. In this case, the backup agent has direct access to the LUNs (Logical Unit Number) in the SAN devices. For SANs, VCBs support the Fiber Channel protocol as well as tape media for archiving. VCB closely uses the capabilities of VMware Tools running inside the guest system to back up guest OS data.

VMware Consolidated Backup currently supports the following packages (the list includes only officially tested software with the ESX Server product):

• Symantec Backup Exec 10.0
• Symantec Backup Exec 10d
• Veritas Netbackup 5.0
• Veritas Netbackup 5.0 MP4
• Veritas Netbackup 5.1
• Veritas Netbackup 5.1 MP2
• Veritas Netbackup 5.1 MP3
• Veritas Netbackup 6.0
• Tivoli Storage Manager v5.2.1
• Tivoli Storage Manager v 5.2.3
• Tivoli Storage Manager v5.3
• EMC Networker v7.0
• EMC Networker v 7.1.x
• EMC Networker v7.2
• EMC Networker v 7.3
• CA BrightStor ARCServe r11
• CA BrightStor ARCServe r11.1
• CA BrightStor ARCServe r11.5
• Commvault Galaxy 5.9
• Commvault Galaxy 6.1

The work of creating archive copies of virtual machines in the general case can be represented as follows:

1. The backup software runs a backup preparation script that performs the following tasks:
   • makes sure that read-write operations do not occur inside the guest system on saved folders and files (Windows guest OS only)
   • switches the virtual machine to "snapshot" mode, creates a snapshot of the state of the virtual machine and makes it available to the application using VCB
   • mounts a snapshot of the virtual machine from the SAN to the proxy server
2. A virtual machine snapshot is backed up at the image level, or at the level of files and folders of the guest system (full, differential, or incremental backup).
3. The backup software calls a post-backup script that completes the backup (dismounts snapshots of virtual machines from the proxy server and brings the virtual machine out of snapshot mode).

The VCB tools use the following virtual infrastructure components in the backup process:

In summary, VMware Consolidated Backup is a powerful tool for creating backups of virtual machines and allows you to use standard backup software used in an organization to create archive copies of data.

Backup with Vizioncore esxRanger

esxRanger by Vizioncore, now controlled by Quest Software, is currently one of the most popular solutions for archiving virtual machines on the ESX Server platform. esxRanger does not require any additional agents to be installed on ESX servers and creates archive copies of virtual machines from a single server or a group of servers through integration with the Virtual Center product. The process of creating backups takes place on a single Windows server, from where archive images of virtual systems can be saved to various devices storage in the organization's production environment.

esxRanger has both a GUI and a command line interface, which allows you to use the regular Windows Task Scheduler to run scheduled backup jobs, eliminating the need to write additional scripts. The main window of the esxRanger product is shown below:

By connecting to VMware Virtual Center, with the appropriate permissions, you can select individual data center server virtual machines for backup. The copied images are automatically compressed when archived and decompressed when restored, saving time for system administrators.

esxRanger integrates with VMware Consolidated Backup when used in SANs and allows you to create full or differential copies of virtual machines, as well as individual files and folders in Windows guests. In addition, during the backup process, esxRanger collects various information about backup metrics (such as the time spent on backup and restore), stores it in a database, and allows you to use it to trend the Disaster Recovery strategy. In addition, esxRanger has a policy engine that allows you to build a data archiving strategy based on templates and integrate it with other components of the organization's IT infrastructure, minimizing the load on system administrators.

The backup procedure with esxRanger looks like this:

1. A VM savepoint is created and stored in the database.
2. Using the VMware API, virtual disk files are “unlocked” for reading (they are locked by default) and .REDO files are created that will store changes to virtual disks since the save point.
3. Virtual disk files are compressed.
4. The compressed files are backed up and the .REDO files are applied to the VMDK files of the virtual machines.
5. After the changes are applied, the VMDK files are returned to their original locked state.
6. The system administrator adds comments to archived copies of virtual machines that provide guidance in case the virtual machines fail.

All in all, esxRanger is a convenient, reliable and easy-to-use tool for creating virtual machine backups in Virtual Infrastructure 3, which integrates with VMware Consolidated Backup, which allows it to be used in SANs of companies of any size.

Backing up virtual machines on the Microsoft Virtual Server platform

Unfortunately, Microsoft, the owner and developer of the Virtual Server 2005 server virtualization product, does not provide users with the same powerful backup and recovery tool as VMware Consolidated Backup. At the moment, Microsoft is focusing mainly on the development of built-in next version Windows platforms Server virtualization support based on a hypervisor codenamed Viridian. However, Microsoft is constantly postponing the date of the final release of Windows Virtualization, as well as cutting down on its announced features, so it's hard to say anything definite about the backup capabilities in the upcoming virtualization platform right now. With a fairly high probability, we can say that there will be built-in support for "live" archiving, but it is not clear yet in what form. Today, virtual machines in Virtual Server can be backed up in "two and a half ways", including:

• usage standard means backup operating system images that can be created by agents running inside guest systems, such as Symantec Backup Exec.
• writing specialized scripts that save the state of the virtual machine, copy its data to backup media and start the virtual machine again
• the use of volume shadow copy services (Volume Shadow Service, VSS), support for which has appeared in Virtual Server quite recently and is not yet supported by manufacturers of data backup systems

In order to back up running virtual machines on the Virtual Server platform, you can use its COM interface by writing a script, for example, using Visual Basic scripting (vbs). When creating a backup copy of a virtual machine, you must first transfer it to a saved state (Saved State), then copy its files to a specified location, and then start it again. Below is an example of a vbs script that does these necessary steps to copy a single virtual machine. It can be scheduled to run using the standard Windows Task Scheduler. "backupvm.vbs" author: John Savill "usage: backupvm.vbs Option Explicit On Error Resume Next Dim objFSO, objVirtualServer, objVM, objSaveTask, objVHD" Connection with file system object set objFSO=CreateObject("Scripting.FileSystemObject")" Connecting to Virtual Server set objVirtualServer = CreateObject("VirtualServer.Application")" Finding a virtual machine set objVM = objVirtualServer.FindVirtualMachine(WScript.Arguments(0))" Saving the state of the virtual machine set objSaveTask = objVM.Save" Pause to perform save operation while not objSaveTask.isComplete WScript.Sleep 1000 wend " Copying virtual disks and UNDO disks for each objVHD in objVM.HardDiskConnections If objFSO.FileExists(objVHD.HardDisk.file) Then "Wscript.Echo objVHD.HardDisk.file & " " & WScript.Arguments(1) objFSO.CopyFile objVHD.HardDisk.file, WScript.Arguments (1) End If If objFSO.FileExists(objVHD.undoHardDisk.file) Then "Wscript.Echo objVHD.undoHardDisk.file & " " & WScript.Arguments(1) objFSO.CopyFile objVHD.undoHardDisk.file, WScript.Arguments(1 ) End If Next" Copy vsv and vmc files objFSO.CopyFile objVM.File, WScript.Arguments(1) objFSO.CopyFile objVM.SavedStateFilePath, WScript.Arguments(1) " Starting the virtual machine objVM.Startup

This script must be used as follows:

C: emp>cscript backupvm.vbs

It should be noted that Microsoft does not officially support such a backup process, since the integrity of a virtual machine copied in a saved state may be compromised due to the fact that part of its memory is not saved in this case in the vsv and vhd files.

Using the Volume Shadow Service

Support for VSS services was introduced in the recent release of Virtual Server 2005 R2 SP1. Using Shadow Copy Services in Virtual Server involves creating backup copies of running virtual machines by creating images, which should greatly simplify and speed up the backup and restore procedure. However, it is not enough to software supported VSS for backup, it also needs to support the new Virtual Server VSS Writer Service (VS Writer), support for which, at the moment, has not been found in any of the archiving systems. According to Microsoft, backup tools can use VS Writer to back up and restore virtual machines in the following way: they notify Virtual Server that the backup process has begun, Virtual Server responds by creating a snapshot of the virtual machine, after which the copy process begins. At the moment, the NTBackup utility also does not support this mechanism.

Backing up Xen virtual machines

XenSource, which maintains the Xen open-source project and distributes the XenEnterprise commercial virtualization platform, offers few options for archiving virtual machines on the Xen platform. One of them is shown below using NFS (Network File System) storage devices.

Initial information:

• XenServer host (in the example of the backup procedure, its IP is 192.168.1.10)
• The computer used as the backup storage server (in the example, its IP is 192.168.1.1)
• XenVM virtual machine (in the example, its IP is 192.168.1.12)

Backup procedure:

1. Install the NFS server by adding the following line to the /etc/exports file:
   / *(rw,sync,no_root_squash)
2. On the XenServer host, add the following to the /etc/xen/xmexample1 file:
   kernel /boot/xenkernel
   name="ExampleDomain"

   root=/dev/nfs

   nfs_server = "192.168.1.1"
   nfs_root="/ip=192.168.1.10:192.168.1.1:192.168.1.1:255.255.255.0:::"

3. Save a copy of the /etc/fstab file and add the following lines to it:
   192.168.1.1:rootdevice / nfs rw,hard,intr 1 1
   192.168.1.1:swapdevice swap swap defaults 0 0
   192.168.1.1:usrpartition /usr nfs rw,hard,intr 1 1
   192.168.1.1:varpartition /var nfs rw,hard,intr 1 1
   none /dev/pts devpts gid=5,mode=620 0 0
   none /proc proc defaults 0 0
4. Copy /lib/modules/2.6.16.29-xen from the XenServer host to the backup device
5. Run the following command on the archive copy server:
   #scp 192.168.1.10:/lib/modules/2.2.16.29-xen /lib/modules/
6. To activate the console using udev, run the following commands on the backup server:
   mkdir /tmp/dev
   mount --move /dev /tmp/dev
   sbin/MAKEDEV null console zero
   mount --move /tmp/dev /dev
7. Run the following command to mount the backup device on the Xen host:
   #xm create -c xmexample1
8. Make a backup copy of the xenstore-ls file and copy the contents of the file system (excluding the /proc and /sys directories) to another folder:
   #rsync -a -e ssh --exclude="/proc/*" --exclude="/sys/*" 192.168.1.10:/ /backupdir

Conclusion

Drawing up and implementing a plan for backup and recovery after failures (Disaster Recover Plan) of the most important servers and workstations of the organization is a necessary part of its activities. Virtual machines, even larger than physical ones, require a high level of attention to data archiving because there are usually several virtual systems consolidated on a single physical host. Leading virtualization platform vendors are committed to providing powerful and easy-to-use backups, but so far only VMware has succeeded. A backup strategy can be implemented in two ways: one of the easiest ways is to do it as part of a standard backup strategy for a company's IT infrastructure, by installing backup agents and imaging in guests. Another, more convenient and faster way is to use built-in platform tools such as VMware Consolidated Backup or scripting by system administrators. In any case, it must never be forgotten that equipment failure or other force majeure should not significantly affect the company's critical business.

There is an excellent free script for backing up virtual machines on a VMWare ESXi server, and it works on free versions of ESXi 4 and 5 without installing any additional VMA gimmicks, etc. The only problem is that the instructions there are not entirely accurate, so I fiddled with this script for a long time so that it would still work in automatic mode ...

I will not describe in detail how to connect to ESXi via SSH, I will only describe the setup steps with which everything worked for me.

First, download the script from the link above and upload it to the server, you need to upload it directly in the archive! The easiest way to do this is through the vSphere Client. I have two disks on the server - machines work on one, and all sorts of iso-images and backups themselves lie on the other. The disks are called datastore1 and datastore2 respectively. All backups, script and configs are in the backup folder. Also note that the names of files and folders are case sensitive, so if the folder is called backup, and you write in a script Backup, then it won't work!

1. Upload the archive with the script here /vmfs/volumes/datastore2
2. Next to SSH cd /vmfs/volumes/datastore2- go to the directory with the script
3. Unpacking the script from the archive tar -zxvf archive_filename.tar.gz
4. Through vSphere, rename the unpacked folder to something simpler, for example, just backup
5. Now let's go to this folder - cd backup
6. Create a folder inside it to store individual configs mkdir BackupConfig
7. Now in BackupConfig drop the necessary individual configs for machines, if they are not needed and all machines need to be backed up with the same settings, you can leave it empty
8. Correct the variables in the configuration file through the vi editor, the main thing is the backup paths, i.e. Change the first line to this: VM_BACKUP_VOLUME=/vmfs/volumes/datastore2/backup, well, then see for yourself what else you need - vi ghettoVCB.conf
9. Create script StartBackup.sh(2 lines) - vi StartBackup.sh
   2nd line, where the call of the script itself, you can remake for yourself
   cd /vmfs/volumes/datastore2/backup
   ./ghettoVCB.sh -a -g ./ghettoVCB.conf -c BackupConfig -l ghettoVCB.log
10. Run chmod +x ghettoVCB.sh
11. Run chmod +x StartBackup.sh
    

Stage 1 completed! Now if you run StartBackup.sh, the backup will start. For the duration of debugging, you can change the 2nd line to something like this ./ghettoVCB.sh -a -g ./ghettoVCB.conf -c BackupConfig -l ghettoVCB.log -d dryrun- this will allow you to run the script and track the progress without copying the disks. To backup more efficiently and quickly, I recommend setting the disk type in the settings thin.

Configuring Cron (to automatically run a script)

1. Give permission to write to a file chmod +w
2. Add a line through vi to /var/spool/cron/crontabs/root
   15 0 */3 * * /vmfs/volumes/datastore2/backup/StartBackup.sh
   Launches at 00:15 at night every three days. My time zone is +4 Moscow, i.е. actually the script is run at 4:15 am, this will be visible by the date the log was modified through vSphere. Of course, you can choose another time and frequency.
   
3. Now you need to run two commands to restart cron
   kill $(cat /var/run/crond.pid)
   crond
4. Add with vi 3 lines to the very end of the file /etc/rc.local
   This is necessary because after rebooting the server, the contents of the file from the 2nd point with the launch of our script will be restored to the previous state, so in rc.local we indicate that after rebooting, the following commands must be executed - stopping cron, adding a line to automatically run the script and starting cron .
   /bin/kill $(cat /var/run/crond.pid)
   /bin/echo "15 0 */3 * * /vmfs/volumes/datastore2/backup/StartBackup.sh" >> /var/spool/cron/crontabs/root
   crond
5. Now let's run the command /sbin/auto-backup.sh to make sure all our changes are saved.

A little explanation - why you need to create a script StartBackup.sh, and not just take and put its contents into /var/spool/cron/crontabs/root? There is some limit on the size of this file and some of the lines in it simply will not work, although you can try to do it this way, at first it worked for me, but then, apparently, some patches came out and stopped. Moreover, it's just more convenient - if you need to change the backup schedule, then you just edit the file StartBackup.sh and there is no need to dance with a tambourine around cron with its restart and making the same changes to /etc/rc.local.

PS: Time passes, everything changes, the script itself changes, ESXi5 has already been released, so somewhere, something may no longer work 🙂

Appendix: Cron Syntax

The cron command looks like this:

1 2 3 4 5 /vmfs/volumes/datastore2/backup/StartBackup.sh

Where,
1: Minutes (0-59)
2: Clock (0-23)
3: Days (0-31)
4: Months (0-12 )
5: Day of the week (0-7)

A few examples:

1. Run at 5 minutes past midnight, every day
   5 0 * * * /vmfs/volumes/datastore2/backup/StartBackup.sh
2. Launch at 2:15 every first day of the month
   15 14 1 * * /vmfs/volumes/datastore2/backup/StartBackup.sh
3. Start at 22:00 every working day
   0 22 * ​​* 1-5 /vmfs/volumes/datastore2/backup/StartBackup.sh
4. Runs at 23 minutes after midnight and every two hours thereafter (2:23, 4:23… etc.), every third day
   23 0-23/2 * * */3 /vmfs/volumes/datastore2/backup/StartBackup.sh

Free backup (backup) of virtual machines based on VMware ESXi

For VMware ESXi question virtual machine backup is particularly acute. Additional free software is inconvenient to use due to limited functionality. Therefore our backup will be based on a free script - ghettoVCB. This is the best version of existing scripts, although it has such a funny name and the whole project as a whole - www.virtuallyghetto.com, author William Lam. Its algorithm is to create a snapshot and clone a VM.

To set up a full-fledged backup scheme, we need:

• NFS server for storing files;
• connection by SSH to ESXi;
• script ghettoVCB.sh is added to the ESXi server (to the root or folder of the future backup). This is done through SFTP in any way convenient for you, for example, FileZilla;
• give the rights to execute the copied script;

Now let's take a closer look at each of the points. To increase the speed and fault tolerance of the file server/backup server, it is better to use RAID10. Preferred in this case are Linux OS (Debian, Ubuntu, "convenient for you") and the file system XFS, because in this configuration, the write speed (the main priority for a quick backup) will be higher.

We already have it, but you can also do everything in vSphere client: Configuration > Software > Security Profile > Properties… > Remote Tech Support (SSH) > Options… > Start or Stop.

Let's go to the script configuration ghettoVCB.sh, the main parameters that we need:

VM_BACKUP_VOLUME - path to the backup folder, in my case /vmfs/volumes/datastore1/backup
DISK_BACKUP_FORMAT - disk format, thin is best for backups
VM_BACKUP_ROTATION_COUNT - the number of stored backups (for each virtual machine), I have 3
ADAPTER_FORMAT - adapter type, in my case - lsilogic

The remaining parameters are responsible for copying files over the network and email notifications. More configuration options are described on the developer's website.!

If it is necessary to copy not all virtual machines, then a file with a list of VMs included in the backup is created. We create such a file in vi:

• go to the folder with the script - cd /ghettovcb or backup
• vi vmlist
• press "a" enter the names of the VM (each name on a new line)
• press "esc" and to save the changes - ": wq" (without saving ": q")

Let's run the script:

• ./ghettovcb.sh -a -l ./log.txt - start copying all machines, write log file in the same directory
• ./ghettovcb.sh -f ./vmlist -l ./log.txt - start copying the machines specified in the vmlist file, logs are saved in the same directory
• ./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt - similar, but using the .conf file

The correct execution of the script will be signaled by a line with the inscription: “###### Final status: All VMs backed up OK! ######". If this is not the case, check the logs, command syntax and file paths.

In order to add a line to run according to a schedule (in cron), you need to edit the file "/etc/rc.local.d/local.sh" by doing the following:

• go to /etc/rc.local.d/local.sh directory
• chmod u+w local.sh
• open the file with an editor - vi local.sh
• enable editing with "i" or "insert" keys
• add the following before the exit0 line:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo 0 20 * * * /vmfs/volumes/datastore/script/ghettoVCB.sh -a -l /vmfs/volumes/backup/log/log.txt >> /var/spool/cron/crontabs/root
/bin/crond

• at the same time, we indicate the schedule (time is indicated in UTC, i.e. for MSK -3 hours), i.e. "00 20 * * * "
• press "esc" and save - "Shift +:" and "wq"
• at the end we execute chmod u-w local.sh

Thus, at 23:00 Moscow time, virtual machine files will be backed up. In our case, 3 copies will remain.

Configuring backup for ESXi via ghettoVCB.sh completed.

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 this writing, the latest available version of MKSBackup 1.0.4 is dated 01/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 online mode create backup copies of running virtual machines. A backup copy of a VM is created by creating its snapshot (snapshot).

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

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

Naturally, the convenience and manageability of the MKSBackup-based VMWare virtual machine backup solution is lower than that of commercial products, but is largely compensated by its free, easy setup and deployment speed.

Installing the MKSBackup backup script

Configuring virtual machine backup options

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

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

In this section, you can set notification parameters for e-mail. We are not interested, so we leave

Next section. This section is a backup task and describes the various options that make it possible to run a backup of virtual machines in 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 where the virtual machines are running

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

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

password– user password

local– local directory where the backup script and its configuration are stored

global_conf– file with ghettoVCB script settings

vm_list– list of virtual machines for which you need to create a backup copy. If you want 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– parameter allows you to specify the type of operation to be performed. It could be

• backup - perform a simple backup (you don't need to specify a destination)
• copy - back up and copy the resulting files to the specified directory
• move - back up and move the resulting files to the specified directory

Let's dwell on the move option, as a more optimal one. 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 as it is, since we will set the frequency of starting backups through the Windows scheduler).

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

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

scp_bin– path to 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 where 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 stored (in our example, the last 3 backups will be stored)

It remains to save the host key in the local ssh cache using the plink utility (also included in the Putty distribution). For example, like this:

PLINK.EXE [email protected] ls/

Running 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 mksbackup.ini settings file, backup- means that you need to start the backup, at the end the name of the task from the file is indicated mksbackup.ini(in our example, the VMWARE_FROM_WINDOWS task).

If everything is configured correctly, the utility will start displaying detailed information about the backup process in the console (the backup process is quite long, so you should not expect it to complete 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 proceed to automate the process of creating backups. To do this, we will create a new Windows Scheduler task.

Let's create a task named "Backup ESXi" that 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 must be run with administrator rights ("Run with highest privileges" option).

Note. If the task will be run on behalf of another account (not the one under which the 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 under the new account.

Disadvantages of this method of backing up virtual machines:

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

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

1. Backup VMware ESXi virtual machines

Introduction

This document presents various methods and strategies for backing up VMware ESXi using vSphere and Bacula Enterprise Edition versions 8.0, 8.2, and 8.4. The Bacula Enterprise Edition plug-in for backing up VMware virtual machines with vSphere gives you the ability to restore the original state of a virtual machine, while file backup at the guest VM level simplifies the protection of mission-critical application data. VMware backup uses a technology called Changed Block Tracking (CBT) to ensure that only those blocks that have changed since the original full and/or last block are sent to the current incremental or differential backup stream in order to create more efficient backups and reduce network load. incremental and/or differential backup.

Key Features of VMware Backup

• Online backup via VADP
• Create VSS snapshots inside guest OS to pause applications
• Full, differential and incremental VM backup at the image level
• Restoring a full VM image
• Restoring vmdk files to an alternative directory
• Access to VMware storage, both over TCP/IP and SAN (FC/ISCSI)

Overview of VMware Backup

The current version of the plugin for VMware vSphere supports vSphere versions 6.0, 5.5, 5.1, 5.0, 4.1 (minimum 7 virtual hardware version). This document provides software solutions Bacula Enterprise Edition 8.0 and later versions, which are not applicable to earlier versions of the software.

VMware Backup Glossary

This document uses the following terms related to how to back up VMware:

• CBT– technology for tracking changed blocks.
• Datastore is the name used by VMware to refer to data stores.
• vSphere- is a VMware technology for OS virtualization and cloud computing.
• VDDK is a set of C/C++ libraries that allows you to create and access VMware virtual disks. The VDDK is used in parallel with the vSphere API to write backup and restore software or similar applications.
• When using a VMware ESXi server, virtual machine files are placed on large external memory.
• NBD– network block device. vSphere allows you to access files hosted in the Datastore using direct file access technology, access over NBD, NBD over SSL, or SAN. When accessing files via NBD, the network protocol is TCP/IP.
• SAN. vSphere allows you to access files in the data store using direct access technology. SAN can use Fiber Chanel network (backup technology without loading local Lan networks free backup) or iSCSI over TCP/IP technology.
• VMware ESX and VMware ESXi is a hypervisor architecture installed on a server without an operating system. The smaller ESXi codebase means a smaller attack surface and a smaller patch code size, which improves system reliability and security.
• VCB- VM Consolidated Backup Method An older VMware API that is generally no longer used. The VMware plugin does not use VCB technology.
• VADP– the next generation of VMware data protection infrastructure implemented in vSphere 4.0, allowing backup software to create centralized, efficient backups of VMware off host machines and without downloading local network.
• .vmdk- file format used for virtual appliances developed for VMware products.
• .bvmdk- internal file format used by the Bacula Enterprise plugin for handling VMware sparse blocks and differential/incremental binary backups. After conversion with the vddk tool, the file becomes a raw image of the original disk, which can be converted to vmdk format using the qemu-img utility.
• ESX 3.x uses version 4 of the virtual hardware, vSphere 4.x uses version 7, and vSphere 5 uses version 8.
• The fingerprint can be generated from the ESXi host
  openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt \-noout -fingerprint | cut -d ‘=’ -f 2
• guestfish- shell and command line tool for viewing and modifying the VM file system.
• VM (or VM) – an abbreviation for the term "virtual machine".
• vSphere is a server virtualization platform with the ability to consistently manage virtual data centers.
• SELinux- Security-Enhanced Linux (SELinux, Security-Enhanced Linux) is a Linux kernel security module that provides a mechanism to support access control security policies, including Authoritative Access Control (MAC).

1.1 How to backup VMware in guest OS

1.1.1 Installing the Bacula Client in each guest OS

The first strategy does not involve the use of a plugin Bacula Enterprise Edition for vSphere. Instead, the Bacula Enterprise File Daemon is installed on each VM as if the VMs were normal physical servers. Tasks are used to optimize I/O flows on VMware ESX/ESXi servers. Schedule, priority and Maximum Concurrent Jobs to distribute backup tasks in the backup window. Since all servers use the same set of disks, performing all backup tasks at the same time, it is possible to bottleneck the disk/network subsystem.

Figure 1: Installing bacula-fd on each guest VM

Installing the Bacula Enterprise File Daemon on each VM allows you to manage virtual servers as if they were physical servers, as well as use all the features of the Bacula Enterprise software, such as:

• Quick recovery of individual files
• Checksum calculation for individual files to detect viruses and spyware
• Checking the task
• File/directory exclusion (such as swap files and temporary files)
• File-level compression, etc.

1.1.2 Backing up VMware with the Bacula Enterprise Edition plug-in for vSphere

In the case of a strategy for creating a backup of a VMware virtual machine image, the plugin Bacula Enterprise Edition for vSphere saves Client disks as raw images in a VMware/vSphere context. In order to implement this strategy, it is not necessary to install the Bacula File daemon on every guest machine.

The Bacula plugin for vSphere will communicate with the VMware ESXi host to read and store the contents of the VM disks via NBD or SAN. With direct access to the image vmdk, saved in data store, Bacula software does not have to run through the Client's file system to open/read/close files. Accordingly, the software will consume less ESXi infrastructure resources than if VMware backups were created on each guest machine. At the same time, Bacula will also read and store useless data such as swap files and temporary internet files.

Figure 2: Creating a TCP backup using NBD

If the vSphere backup plugin uses the NBD data transport method, the data is streamed to the backup storage server through the ESXi system's VMkernel port.

The Bacula Enterprise plugin for vSphere can also use the SAN infrastructure to reduce the load on ESXi servers. However, despite consuming fewer resources on the ESXi server, data will still need to be read from your disks, which can lead to conflicts when trying to send/receive data at the same time.

When using block differential methods, such as those used by the vSphere plugin, all incremental backups must be available for recovery. If at least one backup task is missing at the time of restoration, the Bacula plugin will not be able to recreate the correct image. The use of differential backups allows you to reduce the number of tasks required for recovery, thereby reducing the risk of possible data loss. To prevent the loss of important tasks for creating incremental backups, retention periods Volume retention must be large enough to recover all the data.

1.1.3 Comparison of VMware backup strategies

Table 1. Comparison of backup strategies

The procedure for restoring individual files from a backup of VMware machines created using the plugin for vSphere is described in section 2 on page 27.

1.2 Installation

Documentation detailing the installation process is available upon request.

1.2.1 Configuration

The File Daemon's Plugin Directory parameter, stored in /opt/bacula/etc/bacula-fd.conf, must point to where the plugin is installed vsphere-fd.so. As a rule, by default the Bacula plugin is installed in the directory: /opt/bacula/plugins

The File daemon must have direct access to the vSphere network or access through the SAN. You can check the connection using the telnet program. vSphere network access to ESX or the vCenter server must be configured in /opt/bacula/etc/vsphere_global.conf.

Figure 3. Creating a backup over a SAN

Parameter	Required	Default value	Description
General settings section global
keep_generation	Not	100	Max. number of backups between two full backups.
profile_all_vm	Not	vsphere_all_vm.profile	The name of the internal file used to store VM profile information.
root_directory	Not	/opt/bacula/working/vsphere	The root directory of the vSphere plugin.
vddk_path	Not	/opt/bacula/bin/vddk
Settings section vsphere
username	Yes		The username that is allowed to connect to vSphere.
password	Yes		The password for the username that is allowed to connect to vSphere.
hpassword	Not		Hidden password for the username that is allowed to connect to vSphere.
timeout	Not	60	Timeout to connect to the vSphere server in seconds.
thumbprint	Yes		SSL thumbprint of the vSphere server certificate.
server	Yes		The vSphere ESXi server used to create the backup.
url	Yes		The address of the vSphere ESXi or vCenter server used to make the call using SOAP.
Default_datastore	Not	datastore1	The default recovery storage.
default_restore_host	Not		ESX server used by default for recovery if multiple servers are available in vCenter.
default_ovf	Not		The default OVF description used in case the current OVF description cannot be loaded into VMWare .
root_directory	Not	/opt/bacula/working/vsphere	The directory used to store the plugin's internal data.
datastore_minimum_space	Not		The minimum size to store data in the data store. For example, 5GB.
datastore_allow_overprovisioning	Not	Yes	Allows you to restore a VM using the Over Provisioning feature. If the parameter is set to " Not”, when restoring, you must ensure that the size of all disks matches the size of the Datastore.
datastore_refresh_interval	Not	600	The interval used to update data storage statistics in the Datastore.

Table 2. Configuring a vSphere connection using the vsphere_global.conf file

The fingerprint can be obtained using the console screen by pressing F2 and then logging in. The Thumbprint will appear in the window View Support Information under SSL Thumbprint (SHA1). Or you can connect via ssh:

Using multiple vSphere servers

You can specify multiple vsphere servers in the vsphere_global.conf file. When using this function, you need to set the server=xxx parameter in the plugin's command line. It is also mandatory to specify an alternate directory in case your VM has the same MoRef value.

Take into account the fact that the default section is required in the vsphere_global.conf file.

Parameter	Required	Default value	Description		Example
host	Not		Guest VM name	host=srv1
host_include	Not		Guest VM image to include	host_include=srv3
host_exclude	Not		Guest VM image to exclude	host_exclude=srv
disk_exclude	Not		List of drives to be excluded	disk_exclude=0,2,4
keep_cbt	Not		Don't try to activate CBT	keep_cbt
quiesce_host	Yes		Stop the guest VM before taking a snapshot (try, yes, no)	quiesce_host=no
server	Not		Specify vsphere server	server=vsrv2
debug	Not		Allow Debugging	debug
abort_on_error	Not		Stop a task after an error is detected
update_timeout	Not		Change initial update timeout

Table 3. vSphere plugin command parameters

Take into account the fact that commands host_include and host_exclude are a Java regular expression.

Hide vSphere password

Starting from plugin version 8.0.3 you can hide the vSphere password in the file vsphere_global.conf. Field hidden password called hpassword. To generate a hidden password, you can use the command @encode. Take into account the fact that if the string you want to encrypt contains the expression "=", when writing the command you must use the format string= keyword.

Testing the vSphere Configuration

To test the plugin for vSphere, you can use the following command (as root user):

When using the update command vsphere-ctl a list of all VMs that are defined on the ESXi server should appear. If this does not happen, please check that your credentials are correctly configured in the file vsphere_global.conf.

Team list allows you to display information found on ESX hosts and data stores.

Job function example

When starting tasks to create an incremental/differential backup, it is necessary to set the parameter Accurate.

Examples of using the FileSet function

This section presents various options for using the function. FileSet. Please note that the vsphere plugin is not compatible with the FileSet feature for sparse files.

Figure 4. Backup of the VMware guest1 virtual machine on the ESXi server

Testing the FileSet Function

You can use the command estimate to test the FileSet function.

Implementing VMware Block-Level Incremental Backups

Take into account the fact that the CBT utility is not supported by 6th and earlier versions of virtual hardware, or when the virtual disk is connected to a shared virtual SCSI bus.

In order for CBT to be able to determine the changed sectors of the disk since the last ID change, the following conditions must be met:

• Host version ESX/ESXi 4.0 or higher.
• 7 version (and higher) of the VM hardware that owns the disks whose changes are to be monitored.
• I/O operations must be performed through the ESX/ESXi storage element block. NFS is supported as RDM drives in virtual compatibility mode, but not RDM drives in physical compatibility mode. It also uses the VMFS file system with support for SAN, iSCSI, or local disk.
• For the VM, you need to activate the CBT utility (see description below).
• The VM storage should not (permanently or non-permanently) be represented by an independent disk, that is, one that will not be affected by snapshots.

In order for the CBT utility to be able to determine disk sectors using a full backup, you will need to meet the following conditions:

• The virtual disk must be located on a VMFS volume supported by SAN, iSCSI, or a local disk.
• The VM must have zero snapshots (0) when CBT is activated to implement the so-called. clean launch.

When using "Thick Provisioned Eager Zeroed" disks, VMWare CBT will show all blocks as used during the full backup. For VMs that do not support CBT, the plugin for vSphere will always perform a full backup of virtual disks. To check if the CBT utility has been activated for virtual disk, open the vSphere client, select command powered-offvirtual machine without snapshots(turn off the VM without creating snapshots).

• Right-click on the VM and select edit settings Edit Settings.
• Go to the tab Options.
• Click on tab General under the tab Advanced, and then by item Configuration Parameters. The parameter configuration dialog will open.
• Click on an item Add Row.
• Add a parameter ctkEnabled and give it a value true.
• Click on Add Row, add parameter scsi0:0.ctkEnabled and give it a value true.

Attention: line scsi0:0 in parameter scsi0:0.ctkEnabled indicates the SCSI device assigned to hard drive added to the VM. Each HDD, added to the VM, gets its SCSI device, referred to as scsi0:0, scsi0:1, or scsi1:1. During the creation of the first full VMware backup, the vSphere plugin will try to automatically activate the CBT utility when the VM is turned off. To disable this feature, enter the command keep_cbt on the plugin command line.

Problems when using CBT

If you are reverting to a snapshot earlier than the last incremental backup, you must create a full backup of the VM before reusing incremental backups. This issue has been resolved in vSphere 4.1 and vSphere 4.0 Update 3. Instead of possibly providing incomplete data, a change identification number obtained before reverting to a previous snapshot is now correctly treated as invalid (http://kb.vmware.com/kb/1021607).

Compress backup size by resetting CBT

Once a block is marked as "used" by VMWare CBT, the system will continuously back up that particular block when performing a full backup, even if that block is marked as "free" by the guest OS. After some time, a situation may arise in which a large full VMware backup will be created with a small amount of disk space used.

By re-creating the disc with VMotion, you can reset the CBT table to mark only the actually used blocks. To perform this operation, you must first clear the disk of the guest VM by writing "zero" blocks to cover all the free space. Take into account the fact that the operation will use resources, so it must be performed outside business hours.

On Windows, the procedure can be performed using the utility Microsoft delete, available at http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx

On Linux, you can use the built-in tool dd. Take into account the fact that you can limit dd to not completely fill up the entire disk.

Upon completion of the operation, you must stop the guest VM. This can be done via the ESXi shell interface as follows:

Information about the location of the disk and the configuration file can be found as follows:

After that, zero blocks of VMDK files must be cleared through the ESXi shell interface as follows:

Upon completion of the operation, you must deactivate CBT for the guest drives that you want to compress. You can also edit them through the vSphere management console, or IN AND.

Then you need to enable/disable the guest VM in order to apply the changes to the CBT utility. You can wait until the host is fully up and running.

Now you should not see files like “*-ctk.vmdk” and you can re-enable CBT in the host config file and start your guest VM.

Files like “*ctk.vmdk” will be recreated. Team estimate bacula plugin should display files bvmdk smaller size.

Since this procedure is quite complicated, we recommend that you try it out through the sandbox first. If the ESXi SSH interface is enabled, then you can script anything.

Determination of unavailability of CBT

If the CBT (Changed Block Tracking) utility is not available for disk, the file vsphere-ctl*log may contain the following error:

When this error occurs, the vSphere plugin will automatically create a full disk image backup. To enable CBT for a specific disc, see section 1.2.1 on page 14.

Activation of access through SAN

You may have difficulty configuring SAN access on the host. VixDiskLib VMWare library compiled for Redhat 5 64bit version. On later OSes like Ubuntu or Redhat 6, you need to compile and install the 1.95.7 library. Please note that the Bacula Enterprise plugin for vSphere contains this library in the package bacula-enterprise-vixdisk.

In order to use the SAN data movement technology, the backup server on which the vsphere plugin is installed must have access to all LUNs exported to the ESX server. Packages like multipathd, will not have problems with devices with different connections. If your drives are visible as /dev/sda, /dev/sdb, … the vSphere plugin will open each drive to get a UUID and compare it to the one provided by the ESX server. For example, when using iSCSI, the lsscsi command will list the drives as follows:

You can verify that the method of transferring data across the SAN is being used by using the debug function debug on the plugin command line and make sure that the file vddk trace contained in the following location:

If the SAN data transfer mode is not available, the plugin for vSphere will automatically switch to the nbd data transfer mode.

Removing old snapshots

If the VMware system contains snapshots that were not automatically removed by the vSphere plugin, you can clean up the system using the vSphere Plugin version 6.6.3 and higher using the following commands.

• Removing old snapshots and previous failed snapshots

vsphere-ctl clean-snapshot --snapshot myhost

• Deleting old snapshots with a name starting with a string

vsphere-ctl clean-snapshot --snapshot-base pluginTest myhost

• Deleting all snapshots with all derivatives; possibly faster)

vsphere-ctl clean-snapshot --snapshot --snapshot-delete-child myhost

When starting a new backup task, the vSphere plugin will automatically check for problems with the previous task and delete any old snapshots if necessary.

Debug trace

The plugin for vSphere uses various technologies and third-party libraries. As a result, the system makes extensive use of the trace function. The user will be able to use the help of the following files:

Table 4. Tracing methods used by the plugin for vSphere

To extract a bvmdk file without converting it with vddk during restore, you need to set the FileDaemon debug level to 1000. During restore, Bacula may generate incorrect file size reports.

Working files

The plugin for vSphere creates special files in working directory. These files are required for the VMWare CBT utility to work. To clear the vSphere plugin working directory, you can use the command vsphere-ctl:

This will remove the 30-day files and directories. This period should correspond at least to the period for creating a full backup, plus a few days for security. During the backup, if the plugin can't find working files during the last backup, the vSphere plugin will create a full backup of all disks.

Disk exception

To exclude a specific disk from the procedure, you can activate independent mode through the vSphere console, or use the function disk_exclude(see table 1.2.1 on page 11). To find diskid in order to use it in a function disk_exclude, you can use the command estimate listing. 0.bvmdk is the diskid 0 image.

1.3 VMware vSphere backup and restore procedures

1.3.1 Backup

Figure 5. Excluding a disk from a backup

1.3.2 Recovery

Bacula Enterprise software allows you to restore any file (bvmdk, ovf, ...) on local drives. After that you can mount the image locally using the VMWare tool vmware mount tool or qemu-nbd and perform a file-level restore. When using the parameter where=/path/to/dir in the restore function, the plugin will automatically restore the selected files to the specified location.

It is also possible to copy the raw image to any device, or mount it and restore the files directly.

Recovery on a new guest VM

If you start the recovery procedure of your VM with the where=/ option, and select all files in the directory vm, the plugin for vSphere will try to restore your disks to a new VM created during restore with the existing attributes (disks, controller, CPU type, ...).

Enhanced SAN transfer mode is currently not supported for recovery. The plugin for vSphere uses NBD data transfer.

The ESX host and storage that will be used to restore the guest VM will be automatically determined. However, you can change the default location by changing the plugin restore options via the bconsole menu:

Or you can use the BWeb interface (see Figure 6)

Figure 6: Selecting a datastore, ESXi server, or hostname at the time of recovery

Take into account the fact that you need to configure at least one VM on your ESX server in order to automatically recover a VM with Bacula. We plan to remove this limitation in the future.

Starting with Bacula Enterprise 6.2.4, the plugin for vSphere supports automatic network topology creation. Thus, if your ESX host does not provide the correct vSwitch configuration for the VM, the Bacula plugin will have to recreate all network settings during recovery.

Starting with Bacula Enterprise 8.2.1, the plugin for vSphere can check for available memory in the Datastore during restore. The user can prohibit the increase in the spare area and reserve the minimum amount of memory in storage. These two options can be configured in the file vsphere_global.conf and can be overwritten from the recovery menu.

server=192.168.0.68

url = https://192.168.0.68/sdk

datastore_minimum_space = 64MB

datastore_refresh_interval = 10

datastore_allow_overprovisioning = false

The "unallocated" amount of memory returned by the vSphere server is not always accurate. The refresh rate can be changed using the method described in the manual at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008367

Sometimes Bacula software fails to load the OVF file describing the guest VM to the vSphere or vCenter server. In particular, this is due to certain VMware restrictions, such as “you cannot use an OVF containing references to a mounted CDROM”… The plugin for vSphere uses workarounds to resolve similar problems but it doesn't solve all the problems. If you are having similar difficulties, you can use the parameter default_ovf in file vsphere_global.conf. As a rule, you need to configure the parameter default_ovf so that it references an existing simple OVF template. The recovery process will use this template automatically and you will need to configure the VM later with values ​​such as CPU number, RAM size, etc.

On Windows, in some cases, after the restore process actually completes, you may need to perform additional tasks. For example, if the restored system will not boot, you may need to use the Windows recovery to debug the system. For servers with Active Directory installed, you may need to review Microsoft's guides to get your AD databases consistent and in sync with other AD servers. If the installation involves dynamic disks, you must import them into a freshly restored system after a reboot. You can import using the Disk Manager or using the "diskpart" function by selecting one of the dynamic disks and entering the "import" command.

Recovery without plugin for vSphere

If you are trying to recover disks in a File Daemon that does not have the Bacula Enterprise plugin for vSphere installed, you will need to convert the bvmdk files to raw files using the vddk command from the command line:

Format bvmdk used by the vSphere Plugin to ensure data integrity and efficient handling of sparse information by the CBT utility.

1.4 Suspending a guest VM

To correctly suspend a guest VM, you need to install and update the VMware Tools on the Linux/Windows Virtual Machine VM.

Plugin team quiesce_host=Try/yes/no allows you to control the procedure for stopping guest VMs using vSphere before capturing a snapshot. The default value is try. In this mode, the plugin will try to stop the guest VM when taking a snapshot, and if the snapshot fails, the plugin will try to re-create the snapshot without stopping the guest VM. The first attempt will be logged in the task log as an error.

For more information about the specific error message, see the vSphere console log.

Warning message from ESXi: the guest OS has reported an error during quescing. Error code was: 2 the error message was: custom quiesce script failed. (Error message from ESXi: The guest OS reported an error while shutting down. Error code 2: Stop script error)

An error occurred while saving the snapshot: Failed to quit the virtual machine (An error occurred while saving the snapshot: Unable to stop the VM)

1.4.1 Linux

By creating a special script in /usr/sbin/pre-freeze-script, you will be able to stop your system automatically when you create a snapshot with vSphere. vSphere will try to execute the script /usr/sbin/post-thaw-script in case it will be present in the guest OS.

1.4.2 Windows VSS

The plugin enhances Windows security by creating VSS-based snapshots before backing up to stop VSS-activated applications.

Pre-freeze and post-thaw scripts for VSS. Starting with ESX/ESXi 3.5 U2 and later, VMware Tools first searches alphabetically for scripts in C:/Program Files/VMware/VMware Tools/backupScripts.d, calling them with an argument freeze, and then in reverse alphabetical order calls with an argument thaw(or freezeFail in the event of an unsuccessful stop).

1.5 Supported platforms

The plugin for VSphere supports the following products on the VMware platform:

• ESX/ESXi versions: 6.0, 5.5, 5.1, 5.0, 4.1

We are currently testing the correct operation of the plugin for VSphere with the following VMware products platform:

• vCenter Server versions 6.0, 5.5, 5.1, 5.0, 4.1 managing ESX/ESXi 4.1 and later
• VirtualCenter version 2.5 managing ESX/ESXi 4.1

The VSphere plugin uses the vStorage API to manipulate files and snapshots. This extension requires a valid non-free VMWare license.

• The VSphere plugin has been tested (and supported) on the following Linux based platforms: RHEL 6, 7 (Red Hat Enterprise Linux) 64bitSLES 11 (SUSE Linux Enterprise Server) 64bit

1.6 Restrictions

Plugins may not be compatible with the default VirtualFull tasks. Please contact Bacula Systems Support to ensure that you are using the optimal settings.

2 Overview of the VMware Single File Recovery Procedure

This section provides information on how to use the single file recovery function. VMware via Bacula Enterprise Edition and plugin for vSphere.

Brief Description of Functions


Single file recovery tool Bacula Enterprise Edition allows you to use the following functions:

• Console interface
• Bweb Management Suite Interface
• Support for full/differential/incremental backups
• Support Windows 2003 to 2012
• Linux support (ext3, ext4, btrfs, lvm, xfs)
• ESX 5.x and 6 support

2.1 Installation

Documentation detailing the installation procedure is available upon request.

2.2 Recovery scripts

This feature allows you to quickly find and restore specific files from a directory in a VMware environment.

2.2.1 Through the text console interface

Single file recovery plugin ( VMware single file restore) allows you to use a simple software console that provides access to files inside the VM. The process of restoring a single file begins with mounting VM backups:

Choose the right client first

Then, select the task you want to restore.

Then select the desired VM.

Now select the location of the guest filesystem (locally or via SMB)

At this stage, the VM file system is mounted locally (in the example above, the files are available at /opt/bacula/working/vmware/5. As is the case with the standard file system, you can find directories and copy files (via cp, scp, ftp) from another terminal session using Unix “root” and “bacula” accounts. If you need to use a different Unix account to work with files, use the function -o allow_other” when running the script mount-vmware.

To clear the session, simply press "Enter" in the terminal session in which the script was run. mount-vmware.

Starting with Bacula Enterprise 8.4.8, you can limit the Job list with the following command lines:

• -s= limit the list of tasks to the last XXX days
• -l= limit task list to last entered numbers
• -f= specify advanced filter based on task name and/or FileSet name

2.2.2 Restoring VMware from the interface Web Management Suite

Single file recovery function VMware single file restore can be implemented using Web Management Suite. This utility is a recovery wizard that allows you to easily and easily restore files from a guest VM. First you need to select the client on which the task of creating a backup using vSphere was performed (see Figure 7).

Figure 7. Client selection

After the Client is selected, the administrator must select the Job (Restore Point) to restore. (see figure 8 on another page). If the selected Job is a valid vSphere task, i.e. can be executed, the third step will display the list of virtual machines included in the FileSet (see Figure 9 on the next page).

At this point, Bacula should create a virtual image of the selected VM. Need to recover a couple of small files from each Job that make up the selected restore point Restore Point. After completing the Bacula software procedure, you need to mount the disk of the selected VM in the system. These steps are usually completed quickly, however, the time taken depends largely on the configuration being used. Indexes are created and maintained during this phase to speed up subsequent restore requests.

After the disk is mounted, the files of the selected VM will be displayed in the file manager. In it you will be able to select files or directories for recovery. (see figure 10 on page 31). The administrator can then create a ZIP or TAR archive. The archive will be created automatically and saved to / opt/bacula/working. A link will be created to securely download the archive via HTTP. The administrator will be able to provide this link to the end user.

Each time the administrator selects files, he will be able to choose the method of recovering the compressed file in tar or zip format. (see figure 11 on page 32). After recovery, it is important to end the session in order to free up the resources used for recovery.

Figure 8. Selecting a restore point

Figure 9. Selecting a VM

Figure 10. File selection

Figure 11. File access

2.3 Notes

2.3.1 Cache directory

To speed up subsequent single file restore procedures, some files created during a restore session are stored in the cache directory.

After a while, you can delete the cache files. If necessary, they will be recreated.

2.4 Restrictions

• The VMware Single File Recovery feature uses the Bacula BVFS interface to display a list of files and directories. In the case of MySQL; despite MySQL's limitations with indexes on TEXT columns, the procedure does not significantly impact MySQL performance. However, for best results, we recommend using PostgreSQL.