If you’re like most Citrix administrators, you probably have a few Xen VMs running in your environment. But what if something goes wrong and one of these VMs needs to be restored? Or what if you just want to make sure that your Xen VMs are always backed up? There are a few different ways to backup your Citrix Xen VMs. But the easiest and free way is to use the Xen-pocalypse tool from Bash. This tool will take a snapshot of your Xen VM every five minutes, and then create a tarball of the VM’s disk contents. You can then store this tarball on any storage location that you want. To use Xen-pocalypse, first install Bash on your workstation. Then open a terminal window and type the following command: xen-pocalypse –name myVM –snapshot-frequency 5 –output myTarballPath ..
Have you ever needed to backup your Citrix Xen Virtual Machines (VMs) but didn’t want to break the bank doing it? HTG has just the bash script for you with Xen-pocalypse.
Image by h.koppdelaney, Stuck in Custom and Hotfortech.
One of the nice things in Citrix Xen is that many of its features are free of charge. With that said, if you want the “Automated VM protection and recovery” feature, you would have to start paying for the “Advance” license. Even then, you are only paying for disk level backups, which aren’t sufficient for many types of workloads like Active directory, Databases & Etc. To overcome this you might want the “Live memory snapshot and revert”, which can save the entire machine state, including the contents of RAM. However, that feature is part of the “Enterprise” and “Platinum” editions, which are even more expensive. It is not that we at HTG are dismissing the value of a true backup software, but if you’re on a tight budget and don’t mind some downtime for the backup operation, you might find Xen-pocalypse to be a perfectly reasonable solution before you make the budget commitment.
Overview
The “use case”: You have a couple of VMs that require a backup. The “turning off a VM and exporting it as a file” from the “Xen Center” using right clicks works ok, but you want this process to happen automatically and on a schedule. This Bash script uses the “XE” command to perform its duties. XE is the Xen command line interface (CLI), automatic equivalent for issuing the “right clicks” in the “Xen Center”. We will be calling the script from Cron which will supply the “scheduling” part. In its simplest form, the backup flow is:
Turn off the target VM. Export the VM as a file to the backup location. If the VM was turned on, before the backup started, it will be turned back on.
Lets get cracking :)
Obtain the script
Xen-pocalypse can be freely obtained from github, using the regular git methods. With that said, if you’re not versed in git yet, you can grab the zip file with this link. As the script needs to run on one of your Xen servers, you should extract it there so that execution permissions are preserved.
While the above would work, you are advised to use the GIT method, so that you may benefit from future updates.
Obtain SendEmail (optional)
We’ve written about the SendEmail perl program in the past, so there is no need to reiterate here. Suffice it to say, it works the same way on Linux as it does on Windows.
While enabling email is optional, it is highly recommended because then the script will be able to:
Inform you when it started & finished running. Alert you of any errors it was able to detect and handle. Inform of backup disqualifications due to space issues. (This behavior can be disabled if not desired)
Download it to the Xen server and extract.
Note the location where you extracted it to. You will need it for the settings file.
Defining Tags
Citrix Xen gives you the ability to configure “Custom Fields” for filtering capabilities. We will create the Fields and then populate them with the information used by Xen-pocalypse. Xen-pocalypse recognizes 3 control TAGs which designate the name of the tag for backup and the parent to child relationships. If you are not intending on using the file input method, you MUST create at least the backup tag name field.
To do this, open the server’s or even a VM’s properties. In the navigation pane, select “Custom Fields”.
If this is the first time you define a relationship (as in the example above), you will not have any fields to input data into, so you need to create them. To do this, click on “Edit Custom Fields” in the dialog box that pops up, click on “Add…”
Create three (3) “Text” type fields. One will be called “BackupTAG” and the others “Parent” and “Children”.
Note: The names of the custom fields, have been “hard coded” into the script, so you MUST not deviate from the spelling above, unless you change the relevant code as well.
Once all fields have been created, you should see:
Close the window.You should now have the “BackupTAG”, “Parent” and “Children” fields to fill, as in the picture below.
Now all you have to do is designate which VMs belong to what “BackupTAG”. For example, in the company where the script was grown, we had VMs that were to be backed up weekly on Thursday and Friday, a schedule for our Atlassian product VMs and some that were to be backed up only monthly. So our overview looked like:
Where for example “weekly-fri” was the text we have inputted into the “BackupTAG” “Custom Field”. Neat huh? :)
Parents & Children (optional)
The real beauty of this script is that it supports “parent” to “child” relationships. That is, it is possible to set a list of “child” VMs that would be turned off and backed-up before the parent, and that these children will only be turned back on once the parent has finished its backup and has been turned back on. This is useful in cases where turning off the parent VM will cause the service in the child to become unavailable. Such a thing would mean the service on the child VM would be unavailable twice, once for the child’s backup process and once for the parent’s. Creating this relationship overcomes that problem.
For example, all of our Atlassian VMs used a single DataBase (DB) VM, which was also set to be backed up. So by noting that the DB VM is a “Parent” to the other VMs, a proper order of shutdown -> backup -> startup, can be ensured.
At the time of this writing, this function has a couple of caveats:
The names of the VMs that are to have such a relationship cannot contain spaces. You will have to remove spaces from your VM names, for they will be space delimited, as in the example below. There can be only one parent. Designating more than one isn’t even planned for, not to mention tested.
To create this relationship, go into the VM’s properties. If this is a “parent”, write who its children are and if this is a “child”, write who his parent is. For example:
Note: Not designating a Parent for a child may cause the child to be started before its parent is ready, and could cause it to be backed up twice.
The FILE method (Optional)
For historical reasons, Xen-pocalypse also supports getting the list of VMs to be backed up as a text file. While the “code” is still in there, the functionality is severely inferior to the TAGs method and therefore it is not recommended. With that said, if you prefer to use the list method for some reason, the following restrictions apply:
The names of the VMs cannot contain any spaces or special characters. There can be only one VM name per line. Blank lines are not allowed.
To generate the list, either copy the VM’s name from the Xen center, or execute on a Xen host:
Copy the list above into a regular text file.
The backup location
While randomly poking around in Citrix Xen, I have found that the Storage Repositories (SRs) are available for use under “/var/run/sr-mount/%UUID%” where UUID is the unique identifier of the SR, which can be obtained from the GUI.
This means we can use the regular “Next -> Next -> Finish” wizard to create the mount to the desired backup location, and then have the script use that path (as apposed to messing with mounting from the command line), but doing so is beyond the scope of this guide.
To Create a new “mount”, right click the server name and select New SR.
In this example we will point Xen to a windows share, so choose “Windows File Sharing (CIFS)”:
Complete the Next -> Next -> Finish.
Obtain the SR’s UUID
To obtain an SR’s UUID, simply click on its name in the Xen Center and go to the “General” tab.
In order to copy the UUID, simply right click it an choose “copy”.
With this information at hand, you are ready to edit the settings file.
Configure the Settings file.
The Xen-pocalypse project comes bundled with a “settings” file template. This template should be edited to reflect your setup and passed as the first argument to the script. The settings file designates the following:
The method for obtaining the VMs to be backed up – The default method is TAGs. You may change this to FILE, but this is not recommended.
The location of the backup destination – If you have followed the guide to this point, you only have to replace the %UUID% with the SR’s as it was obtained from above.
The location of SendEmail – If you have opted to enable Email, you need to input where you have extracted the perl executable here.
Email details – Again, if you have enabled email, you need to define details such as: To, From, Servername/IP & etc’.
Compression – This is set to “No” by default, because while enabling it will produce a smaller backup file, it will also cause the backup procedure to run for a considerably longer amount of time.
Check for free space on the destination – This will have the script check that making the VM’s backup will not cause the backup location’s free space to fall beneath 10GB. This is done to ensure the most amount of VMs are backed up instead of just one very large VM. The calculation is done using the gross disk size total of all the HDs associated with the VM.
Debugging – The default is to have debugging turned off with the value “0” (zero). You should not need to turn this on, but if you do, more information is noted in the troubleshooting segment.
Execution/Scheduling
In its simplest form, an invocation of Xen-pocalypse would look like:
Where in the case above, we are inside the directory that holds the script & the settings file. The “Tag” the script will look for is “weekly-fri”.
As noted above, we will use Cron to schedule the execution. Before we go into the configuration, it is highly recommended that you configure the already installed SSMTP package on your Xen server. While this is an optional step, doing so will give you a backwash collector. Having such a “backwash collector” may alert you of things the script isn’t able to.
Enter into cron’s editing more by issuing:
If you have followed the instructions above and you want to add a scheduled backup for Friday at 18:01 (6:01PM), input the below:
The above is correct assuming your script and settings file are both under “/root/Xen-pocalypse-master/”.
Troubleshooting
While I’ve put a lot of effort into making the script as easy to use and as foolproof as possible, “The world is a bigger lab”. The information below may help you ascertain what is the source of your troubles.
Progress
You may want to use this one liner to quickly “watch” all tasks in progress, to see if they actually progressing at all or if they are actually stuck.
To stop watching, use Ctrl+C to brake the “while loop”.
Logging
All “logging” is collected by the Xen host running the script in the syslog mechanism. This of course can be viewed with:
You are looking for the key word “Xen-pocalypse”.
Note: Citrix has set a two (2) day retention policy for syslog of its servers. You may want to keep that in mind for postmortems.
Debugging
As noted in the settings file segment, there is a directive to enable debugging. Enabling debugging will cause the script to output verbose logging to the console and castrate it from sending emails and actually performing the exports, unless the relevant flags are also set. The possible flags are noted in the settings file template and they enable you to granularly define what you want to debug.
It is my hope that you haven’t needed any debugging and you are reaping the fruits of my labor :)
Thrust, my man, you are about to become number one decepticon…
