Citrix Hypervisor (previously called XenServer) is a comprehensive virtualization management platform with a variety of capabilities and supported infrastructure types. Citrix Hypervisor is a result of a rebranding of its product formerly known as XenServer.
Bacula Enterprise provides native integration with Citrix Hypervisor via a specific plugin (or ‘Module’; those terms are interchangeable in this context). This level of integration allows Bacula Systems users to perform various XenServer backup and recovery operations on different levels with Citrix Hypervisor no matter the size and complexity of the data center in question. There’s also a lot of room in regards to flexibility and the customizability of the solution, including deployment locations, data types, recovery methods, and so on.
Bacula Enterprise’s integration with XenServer Citrix Hypervisor offers a variety of different features, including:
- Full, Incremental and Differential image-level XenServer backups;
- Online backup capabilities with a snapshot technology for guest VMs;
- Full VM image restoration capabilities;
- Support for the older backup formats and types;
- The ability to perform VSS-based snapshots of guest VMs;
- An option to change the target directory for a VM archive, and much more.
When it comes to actual XenServer VM backup and restore operations, there are a number of different approaches. First of all we’ll work out the way that Bacula and Citrix can operate with guest VMs and which backup strategies work for those.
Bacula client installation on each guest VM
This particular strategy works by installing a Bacula Enterprise File Daemon on every guest VM, treated as if they are normal, physical clients. You will have to manually take advantage of Bacula’s scheduling, prioritizing and parallel job performing capabilities to optimize I/O usage of the Citrix Hypervisor and avoid various hiccups and bottlenecks.
Performing an installation of a Bacula Enterprise File Daemon on a particular VM allows you to manage it like a physical server, allowing for a number of useful Bacula Enterprise features, including:
- Compression on a file level;
- Job verification;
- Backup accuracy;
- Individual file restoration;
- Exclusion of specific files or directories;
- Checksum verification to look for spyware of viruses.
Using Citrix Hypervisor module to create image backups
The image-level strategy allows Bacula’s Citrix Hypervisor module to use the raw disk level to create backups. There is no need to install a Bacula Daemon on each VM for this technique to work, either. The Xen module takes advantage of XenServer’s API to locate and save the contents of each of your VMs using the snapshot technology and the vm-export/vm-import methods.
This method typically saves significant resources since there’s no need for Bacula to “walk” through each and every VM’s filesystem, allowing to ease the workload of a Citrix Hypervisor infrastructure in general. On the other hand, since this XenServer VM backup type saves literally everything on a particular VM, this also includes useless files that you don’t really need in your backup, such as temp files or swap files. However, it’s also an advantage as well, since the VM configuration files are also saved via this method - allowing for much easier VM restoration.
There are four main steps in the basic process of creating a backup of a single VM using XenServer VM backup module:
- Older version deletion;
- New VM snapshot creation and the preparation stage of the backup;
- vm-export command execution and data being saved to a Bacula storage;
- Snapshot deletion as soon as the backup is done.
Both running and halted guest VM states are suitable for performing a backup process. The only snapshots that would be considered old by the system are the ones that fit the specific template – BaculaSnapshot_<UUID>_JobID_<NR>. Those are automatically deleted at early stages of the Xen backup process, so it’s recommended to avoid creating manual snapshots that fit this naming template. Citrix Hypervisor module’s status console would offer you the information about the guest VMs that are currently backed up, the stages of each backup, snapshot activities, which backups were deleted, etc. You can see an example of this information below:
JobId 135: Start Backup JobId 135, Job=xen.2017-12-28_15.52.21_11
JobId 135: Using Device "FileChgr1-Dev1" to write.
JobId 135: Volume "Vol-0002" previously written, moving to end of data. JobId 135: \
xenserver: Start Backup vm: CentOS 7 (fe1ccf3b-1865-3942-c928-d98138397ff1)
JobId 135: xenserver: Old stalled backup snapshots found.
JobId 135: xenserver: Snapshot deleted: 12e387c0-eac5-84b1-8e40-1d0601c9eebf
JobId 135: xenserver: Snapshot created: 03afdf67-4ae3-7b0a-5eb0-2c2520c8580f
JobId 135: xenserver: Snapshot deleted: 03afdf67-4ae3-7b0a-5eb0-2c2520c8580f
JobId 135: xenserver: Backup of vm: CentOS 7 (fe1ccf3b-1865-3942-c928-d98138397ff1)
Every guest VM participating in the process means one more backup file, named as follows:
There’s also a number of parameters that are used to define specific parts and variations of the Xen backup process.
- vm=<name-label> represents a guest VM’s name that you’ll be backing up. All matches with the name-label in the brackets will be backed up. The parameter itself is optional and not required for the entire process to work.
- uuid=<uuid> specifies a UUID of the specific guest VM. UUID is the universally unique identifier – a 128-bit number that identifies information in various systems. The parameter itself is optional and not required for the entire process to work.
- include=<name-label-regex> is a list of guest VM names to backup, expressed via regular syntax. All guest VMs with matching names would be backed up. The parameter itself is optional and not required for the entire process to work.
- exclude=<name-label-regex> is a list of guest VM names to exclude from the backup process, expressed via regular syntax. All matches would be excluded from the backup process entirely. Does not affect either the vm= or the uuid= parameters. The parameter itself is optional and not required for the entire process to work.
- quiesce=<0|1> is about specific guest VMs that you want to be created using the quiesce method. This method is only supported by Windows OS with guest tools installed. The whole backup job is aborted if the guest VM snapshot can’t be created via quiesce method.
It is worth noting that, since all of the specification parameters themselves are optional, the system would proceed to backup all of the available guest VMs if there’s no vm=, uuid=, exclude or include input found beforehand. There’s also a specific parameter called abort_on_error, that orders the entire job to be halted if there’s an error found in the setup process, like the lack of vm= parameters, or any other parameters in the first place.
The restore process as a standalone operation pursues two main targets:
- Restoration to a local directory from an XVA archive file;
- Restoration to a XenServer hypervisor as new or original guest VM.
There are several methods that can be done in regards to the restoration process. For example, here’s a restore to the XenServer method. It requires setting up a “where=/” restore parameter in Bacula. In that case the guest VM archive in question would be restored as a new guest VM via Citrix Hypervisor, or restored as the original form of this VM if the preserve option is set beforehand. Failure to set up a correct path for the restoration process will result in the guest VM being created at the default Citrix Hypervisor directory.
There’s also the restore to local directory method, which utilizes the “where=/some/path” restore parameter. This path needs to represent a specific location on the server where the module is installed, and even if it doesn’t exist - it would be created by the plugin itself.
The basic restoration process is relatively easy on its own, it requires a specific command to be executed, with the “where” parameter added in one way or another:
* restore where=/…
In regards to the restore parameters that are used to include or exclude specific VMs, those are similar to the ones used in the backup process. There are some additions to that, too:
- server: <address> is used to specify the XenServer API address to perform the operation, and in the case of this parameter being incorrect or absent – the default one will be utilized instead;
- port: <number> is specifying the port of the XenServer API to be used, must be in the range between 1 and 65536; the invalid parameter causes the job to be aborted and the omission of this parameter leads to the process using the default port.