OpenVZ, backups, and you

Virtualization technologies are moving to the forefront of computing. VMWare, OpenVZ (Virtuozzo), VirtualBox, Xen, KVM, Hyper-V… the list grows. Today we’ll take a look at the most basic and critical of functions in any environment – backups. In today’s example we’ll take a look specifically at backups in OpenVZ. First, lets talk about what kind of virtualization OpenVZ provides.

OpenVZ is OS level virtualization, as opposed to the full virtualization you see in VMWare or the paravirtualization options you see with KVM. The system functions as a series of chrooted jails that completely segregate each container from the other containers on the system. Because they share most common files there is often a significant savings of disk space on a host with many containers. Because there is less emulation of hardware occurring, this also tends to yield good performance compared to paravirtualzation. The ability to update the host alone and subsequently all guests relying on the host as well has made this an attractive option to many hosting providers and companies with a large infrastructure to maintain.

So let’s dig into backups a bit. OpenVZ provides vzdump for working with containers. Vzdump takes a snapshot of the configuration and private space of a container and backs it up to a directory you specify as a tar ball. This backup can be later restored to the same or a different machine with little difficulty.

There are three basic forms that vzdump can operate in. The first is stop the container and back it up, which requires significant downtime. The second is rsync and suspend/resume the container, requiring minimal downtime. The third involves the use of lvm2 shadow snapshots, which requires no downtime.

In it’s most simple form it consists of the following:

vzdump [container-id-number]

This will simply take the private area and configuration file and dump them as a tar ball to the default directory (/vz/dump). It does stop the container to perform this operation which can take anywhere from five minutes to several hours to complete. For development servers this is an acceptable option, but for most production servers, this kind of downtime is unacceptable.

The second way we can perform backups is to suspend the vm long enough for rsync to take a snap shot of the differences between the start of the backup and the completion. This still results in downtime but it is minimal. This makes this option much more desirable.

vzdump --suspend [container-id-number] --dumpdir /backups

The options here are fairly simple. The –suspend tells the vzdump program to use rsync and the –dumpdir parameter tells vzdump to place the backups outside of the default area in the /backups directory. The short amount of downtime makes this a much more acceptable method of backing up for most companies. Most of us want no downtime, which brings us to our third option.

The third option is to use lvm2 to create a snapshot of the os. This option isn’t syntactically more difficult than the previous two options, but it does offer a full backup with no downtime.

vzdump --snapshot [container-id-number]

Here we take a simple backup and dump it to the /vz/dump directory (the default), and we tell vzdump to make it a snapshot backup so there is no downtime involved in getting the backup. This is by far the best option for most operators, as host downtime can often lead to lost revenue.

So now you have a backup made, what do you do with it? Well, vzdump is the answer there as well. The tool that makes the backups also restores them. The syntax for that is what you would expect.

vzdump --restore /backup/vzdump-containeridnumber.tar [container-id-number]

Some versions of OpenVZ do not support vzdump –restore and if this is the case then you should look at using vzrestore like so:

vzrestore /backup/vzdump-containeridnumber.tar [container-id-number]

This will provide exactly the same effect as using vzdump –restore.

If you’re unsure of the id of your container you can get a full list of ids by running vzlist. There is always the option of using –all instead of a specific container id which will perform that operation on all containers running on that specific host.

This covers the basics of using vzdump and how to restore the backups created with it. Virtuozzo offers a lot of flexibility in performing backups and if the option you prefer isn’t available for your os, there are a lot of third party tools available as well. For example, vzbackup from Parallels for Virtuozzo which supports backing up to remote sites. You can even schedule simple tar backups, remote rsync backups, or code your backups to fit into your existing backup scheme. Just be sure to correctly backup and test your restores no matter what method you use, any backup is only as good as your ability to restore it!

As always, if you need further assistance with this or any other open source application or issue, the experts at Pantek Inc. are available 24/7 at info@pantek.com, 216-344-1614, and 877-LINUX-FIX! We look forward to working with you.