Skip navigation links
Overview Expand Overview
Products Expand Products
Solutions Expand Solutions
Support Services Expand Support Services
Partners Expand Partners
About Us Expand About Us
How to Buy

B.4. Backing up and restoring XenServer Hosts and VMs

We recommend that, whenever possible, you leave the installed state of XenServer Hosts unaltered. That is, do not install any additional packages or start additional services on XenServer Hosts, and treat them as if they are appliances. The best way to restore, then, is to re-install XenServer Host software from the installation media. If you have multiple XenServer Hosts, the best approach is to configure a PXE boot server and appropriate answerfiles for this purpose (see Appendix C, PXE installation of XenServer Host).

For VMs, the best approach is to install backup agents on them, just as if they were standard physical servers. For Windows VMs, as of this release we have tested CA BrightStor ARCserve Backup, and Symantec NetBackup and Backup Exec.

For more information about backup tools tested, best practices, and backups in general, see the XenSource Knowledge Base.

B.4.1. Backing up Virtual Machine metadata

XenServer Hosts use a per-host database to store metadata about VMs and associated resources such as storage and networking. When combined with storage repositories, this database forms the complete view of all VMs available across the pool. Thus, it is important to understand how to backup this database in order to recover from physical hardware failure and other disaster scenarios.

This section first describes how to backup metadata for single-host installations, and then for more complex pool setups.

B.4.1.1. Backing up single host installations

The CLI must be used to backup the pool database. To obtain a consistent pool metadata backup file, run xe pool-dump-database against the host and archive the resulting file. The backup file will contain sensitive authentication information about the pool, so ensure it is securely stored.

To restore the pool metadata, use the xe pool-restore-database from a previous dump file. If your XenServer host has died completely then you must first do a fresh install, and then run the xe pool-restore-database command against the freshly installed host.

After a restoration of metadata, some VMs may still be registered as being “suspended”, but the Storage Repository with the suspended metadata is no longer available since the host has been reinstalled. To reset these VMs back to the halted state so that they can be started up again, use the xe vm-reset-powerstate command.

Note that hosts restored using this method will have their UUIDs preserved. Thus, if you restore to a different physical machine while the original host is still running, there will be a UUID clash. The main observable effect of this clash will be that XenCenter will refuse to connect to the second host. Pool metadata backup is not the recommended mechanism for cloning physical hosts; you should use the automated installation support for that (see Appendix C, PXE installation of XenServer Host).

B.4.1.2. Backing up pooled installations

In a pool scenario, the master host provides an authoritative database which is synchronously mirrored by all the slave hosts in the pool. This provides a degree of built-in redundancy to a pool; the master can be replaced by any slave since each of them have an accurate version of the pool database. Please refer to the XenServer Administrator's Guide for more information on how to transition a slave into becoming a master host.

This level of protection may not be sufficient; for example, if your shared storage containing the VM data is backed up in multiple sites, but your local server storage (containing the pool metadata) is not. To fully recreate a pool given just a set of shared storage, you must first backup the xe pool-dump-database against the master host, and archive this file.

To subsequently restore this backup on a brand new set of hosts

  1. Install a fresh set of XenServer hosts from the installation media, or via PXE.

  2. Use the xe pool-restore-database on the host designated to be the new master.

  3. Run the xe host-forget command on the new master to remove the old slave machines.

  4. Use the xe pool-join command on the slave hosts to connect them to the new cluster.

B.4.2. Backing up XenServer Hosts

This section describes the XenServer Host control domain backup and restore procedures. These procedures do not back up the Storage Repositories that house the VMs, but only the privileged Control Domain that runs Xen and the XenServer agent.

Note that since the the privileged privileged Control Domain is best left as installed, without customizing it with other packages, we recommend you set up a PXE boot environment to cleanly perform a fresh installation from the XenServer media as a recovery strategy. In many cases you will not need to backup the control domain at all, but just save the pool metadata (see Section B.4.1, “Backing up Virtual Machine metadata”).

Another approach is to run the XenServer installation twice, selecting to back up the existing installation when prompted. This will create a pristine copy of the freshly-installed Control Domain that can later be restored if necessary by using the installation CD and choosing the Restore option.

Using the xe commands host-backup and host-restore is another approach that you can take. If using these commands, the VM metadata must also be separately restored by using the xe pool-restore-database command as described above (see Section B.4.1, “Backing up Virtual Machine metadata”).


The CLI host-backup command captures a live stream of the Control Domain, and so is not guaranteed to be completely consistent with a fresh installation. If live Control Domain backups are required, then the CLI commands are appropriate. Otherwise, this is not recommended.

Be careful not to mix up the pool metadata backup file (creating using xe pool-dump-database) with the backup files for the control domain (created using xe host-backup). These files are in different formats and contain different data, and so should not be interchanged.

To back up a XenServer Host

  1. Backup the pool metadata using the xe pool-dump-database, as described above in Section B.4.1, “Backing up Virtual Machine metadata”.

  2. On a remote host with enough disk space, run the command:

    xe host-backup file-name=filename -h hostname -u root -pw password

    This creates a compressed image of the Control Domain file system in the location specified by the file-name argument.

To restore a running XenServer Host

  1. If you want to restore a XenServer Host from a specific backup, run the following command while the XenServer Host is up and reachable:

    xe host-restore file-name=filename -h hostname -u root -pw password

    This restores the compressed image back to the hard disk of the XenServer Host. In this context “restore” is something of a misnomer, as the word usually suggests that the backed-up state has been put fully in place. The restore command here only unpacks the compressed backup file and restores it to its normal form, but it is written to another partition (/dev/sda2) and does not overwrite the current version of the filesystem.

  2. To actually use the restored version of the root filesystem, you need to reboot the XenServer Host using the XenServer installation CD and select the Restore from backup option.

    After the Restore from Backup is completed, reboot the XenServer Host machine and it will start up from the restored image.

    Finally, restore the VM meta-data using the xe pool-database-restore command.

To restart a crashed XenServer Host

  1. If your XenServer Host is crashed and not reachable anymore, you need to use the XenServer installation CD to do an upgrade install (see Section B.2, “Upgrading from version 3.2 to the current version”). When that is completed, reboot the machine and make sure your host is reachable with XenCenter or remote CLI.

  2. Then proceed with the procedure on restoring a running XenServer Host.

B.4.3. Backing up VMs

VMs are best backed up using standard backup tools running on them individually. For Windows VMs, we have tested CA BrightStor ARCserve Backup.