XenServer Backup Solutions. How to Backup XenServer?

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.

General information about XenServer backups

There are three different backup types that XenServer Virtual Machine distinguishes – Cold, Warm and Hot backups. The main difference between these backup types is the state of the VM during the backup process. A cold backup can only occur when the VM itself is completely powered down. A warm backup does not have to do that, but VM service interruptions are still expected during the backup process. A hot backup, on the other hand, is done with a fully working VM service – even though it might affect VM performance.

As for the backups themselves, they can be differentiated between XenServer host backups and XenServer VM backups. XenServer hosts rarely need backups of themselves, if ever. The main reason for that is the metadata of a XenServer host rarely changes and it is extremely fast and easy to install XenServer itself on a server, from scratch. This makes a XenServer host backup job a relatively simple task of backing up the host metadata from time to time, which can be handled with a simple “xe host-backup” command of XenServer itself.

XenServer VM backups, on the other hand, are somewhat different in their nature. This process is typically more complicated than the host backup process, which is why we can segregate two different groups of backup options – basic and advanced.

Basic XenServer VM backups are usually there for the most spur-of-the-moment decisions – including options such as snapshots, VM exporting and existing server backup capabilities. Both snapshots and VMs cannot be considered a part of the comprehensive backup strategy for a number of reasons.

For example, snapshots tend to be extremely expensive in terms of storage space and they are also technically “hot” backups (with all of the drawbacks of this backup type). There can be some restoration complications with snapshots (such as file-level restore), and the general lack of customization options aside from automation makes it far from sufficient to be considered a full backup strategy.

Advanced XenServer backup options, on the other hand, are more varied since this is the group where all the third-party backup solutions come in. As such, we can determine three different backup categories depending on the solution’s approach to XenServer VM backup – OS level backups, XenAPI backups and storage replication.

OS level backups is most likely the oldest backup method on the list, employing a technology that has been around for a while now. It is true that VMs are virtual in their nature, but they are also still considered servers with full functionality – with different drivers and different hardware, but the same operating system.

This operating system can be used as a link for VMs to receive classic server backup treatment – installing an agent in the OS to create backups of different parts of data. Technically speaking, even the built-in Windows Backup can be used as the alternative in terms of OS level backups for XenServer (most useful for smaller companies with tight budget spendings).

XenAPI snapshots are another way to create XenServer backups, and this particular method might be the most widespread out of the three. The usage of XenAPI allows for an entire server to be backed up as an image, and there is a lot of variation when it comes to backup customization and additional features. For example, some of the more basic backup scripts that use XenAPI can be found on the Internet, and are free (NAUbackup would be a good example of that), but these scripts would not have the customization and the support that third-party XenAPI backup solutions provide.

Storage replication as a backup strategy might be the most expensive option out of the three, since it has several requirements for it to work in the first place. Two or more storage devices are needed for this strategy to work, as well as a connection between them strong enough to withstand the amount of traffic transmitted on a regular basis. This approach also makes some of the useful features harder to implement, such as file-level restore.

Of course, the best option for any company would be to acquire a solution that offers multiple approaches to XenServer VM backup – OS level and API-level, for example, covering both physical and virtual iterations of the system. However, that is not always an option, which is why there are so many different third-party solutions on the market. Bacula Enterprise is one such solution – but first we have to see how XenServer’s own VM backup capabilities work.

Built-in XenServer backup and recovery

Before going over Bacula’s capabilities with the XenServer it’s also important to mention that there is a way to do XenServer backup and restore operations with Xen itself. There are a few limitations to that, though – server backups might take a lot of storage space, you may need to restart with the original installation CD to perform a complete restore process, and you must not create XenServer control domain backups (domain 0).

Here’s how the backup process goes:

1. Select the designated server in the Resources panel, click the Server menu and proceed to the Back Up Server… line.
2. Locate and specify the folder that you want to use as the backup file storage location, enter the filename and click Save. The backup process will begin. You may also use the Logs tab to see the process of the backup.

And that’s about it, the entire backup process is just two steps. The restore process is also relatively simple:

1. First you’ll have to locate that same menu Server and click the Restore From Backup… line.
2. In the following menu locate the backup file that you want to restore.
3. Use the XenServer install CD to restart the server and complete the entire restoration process.

XenServer backup and recovery with Bacula Enterprise

Besides Bacula Enterprise’s natively integrated coverage of other Hypervisor types, it also provides native integration with Citrix Hypervisor via a specific module. 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 or complexity of the data center in question. There’s also an especially large potential in regards to flexibility and the customizability of the solution, including deployment locations, data types, recovery methods, and so on.

Bacula Enterprise’s backup and recovery of 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.

Bacula client installation on each guest XenServer VM

When it comes to actual XenServer VM backup and restore operations with Bacula, there are a number of different approaches, and it’s somewhat more sophisticated than the original method. First of all we’ll work out the way that Bacula and Citrix can operate with guest VMs and which XenServer backup strategies work for those.

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 Bacula’s 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.

XenServer backup process

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 XenServer backup, snapshot activities, which backups were deleted, etc. You can see an example of this information below:

Every guest VM participating in the process means one more XenServer 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 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.

XenServer restore process

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 utilized for the restoration process. For example, here’s one 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:

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.

Third-party XenServer backup solutions

Using Bacula also means benefitting from access to its notably highly secure and robust wider architecture and broad technology fit, typically allowing complete integration of an entire IT estate all from one platform.

Of course, Bacula Enterprise is not the only XenServer backup solution on the market; there are several other backup and recovery solutions and platforms that have XenServer backup capabilities. This includes both popular players on the market and less known companies in this field.

Vembu BDR is our first example, offering a highly customizable backup and recovery platform with plenty of different data types and storage locations supported from the get-go. Vembu’s XenServer backup capabilities are based on a previously mentioned OS-level backup, which implies image backups for VMs that run Xen Hypervisor. Vembu BDR can offer an abundance of different features for its Citrix Xen users, such as app-aware VM backups, CBT technology (changed block tracking), easier VM migration to other hypervisors, and more.

Acronis Cyber Protect is another well-known name in the backup and recovery field, and their VM support is quite versatile. It can support not only VMware vSphere and Microsoft Hyper-V environments, but also Oracle VM, RHV, Linux KVM and, of course, Citrix XenServer. Acronis uses its own massive instrumental capabilities to provide disk-image backup and restore operations to XenServer VMs, offering both a complete backup and a quick recovery process – while also providing data protection capabilities via Acronis Active Protection and offering many flexibility options in terms of backup storage locations (SAN, tape, NAS, Acronis’ own cloud storage and local disks).

Commvault is also in this market for companies that are looking for a simple yet effective XenServer backup solution. It offers an extremely flexible infrastructure, easy-to-use protection plans based on SLAs (Service Level Agreements), as well as an easy control of the entire backup architecture using a centralized VM management console. Commvault’s XenServer backup solution can act as a foundation for a strong yet flexible disaster recovery strategy for a company of any size.

Unitrends is a backup solution that goes for a slightly different angle than the others, claiming to be able to provide a comprehensive XenServer backup solution that covers all of the client’s needs when it comes to protecting their XenServer VMs. The backup and recovery side of the platform is covered by Unitrends partnering with Citrix themselves to solve the biggest problem of the snapshot backup type – their massive storage space requirements. Unitrends can also perform granular file restoration, has an extensive ransomware protection system in place with predictive analytics and machine learning, and many other features.

Moving on towards smaller solutions with specific feature sets, we have Alike DR – a Citrix Hypervisor backup and recovery solution that claims to have an unprecedented level of XenServer integration combined with an easy-to-use interface. Some of the features that Alike DR provides include Changed Block Tracking, web-based UI for better mobility and decision-making, as well as a variety of different backup methods, a cross-platform protection of the client’s data, and more.

Xen Orchestra (XO) is also a solution mostly focused on working with and supporting all kinds of XenServer environments. It is an agentless solution with a variety of backup and recovery features that also offers multiple cloud-related benefits and a centralized management interface for its users. XO also offers extensive customer support, file-level restore, and provides a plethora of different XenServer-related metrics to its clients.

SEP Software has their own take on XenServer backup solution with a short name SEP, offering full support of Citrix XenServer on multiple levels. SEP has all of the regular features that a XenServer backup solution provides, such as CBT, several backup options, file-level restore, and so on. Additional features of SEP include centralized management console, data encryption capabilities, disaster recovery capabilities, data deduplication, server conversion, etc.

Simplicity is the cornerstone of another XenServer backup solution – Vinchin Backup & Recovery. Vinchin provides a highly efficient VM backup solution for both host and pool XenServer environments combined with a comprehensive data protection. It can do agentless backups, has extensive automatization capabilities and a centralized management console. There is also the ability to recover VMs in a short time span, the aforementioned CBT technology, the ability to create backups with zero network bandwidth consumption, and so on.

The last, but not the least example on the list is Xackup – a simple yet effective XenServer backup solution from Fungusware. It has a user-friendly Wizard-driven UI that helps with all kinds of operations – VM migration, data backup, data restore, and so on. Each of these processes is made far easier and faster with Xackup – backup process has multiple target storage locations, restore process is capable of performing either full or file-level restoration, and migration process can transfer VMs between hypervisors and pools both remotely and locally with the possibility of automatization for some operations – startup, shutdown, etc.