Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I can't find any good info on backing up qcow2 kvm guests. I'm not really interested in the guests running state, only the file system. This question suggests using savevm but that creates a snapshot in place. I'd like to backup the filesystem remotely.

Is there a better way than:

  1. suspend virt_machine # pause virtual machine
  2. rsync --sparse /home/vm/image.qcow2 /tmp/image.dec_14_2010.qcow2 # copy the image on the same drive
  3. resume virt_machine
  4. rsync --sparse /tmp/image.dec_14_2010.qcow2 ssh://backup@backupmachine:/vmbackups

There are a couple of downsides to this. First, copying a huge image file takes a (relatively) long time. Secondly, I must always make sure that I have enough space to backup my machines. This is not ideal. Are there any other better ways of managing KVM backups?

Thanks.

share|improve this question

4 Answers 4

I would suggest qemu-nbd's snapshot feature:

qemu-nbd --snapshot --connect=/dev/nbd0 image.qcow2

then mount /dev/nbd0p1 (partition 1), rsync, unmount and finally disconnnect:

qemu-nbd --disconnect /dev/nbd0

share|improve this answer

Dirty image with this (your pause can probably help, but still might not be fully consistent):

Do a snapshot on LVM file system holding the qcow2 sparse file (again assuming you have room for the LVM snapshot)

Mount the LVM snapshot.

Mount the remote using sshfs.

Copy to the sshfs mountpoint using sparse copy (cp --sparse=always src dest)

Less time to copy, but still will take up to the full time if the image is mostly full.

Backups of data from within the VM are probably a better idea (less space / time). Treat the individual vm's as regular hosts to be backed up / restored - i.e. just get what you need and keep a set of stub vm's without the data to get back up and running fast.

share|improve this answer
    
Interesting, thanks. I dont have LVM on top of my filesystem, for simplicity. I'd prefer to copy the whole image because that would allow me to have a stand-by failover ready to go in case the machine fails at any point. –  EightyEight Dec 14 '10 at 17:11
1  
No problem. The LVM would just save you from having to pause the VM and allow you to snapshot wile it continued to run. –  ax25 Dec 14 '10 at 17:19

No matter where you do the snapshot - LVM or qcow2, the VM still needs to be quiesced before you take it. Otherwise you get lost data and corrupted images.

share|improve this answer
    
no more so than you would if you pulled the power cord though? –  Jack Douglas May 21 '12 at 9:43
1  
no more, and no less of course :) –  dyasny May 21 '12 at 10:12
    
thinking about this some more, quiescing the domain does not add anything - either way the snapshot is 'crash-consistent', nothing more, nothing less, am I right? –  Jack Douglas May 21 '12 at 11:23
    
errr, define "crash-consistent". The guest OS might have some in-flight data destined for the v-disk, that will be lost if you pull the plug. Theoretically, this data might get written to the snapshot after it is taken live, but there is a good reason live snapshots in all virt platforms include quiescing/thawing in the guest agents. Moreove, if the data is not lost, it will still end up in the snapshot instead of the base image, which defeats the purpose of PIT –  dyasny May 21 '12 at 11:58
    
"crash-consistent" just means "as consistent as you would expect in a crash" iiuc - ie relying on journals etc and accepting some data loss due to lack of timely fsync. "there is a good reason live snapshots in all virt platforms include quiescing/thawing in the guest agents" as I understand, the good reason is exactly the same as taking an LVM snapshot - do you know different? KVM doesn't seem to fsync before quiesce any more than an LVM snapshot would? Of course, if you are not using LVM for snapshotting, you'd be foolish not to quiesce - but that is different and not what you are saying. –  Jack Douglas May 21 '12 at 12:33

Personally, I've had a VERY difficult time with this issue and have found that, even when quiesced, the guest backups were often flaky. Remember -- if you are not regularly trying to restore these backups, you really have no idea if they work.

After a lot of experimentation, I punted on image backup entirely and went with a traditional network backup solution that one might use for bare metal servers. In my case we went with BackupPC, which is old, but super reliable. On each server, I configured the backup solution for the particular application(s) in use. For example sqldump for MySQL, plugin for Joomla, etc.

It's a PIA, but it is far faster, and very reliable.

share|improve this answer
    
Thanks @hdave. I feel like with this approach I'm losing out on one of the primary benefits of VMs, containment. To restore, I'd have to reinstall everything manually and configure. Not really the approach I want to take. However, thanks anyway, it's a valid technique. –  EightyEight Aug 14 '12 at 15:09
    
100% agree that it is a royal pain. If you ever crack this nut, let us all know how you did it! –  hdave Aug 14 '12 at 15:21
    
@EightyEight: I highly recommend a configuration management software like Chef or Puppet. It’s much more flexible and also less painful if you want to set up an identical second server (physical or virtual, doesn’t matter). Chef has plugins for almost all hypervisors and can help you to provision & configure a host. This way you have the benefit of using less space for backups (a whole VM is bigger compared to specific data sets) and a faster deployment time in new environments. Furthermore CM is like infrastructure documentation in code. –  Rafael Aug 23 at 11:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.