If you're using raw image files then the only way to get a consistent snapshot is to suspend or shut down the VM.

You can take a snapshot using qcow2 image files without suspending the VM, but the snapshot becomes part of that file. This may or may not be appropriate, depending on your situation.

You would have more options if you were using a CentOS 7 or current Fedora hypervisor, such as snapshottable LVM volumes or ZFS zvols. On these modern systems you would virsh domfsfreeze the guest, take the snapshot, virsh domfsthaw the guest, and then backup the snapshot. This requires the qemu-guest-agent running in the guest.


Suspending VM-s with virsh suspend <domain> just freezes VM, according to the docs all disk I/O and network I/O are suspended, while VM still consumes host's RAM.

If you have Centos then there's high probability that you aslo have LVM partition there and on top of that an XFS partition. If the statement is true, then you can backup it in the following way:

  • drop cache on VM and suspend it,
  • drop cache on Host and do LVM snapshot,
  • mount LVM snapshot somewhere in the host and do your backup schedule.

It's working for me even with database servers. It's even completely safe to backup fileserver (for instance samba), without drop cache on the host or VM, assuming that kernel parameters on the host and guset are default. Lost of data is minimal. Ext4 for example commits dirty pages in RAM every 5 seconds (default setting). It may lead to data loss what were committed less than 5 seconds before freezing. That amount data loss was acceptable for me.

Every backup method have some drawbacks. Downtime or potential data loss. Many databases administrators suppose to think, that data loss may lead to data corruption when database engine (like MS SQL) obligatory must commit every transaction to the file system before accepting the change. On the other hand they accept to restore data from backup and agree with data loss.