Virtkick Docs

Documentation and information to Virtkick your business

How to Perform a Live Backup on your KVM Virtual Machines

One of the most common requests we receive at Virtkick is information on backing up machine data on hypervisors. This guide will provide you with the basic steps necessary to perform a live back up virtual machines on your hypervisor(s).

1. Preparing Virtual Machines

First, you'll need to log in as the `virtkick user, you can do this by executing the following command as root:

su - virtkick

Next, locate the virtual machine you want to back up using virsh:

virsh -c qemu:///system list

You should see something like this:

 Id    Name                           State
----------------------------------------------------
...
 387   1_c72backuptest_d10af10c-cd41-4220-a175-0476eb4918c9 running
...

Your exact output will vary based on the machines running on your hypervisor. Note the name of your virtual machine, in this case it would be 1_c72backuptest_d10af10c-cd41-4220-a175-0476eb4918c9.

Next, you'll need to dump the configuration for this virtual machine, libvirt uses XML to define virtual machines so you will need to dump the XML for this machine using the following command:

virsh -c qemu:///system dumpxml MACHINE_NAME > /path/to/your/backup/directory/backup.xml

Substitute MACHINE_NAME with the name you found in the step above and be sure to supply a path to the directory you actually want the XML to land in.

2. Create the backup

Now that you have the configuration for this virtual machine, you can begin the process of creating the data backup. To do this, you will first need to locate the disk for this machine on the filesystem. To do this you can execute the following command:

virsh -c qemu:///system domblklist MACHINE_NAME

You should see output similar to this:

Target     Source
------------------------------------------------
vda        /home/virtkick/hdd/1_c72backuptest_d10af10c-cd41-4220-a175-0476eb4918c9.qcow2 <-- This is your disk location
hda        -

The disk location has been hilighted above. Note that path before moving on.

With this information you can now create the backup of this machine using a snapshot. To do this excute the following commands:

mkdir -p /home/virtkick/snapshots/20160803/
virsh snapshot-create-as --domain 1_c72backuptest_732019dd-3479-4e59-8fbf-3f7e210f2ec1 NAME_OF_YOUR_BACKUP --diskspec vda,file=/home/virtkick/snapshots/20160803/1_c72backuptest_732019dd-3479-4e59-8fbf-3f7e210f2ec1-NAME_OF_YOUR_BACKUP.qcow2 --disk-only --atomic

Substitute NAME_OF_YOUR_BACKUP with the name you would like to assign to this backup, including a timestamp is usually a good idea. Take the path you obtained in the last step, this should be to a .qcow2 file.

Warning: there's a bug which may prevent you from creating a snapshot since Virtkick disables dynamic_ownership parameter in Libvirt. To workaround it you need to create empty file with proper ownership set in place of snapshot:

touch /home/virtkick/snapshots/20160803/1_c72backuptest_732019dd-3479-4e59-8fbf-3f7e210f2ec1.qcow2
chown virtkick:kvm /home/virtkick/snapshots/20160803/1_c72backuptest_732019dd-3479-4e59-8fbf-3f7e210f2ec1.qcow2

After creating the snapshot all disk operations from guest will be directed to it so that you can copy the original disk file to safe place.

3. Secure your backups

Backups are generally not very useful if they remain on the hypervisor. Ideally, backups should be moved to discrete hardware that uses a sufficiently redundant RAID level. Even more ideally, this hardware should be located in a geographically discrete location.

You can move your backups using any method you prefer, but be sure to include both the qcow2 disk image and the machine configuration (the XML file).

rsync -hav --progress /home/virtkick/hdd/1_c72backuptest_d10af10c-cd41-4220-a175-0476eb4918c9.qcow2 backup@some-backup-server:/backup/safe/place

4. Performing active blockcommit

After the file transfer is completed, you should merge changes written to snapshot, back to original disk image. This operation is called 'active block commit':

virsh blockcommit MACHINE_NAME vda --active --pivot --shallow --verbose

If you get an error that blockcommit is not supported by qemu and you run CentOS 7, you may need to perform an update. This may be the case if you connected your hypervisor to Virtkick couple months ago. Here is how to do it:

pkg_install "http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm"
check_pkg ovirt-release40
yum --disablerepo="*" --enablerepo="ovirt-4.0" update -y

Check block devices again. If the block commit completed successfuly your virtual machine should use its original image again:

# virsh -c qemu:///system domblklist MACHINE_NAME

Target     Source
------------------------------------------------
vda        /home/virtkick/hdd/1_c72backuptest_d10af10c-cd41-4220-a175-0476eb4918c9.qcow2
hda        -

If you need more information please refer to official Libvirt guide: http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

Need to know how to restore your backup(s)? Take a look at our guide on restoring live backups

Have any problems? Let us know - we are happy to help!

Back to the list ยป

avatar
Joe Pettit
Developer @ Virtkick
comments powered by Disqus