13

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.

Community
  • 1
EightyEight
  • 303
  • 1
  • 2
  • 11

4 Answers4

7

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

phhe
  • 321
  • 1
  • 3
  • 6
5

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.

ax25
  • 231
  • 1
  • 2
  • 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
3

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.

Dave
  • 577
  • 1
  • 8
  • 18
  • 1
    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! – Dave 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 Bugajewski Aug 23 '14 at 11:22
2

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.

dyasny
  • 18,482
  • 6
  • 48
  • 63
  • no more so than you would if you pulled the power cord though? –  May 21 '12 at 09: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? –  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. –  May 21 '12 at 12:33
  • nothing to do with kvm vs lvm here, snapshot is a frozen situation of a point in time (PIT), which it will not be if you don't quiesce (or power down completely) before taking the snapshot. As for actually doing it, take a look at http://wiki.qemu.org/Features/Snapshots - thaw is right in there. – dyasny May 21 '12 at 13:39
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/3505/discussion-between-jack-douglas-and-dyasny) –  May 21 '12 at 14:37