VirtualBox: Creating Backups & Clones Of Running Virtual Machines (No Downtime) With LVM Snapshots

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Tue, 2012-07-24 17:53. :: VirtualBox | Virtualization

VirtualBox: Creating Backups & Clones Of Running Virtual Machines (No Downtime) With LVM Snapshots

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Follow me on Twitter
Last edited 07/19/2012

If you use LVM volumes for your VirtualBox VMs (as shown in the tutorial Using RAW Devices In VirtualBox VMs), you can create backups and clones of a running VM without shutting it down. This tutorial shows just that: using LVM snapshots to create backups and clones of running VirtualBox VMs without downtime.

I do not issue any guarantee that this will work for you!

 

1 Preliminary Note

Because I've installed VirtualBox on a headless server, I'm using phpvirtualbox as the VirtualBox GUI here. If you use the original VirtualBox GUI, that is perfectly fine.

My running virtual machine (of which I want to take a backup) is named vm10, and it is located on the LVM volume /dev/vg0/vm10.

Make sure that you are logged in as root (type in

sudo su

to become root), because we must run all the steps from this tutorial as root user.

 

2 Create A Backup Of A Running VM With LVM Snapshots

To create a backup of the running virtual machine vm10, I first create an LVM snapshot of /dev/vg0/vm10 called vm10_snap. Snapshots can be smaller than the original volume - 512MB would probably enough, but I'm using a size of 5GB here:

lvcreate -L5G -s -n vm10_snap /dev/vg0/vm10

Next I use dd to read the contents from the snapshot and pipe it to gzip to create a gzipped backup image in the directory /backup (you can, of course, use any other directory):

dd if=/dev/vg0/vm10_snap bs=64k | gzip -c > /backup/vm10.img.gz

That's it - your backup of vm10 is now located in /backup/vm10.img.gz.

Now remove the LVM snapshot:

lvremove -f /dev/vg0/vm10_snap

 

3 Restore From A Backup/Clone From A Backup

Restoring and cloning is essentially the same, so I will show how to create a clone called vm11 from the backup we've just created.

First create an LVM volume of the same size as the original LVM volume (20GB in this example):

lvcreate -L20G -n vm11 vg0

Restore the backup of vm10 to the new logical volume /dev/vg0/vm11:

gunzip -c /backup/vm10.img.gz | dd of=/dev/vg0/vm11 bs=64k

Next create a .vmdk file for /dev/vg0/vm11 (e.g. vm11.vmdk) so that we can use it with VirtualBox. It's probably best to create it in the home directory of the user under which VirtualBox is running (e.g. /home/vbox if you use phpvirtualbox) - the file must also be owned by that user:

cd /home/vbox
VBoxManage internalcommands createrawvmdk -filename vm11.vmdk -rawdisk /dev/vg0/vm11
chown vbox:vbox vm11.vmdk

Next go to your VirtualBox GUI (original VirtulBox GUI or phpvirtualbox) and click on New:

Click on Next>> in the Create New Virtual Machine wizard:

Specify the name of the new VM and select the same operating system and version as used by the original VM:

Specify the clone's memory:

On the Virtual Hard Disk screen, select Use existing hard disk and click on the Choose a virtual hard disk file icon:

Select the vm11.vmdk file and click on OK:

Click on Next>>:

Click on Create:

Before we start the clone, you might want to adjust some settings, for example if the original VM uses bridging, you might want to select bridging for the clone in the network configuration as well:

Now click on Start to start the clone:

During boot, you will probably notice that the network configuration hangs:

This happens because VirtualBox has assigned a different MAC address for the interface eth0 to the clone, but the clone's /etc/udev/rules.d/70-persistent-net.rules file still uses the original MAC address. After booting has finished, log into the clone and run...

ifconfig

... and you will see that eth0 is missing (because of the MAC address problem), which means the clone cannot use networking:

To fix the problem, open /etc/udev/rules.d/70-persistent-net.rules in the clone...

vi /etc/udev/rules.d/70-persistent-net.rules

... and comment out the eth0 (and also the eth1 line which was added during boot because eth0's MAC address was wrong) line. This makes sure that during the next boot, the system will add a new eth0 line with the correct MAC address.

Now reboot the clone. After the reboot, its networking should work, and you should see eth0 in the output of

ifconfig

Congratulations, you have successfully cloned a VM without shutting down the original VM.

 

4 Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Rolf Fokkens (not registered) on Sat, 2012-07-28 10:03.
With the same LVM concepts in mind I wrote BDsync (bdsync.rolf-fokkens.nl) to make a network backup, so BDsync may be useful for VirtualBox users.
Submitted by Andrew McGlashan (not registered) on Thu, 2012-07-26 14:43.

The above is all well and good, so long as the backup / restore can survive running processes during the backup -- particularly database processes.

I prefer to create a snapshot immediately after shutting down the VM and then once the snapshot has been created, to restart the VM and backup using rsync via the snapshot.  Then with a fully consistent backup, I also dump the filesystem (unmounted of course).

Submitted by Rolf Fokkens (not registered) on Sat, 2012-07-28 10:09.

For application software it's like the server rebooted after an unexpected crash (e.g. powerfailure). If the software cannot survive such a crash, this way to make a backup may not be useful for the software.

One detail I'm not sure of: as a KVM user I make sure that all caching is 'writethrough' to make sure that the data the guest writes to (virtual) disk is actually written to disk. I'm not an expert VirtualBox user, but I'm sure this kind of caching is important for VirtualBox guests as well.

Submitted by affinity (not registered) on Wed, 2012-08-08 20:37.
You need to understand how databases work, they operate with on disk data as well as in memory data (data not yet written to disk); also, you cannot rely on file systems to write everything to disk.  A cleanup shutdown, snapshot and startup is much safer.