This section is dedicated to all existing methods of rolling back or backing up your VMs in Xen Orchestra.
There are several ways to protect your VMs:
- Full Backups [Starter Edition]
- Rolling Snapshots [Starter Edition]
- Delta Backups (best of both previous ones) [Enterprise Edition]
- Disaster Recovery [Enterprise Edition]
- Continuous Replication [Premium Edition]
- File Level Restore [Premium Edition]
There is also a way to automatically select the VMs to backup: smart backup [Enterprise Edition]
This is the welcome panel for the backup view. It recaps all existing scheduled jobs. This is also where the backup logs are displayed.
All the scheduled operations (backup, snapshots and even DR) are displayed in the main backup view.
A successful backup task will be displayed in green, a faulty one in red. You can click on the arrow to see each entry detail.
You also have a filter to search anything related to these logs.
Logs are not "live" tasks. If you restart XOA during a backup, the log associated with the job will stay in orange (in progress), because it wasn't finished. It will stay forever unfinished because the job was cut in the middle.
Each backups' job execution is identified by a
runId. You can find this
runId in its detailed log.
All backup types rely on snapshots. But what about data consistency? By default, Xen Orchestra will try to take a quiesced snapshot every time a snapshot is done (and fall back to normal snapshots if it's not possible).
Snapshots of Windows VMs can be quiesced (especially MS SQL or Exchange services) after you have installed Xen Tools in your VMs. However, there is an extra step to install the VSS provider on windows. A quiesced snapshot means the operating system will be notified and the cache will be flushed to disks. This way, your backups will always be consistent.
To see if you have quiesced snapshots for a VM, just go into its snapshot tab, then the "info" icon means it is a quiesced snapshot:
The tooltip confirms this:
Remotes are places where your backup and delta backup files will be stored.
To add a remote, go to the Settings/Remotes menu.
Supported remote types:
- Local (any folder in XOA filesystem)
- SMB (CIFS)
WARNING: the initial "/" or "\" is automatically added.
On your NFS server, authorize XOA's IP address and permissions for subfolders. That's all!
We support SMB storage on Windows Server 2012 R2.
WARNING: For continuous delta backup, SMB is NOT recommended (or only for small VMs, eg < 50GB)
Also, read the UI twice when you add an SMB store. If you have:
192.168.1.99as SMB host
- no subfolder
You'll have to fill it like this:
PATH TO BACKUP is only needed if you have subfolders in your share.
This is for advanced users. Using the local XOA filesystem without extra mounts/disks will use the default system disk of XOA.
If you need to mount an unsupported store (FTP for example), you can always do it manually:
- mount your remote store inside the XOA filesystem manually, e.g in
- in the web interface, select a "local" store and point it to your
Any Debian Linux mount point could be supported this way, until we add further options directly in the web interface.
All your scheduled backups are acccessible in the "Restore" view in the backup section of Xen Orchestra.
- Select your remote and click on the eye icon to see the VMs available
- Choose the backup you want to restore
- Select the SR where you want to restore it
Note: You can restore your backup even on a brand new XenServer and on brand new hardware.
By default, Backups are compressed (using GZIP, done on XenServer side). There is no absolute rule but in general uncompressed backups are faster (but sometimes much larger).
XenServer uses Gzip compression, which is:
- slow (single threaded)
- space efficient
- consumes less bandwidth (helpful if your NFS share is far away)
If you have compression on your NFS share (or destination filesystem like ZFS), you can disable compression in Xen Orchestra.
If you want to use XOA to locally store all your backups, you need to attach a large disk to it. This can be done live.
First, after your disk is attached to XOA, you'll have to find the new disk name with
fdisk -l. It's probably
Then, create a filesystem on it:
If you already have backups done, you can move them to the new disk. The orignal backups folder is in
To make the mount point persistent in XOA, edit the
/etc/fstab file, and add:
/dev/xvdb /var/lib/xoa-backups ext4 defaults 0 0
This way, without modifying your previous scheduled snapshot, they will be written to this new local mountpoint!
Replicated VMs HA are taken into account by XS/XCP-ng. To avoid the resultant troubles, HA will be disabled from the replicated VMs and a tag indicating this change will be added.
The tag won't be automatically removed by XO on the replicated VMs, even if HA is re-enabled.