XenServer backup and recovery solutions

Easy and fast XenServer backup software by Bacula Systems 

Bacula Systems’ technology for XenServer backup and disaster recovery brings never-seen-before speed and convenience to Xen users, all designed to make your backup of Xen VMs easier and with no intermediate steps required.

Bacula Enterprise’s native integration with Xen provides virtual machine bare metal recovery, while its ability to back up data at the guest level simplifies data protection of critical applications. Backup can be performed for a guest VM in any power state (running or halted). Single File Recovery is available.

Bacula uses the Xen Server API to access and backup virtual machines. It brings a broad range of features, capabilities and automation to the Xen environment, including Incremental and Differential backup levels. A detailed description of Bacula Enterprise’s capabilities with  XenServer (Citrix Hypervisor) follows below:

Bacula’s XenServer backup features

  • Snapshot-based online backup of any guest VM
  • Differential and Incremental backup levels
  • Single File Recovery
  • VSS-based guest snapshots for quiescing VSS-based applications
  • Full image-level backup
  • Ability to restore complete virtual machine image
  • Ability to restore VM archive to alternate directory
  • Uses raw disk images and ova configuration
  • Supports restore of old backup formats
  • Full restore job logs

Bacula also displays useful information about available XenServer resources, which could simplify your backup configuration and restore operations, such as:

  • List of guest VM name-labels
  • List of guest VM UUIDs
  • List of XenServer Storage Repositories

Benefits of XenServer backup solution from Bacula 

It is important to have a XenServer backup strategy that goes beyond the use of scripts at the command line level or shell, which do not offer alternatives or benefits in terms of:

  • Granularity while using Citrix XenServer VM backup and restores
  • Execution of different Citrix XenServer VM backup levels
  • Ease of Citrix Xen VM data recovery
  • Scheduling of backup for XenSever from Citrix

Bacula Enterprise allows you to manage and execute the backup of XenServer VM configured in diverse environments, whether physical, remote or in the cloud.

XenServer Backup and Restore Operations

(Note: all below sections are under review, due to the module having just been updated with new features)

Backup

The backup operation of a single guest XenServer VM takes the following steps:

  • Find and delete any old or stalled backup snapshots if found.
  • Create a new guest VM Bacula snapshot and prepare it for backup.
  • Execute XenServer’s vm-export command and save the data to a Bacula storage daemon.
  • Delete the guest VM’s Bacula snapshot.

XenServer backups can be performed for a guest VM in any power state (running or halted). Any guest VM snapshot with a name-label which matches the following template: BaculaSnapshot_<UUID>_JobID_<NR> will be treated as an old backup snapshot for this guest VM and will be automatically deleted during backup. Avoid creating manuall snapshots that match this naming scheme. Any other guest VM snapshots will be unaffected. The XenServer backup plugin will inform you about every guest VM backup start and finish including information about old stalled backup snapshots and backup snapshot activities. For example:

 

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) OK.

The backup will create a single file for every guest VM saved in the form of: /@xen/<name-label>/<vmuuid>.xva. Multiple files will be created during the backup if multiple guest VMs are found to backup. You can use this information to locate the proper guest VM archive during a restore.

 

+——————————————————-+
| filename |
+——————————————————-+
| /@xen/vm1/10908c8a-f932-6f91-9cac-3034e3acf45b.xva |
| /@xen/vm1/03fad8c9-d88b-ea7e-98da-2f3bcd20d0c4.xva |
| /@xen/CentOS/fe1ccf3b-1865-3942-c928-d98138397ff1.xva |
+——————————————————-+

Restore

The XenServer VM backup and recovery module provides two main targets for restore operations:

  • Restore to a XenServer hypervisor as new or original guest VM
  • Restore to a local directory as a XenServer XVA archive file or files

Restore to XenServer

To use this restore method you have to set a “where=/” Bacula restore parameter. The guest VM archive will be sent to the XenServer hypervisor and restored as a new guest VM (default behavior) or restored as an original when plugin restore option preserve will be set. You can change the Storage Repository where your guest VM will be restored.

To list available Storage Repositories you can use a listing mode, see 6.1 on page 13. If you set an improper (eg: non-existent) Storage Repository for restore, then the restore process will create the guest VM on the XenServer’s default storage.

Restore To Local Directory

To use this restore method you have to set a “where=/some/path” Bacula restore parameter. The path has to be a directory location on the server where the XenServer VM backup plugin is installed. If the path doesn’t exist, it will be created by the plugin.

XenServer VM Backup Installation

You have to install and configure the Bacula File Daemon on your XenServer hypervisor machine which hosts your virtual guest VMs that you want to backup. The XenServer hypervisor uses a customized CentOS distribution (RHEL derivative), so you need to install the Bacula Enterprise File Daemon compatible with that Linux distribution.

Configuration

The Plugin Directory directive of the File Daemon resource in /opt/bacula/etc/baculafd.conf should point where the xenserver-fd.so plugin is installed. The standard Bacula plugin directory is: /opt/bacula/plugins

 

FileDaemon {
Name = bacula-fd
Plugin Directory = /opt/bacula/plugins

}

Installation of the XenServer VM backup plugin

You can install the Bacula Enterprise XenServer plugin by extending the repository file for your package manager to contain a section for the plugin. For example, in Redhat/CentOS 7, /etc/yum.repos.d/bacula.repo:

 

[Bacula]
name=Bacula Enterprise
baseurl=https://www.baculasystems.com/dl/@customer-string@/rpms/bin/@version@/rhel7-64/
enabled=1
protect=0
gpgcheck=0
[BEEXenPlugin]
name=BEE XenServer Plugin
baseurl=https://www.baculasystems.com/dl/@customer-string@/rpms/xenserver/@version@/rhel7-64/
enabled=1
protect=0
gpgcheck=0

Then perform a yum update and after that the package bacula-enterprise-xenserverplugin can be installed with yum install.
If you prefer to manually install the packages, you can also download them from your download area and use one of the low level package manager tools such as rpm to do the plugin installation.

XenServer Backup Configuration

The XenServer backup plugin is configured using the parameters defined in a FileSet’s “Include” section of the Bacula Enterprise Director’s configuration.

Generic plugin Parameters

The following XenServer VM backup plugin parameters effect any type of Job (Backup, Estimation, or Restore).

  • server=<address> specifies the XenServer API address used for operations. This is the address used in the xe command as the -s <address> parameter. This parameter is optional. If omitted default access will be used.
  • port=<number> specifies the XenServer API port used for operations. This is the value used in the xe command as the -p <number> parameter. The value of this parameter has to be in the range of 1..65536. An invalid value will cause the job to be aborted. This parameter is optional. If omitted default access will be used.
  • username=<string> specifies the username used to access the XenServer API system. This is the value used in the xe command as the -u <string> parameter. This parameter is optional. If omitted default access will be used.
  • password=<string> specifies the password used to access the XenServer API system. This is the value used in the xe command as the -pw <string> parameter. This parameter is optional. If omitted default access will be used.
  • passfile=<string> specifies a file local to the File Daemon that contains the password for the username. This is the value used in the xe command as the -pwf <string> parameter. This parameter is optional. If omitted default access will be used.
  • abort_on_error[=<0 or 1>] specifies whether or not the plugin should abort it’s execution (and the Bacula Job) if a fatal error occurs during a Backup, Estimation, or Restore operation. This parameter is optional. The default value is 0.

Estimation and XenServer VM Backup Plugin Parameters

  • vm=<name-label> specifies a guest VM name to backup. All guest VMs with a name-label provided will be selected for backup. Multiple vm=… parameters may be provided. If a guest VM with <name-label> can not be found, then a single job error will be generated and the backup will proceed to the next VM unless abort_on_error is set which will cause the backup job to be aborted. This parameter is optional.
  • uuid=<uuid> specifies a guest VM UUID to backup. Multiple uuid=… parameters may be provided. If a guest VM with <uuid> can not be found, then a single job error will be generated and the backup will proceed to the next VM unless abort_on_error is set which will cause the backup job to be aborted. This parameter is optional.
  • include=<name-label-regex> specifies list of a guest VM names to backup using regular expression syntax. All guest VMs which match the name-labelregex provided will be selected for backup. Multiple include=… parameters may be provided. If no guest VMs match the <name-label-regex> provided, the backup will proceed to the next VM parameters or finish successfully without backing up any VMs. The abort_on_error parameter will not abort the job when no guest VMs are found using a <name-label-regex>. This parameter is optional.
  • exclude=<name-label-regex> specifies list of a guest VMs names which will be excluded from backup using regular expression syntax. All guest VMs which match the name-label-regex provided and were selected for backup using include=… parameters will be excluded. This parameter does not affect any guest VMs selected to backup with vm=… or uuid=… parameters. Multiple exclude=… parameters may be provided. This parameter is
    optional.
  • quiesce[=<0 or 1>] specifies if the guest VM snapshot should be created using a quiesce method or not. The quiesce method is supported by XenServer for Windows OS with guest-tools installed only. This is a limitation of the XenServer itself. If the guest VM snapshot with quiesce cannot be created, the whole backup job will be aborted. In this case you should repeat a backup without the quiesce parameter.

If none of the paramaters vm=…, uuid=…, include and exclude are specified, all available guest VMs hosted on the XenServer hypervisor will be backed up.

Plugin Restore Parameters

During restore, the XenServer backup plugin will use the same parameters which were set for the backup job and saved. Some of them may be changed during the restore process if required.

  • server: <address> specifies the XenServer API address used for operations. This is the address used in the xe command as the -s <address> parameter. This parameter is optional. If omitted default access will be used.
  • port: <number> specifies the XenServer API port used for operations. This is the value used in the xe command as the -p <number> parameter. The value of the parameter must be in the range of 1..65536. An invalid value will cause the job to be aborted. This parameter is optional. If omitted default access will be used.
  • username: <string> specifies the username used to access the XenServer API system. This is the value used in the xe command as the -u <string> parameter. This parameter is optional. If omitted default access will be used.
  • password: <string> specifies the password used to access the XenServer API system. This is the value used in the xe command as the -pw <string> parameter. This parameter is optional. If omitted default access will be used.
  • passfile: <string> specifies a file local to the File Daemon that contains the password for the username. This is the value used in the xe command as the -pwf <string> parameter. This parameter is optional. If omitted default access will be used.
  • storage_res: <storage> specifies a XenServer Storage Repository where restored guest VMs will be saved. If not set, then a guest VM will be saved to a XenServer Storage Repository configured as the default. This parameter is optional.
  • preserve: <yes or no> specifies if a restore job should preserve as much guest VM configuration parameters as possible. The default is to create a new VM on restore. A restore job with this preserve option set to ’yes’ could fail if the restore might create duplicate objects on the XenServer hypervisor. This parameter is optional.

FileSet Examples

In the example below, all guest VMs will be backed up.

 

FileSet {
Name = FS_XenAll
Include {
Plugin = “xenserver:”
}
}

In the example below, a single guest VM with a name-label of “VM1” will be backed up.

 

FileSet {
Name = FS_Xen_VM1
Include {
Plugin = “xenserver: vm=VM1”
}
}

The same example as above, but using uuid instead:

 

FileSet {
Name = FS_Xen_VM1
Include {
Plugin = “xenserver: uuid=fe1ccf3b-1865-3942-c928-d98138397ff1”
}
}

In the example below, all guest VMs which have ’Prod’ in the name will be backed up.

 

FileSet {
Name = FS_Xen_ProdAll
Include {
Plugin = “xenserver: include=Prod”
}
}

In the example below, all guest VMs except VMs whose name-label begins with “Test” will be backed up.

 

FileSet {
Name = FS_Xen_AllbutTest
Include {
Plugin = “xenserver: include=.* exclude=^Test”
}
}

Restore

Restore to a XenServer Hypervisor

To restore a VM or VMs to a XenServer hypervisor, you should execute the restore command and specify the “where” parameter as in this example:

 

* restore where=/

… Then set any other required restore plugin parameters for your restore. In the following restore session example, the “Preserve vm config on restore” plugin restore option is set to “yes”:

 

* restore where=/

Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/srv-xen-01-dir.restore.2.bsr
Where: /
Replace: Always
FileSet: Full Set
Backup Client: srv-xen-01-fd
Restore Client: srv-xen-01-fd
Storage: File1
When: 2018-01-05 12:47:16
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Restore Client
6: When
7: Priority
8: Bootstrap
9: Where
10: File Relocation
11: Replace
12: JobId
13: Plugin Options
Select parameter to modify (1-13): 13
Automatically selected : xenserver: uuid=fe1ccf3b-1865-3942-c928-d98138397ff1
Plugin Restore Options
server: *None* (*None*)
port: *None* (*None*)
username: *None* (*None*)
password: *None* (*None*)
passfile: *None* (*None*)
storage_res: *None* (*Default location*)
preserve: *None* (*No*)
Use above plugin configuration? (yes/mod/no): mod
You have the following choices:
1: server (Restore server name)
2: port (Restore server port number)
3: username (Restore user name)
4: password (Restore user password)
5: passfile (Restore user password file)
6: storage_res (Storage Resource location for restore)
7: preserve (Preserve vm config on restore)
Select parameter to modify (1-7): 7
Please enter a value for preserve: yes
Plugin Restore Options
server: *None* (*None*)
port: *None* (*None*)
username: *None* (*None*)
password: *None* (*None*)
passfile: *None* (*None*)
storage_res: *None* (*Default location*)
preserve: yes (*No*)
Use above plugin configuration? (yes/mod/no):

The restore job log will inform you about what guest VM is restored and what new guest VM was created.

 

JobId 131: Start Restore Job RestoreFiles.2017-12-28_14.42.25_15
JobId 131: Using Device “FileChgr1-Dev2” to read.
JobId 131: xenserver: VM restore: vm1/10908c8a-f932-6f91-9cac-3034e3acf45b
JobId 131: Forward spacing Volume “Vol-0002” to addr=1758441248
JobId 131: Elapsed time=00:04:51, Transfer rate=3.158 M Bytes/second
JobId 131: xenserver: VM UUID created: 45c49e07-ff20-ab55-e622-05ff2fbb0c1f

The new guest VM created during the restore will get a new name-label set by the plugin as: <name-label>/<vmuuid> where <vmuuid> is the UUID of the original VM which was backed up.

Restore to Local Directory

 

* restore where=/tmp/bacula/restores

Please check the following example for the test “VM local restore”:

 

JobId 112: Start Restore Job RestoreFiles.2017-12-28_11.30.19_34
JobId 112: Using Device “FileChgr1-Dev2” to read.
JobId 112: xenserver: VM local restore
JobId 112: Forward spacing Volume “Vol-0001” to addr=5190619786
JobId 112: Elapsed time=00:00:30, Transfer rate=30.64 M Bytes/second

The restore job log will inform you that a restore will go to a local directory.

Nicolas Van Eenaeme
Netlog’s Director of ITS
«As we grew, XenServer backup was taking longer and longer to complete. We then decided to take a support contract with Bacula Systems to use Bacula Enterprise. Bacula even helped us optimize our XenServer VM configuration, and now backups are completed almost twice as fast as before’»

Further help on XenServer backup: