2

I'm trying to understand how the write happens with a VM. It looks like running one is not blocked while copying it for a backup. Will the copy contain any modified files like the boot log? Or will it just copy from a 'shadow copy' like on Windows?

The reverse question could be asked, as in, what happens if I start copying while a VM is open. I would guess the mechanics are similar. Would it change the copied file if changes are made during the copy process? My current guess is that only if files are changed that havent been copied yet. I've tested a VM copied this way and it had no noticeable brokenness, but I can image if a file is changed that relies on another file that is already copied to be different to operate, then it could break things.

So corollary question is, are there files such as this that change during while the VM is running but not being actively used? I might assume running apt upgrade would be a bad idea, but I'm wondering if I can make a backup with little to no risk, while the VM is just open and running idle.

I'm using virt-manager, but I would guess the answers depend more on the image file type qcow2 versus raw more than the VM host software. I'm also wondering if qcow2 has advantages or disadvantages versus a raw image in this regard.

alchemy
  • 537
  • 5
  • 16

1 Answers1

2

You will get an inconsistent filesystem state but there is a solution with QCOW2 disk images. Run the QEMU Guest Agent (qemu-ga) service in the guest OS if you want to trim the disk in the first step (is often pre-installed).

  1. You can begin with trimming the guest disk (optional).

    virsh domfstrim $vmname

  2. Create a temporary snapshot for disk writes during the backup.

    virsh snapshot-create-as $vmname --no-metadata $snapname --disk-only --quiesce --atomic

    You might want to use --diskspec too. See man virsh.

  3. Copy the original QCOW2 disk image for backup (writes are going to the temporary disk image $snapname).

  4. Commit the temporary disk image when the backup has finished.

    virsh blockcommit $vmname vda --wait --active --pivot --delete

    Or if --delete still isn't implemented and the temporary disk image lingers.

    virsh blockcommit $vmname vda --wait --active --pivot
rm /var/lib/libvirt/images/<diskimage>.$snapname

    Replace vda with sda depending on storage type.

Patrik Lundquist
  • 69
  • 7
  • Great, thank you! Couple questions to clarify: So `qemu-qa` fixes the Guest.. then youre saying to save the new changes (unwritten to the second qcow2) in a snapshot, and then commit them to while keeping a third backup copy, did I get that right? – alchemy Aug 11 '22 at 04:43
  • Tried to clarify the answer. The trick is that the writes are going to $snapname while you are backuping the disk image so you are copying a filesystem in a consistent state. `--pivot` merges the wites in $snapname back to the main disk image. `--delete` wasn't implemented a couple of years ago when I set up my backups. – Patrik Lundquist Aug 12 '22 at 06:53