On Thu, Jan 16, 2025 at 16:48:59 -0000, camccuk--- via Users wrote: > Hello all > > Apologies for the basic nature of the question, but having recently started working with libvirt - and virtualisation in general - I find there is a lot of out-of-date and sometimes contradictory material out there across blogs, articles, stackoverflow, the usual sources... I thought I might be able to get definitive answers here. For the record, I assume libvirt.org is authoritative but while there is a lot of material there, its structure is not always clear to me. Also the lack of dates on any pages leaves some room for doubt. > > I am wondering if there is a recent, reliable summary of the various approaches and current best practices for backing up VMs that covers snapshots both internal and external, approaches that use backup-begin and third-party approaches which simply stop the VM and copy off files. > > If there is not such a summary, can anyone confirm my reading of https://libvirt.org/kbase/domainstatecapture.html that a simple backup-begin <domain-name> will: That document is mostly accurate but it was created before the actual implementation of backups was finished so some things were not actually implemented in the end. > - pause the VM and quiesce the disk (in which case is qemu agent a requirement on the guest?) The disk quiescing is not part of the backup operation and needs to be done manually via 'virsh domfsfreeze' if required. The original intention was to mirror the snapshot code which does disk quiescing but it's a bit problematic to fold all operations into one so here we didn't do it. Also the backup operation doesn't actually (need to) pause the VM. It can create a point in time backup/copy of the disks without pausing the VM at all. You can even thaw/un-quiesce the disks right away the backup operation starts/while it's running. > - generate a date-suffixed disk-only copy of a VMs disks alongside the originals wherever that storage is Yes if you don't override the path in the XML the backup images will be stored in the same path with a suffix of the UNIX timestamp of the time when it was started. > - not generate any backing image chains or metadata that needs to be retained By default a full backup creates a stand-alone image. If you'd use incremental backups, then it is actually creating images that depend on each other. > > Furthermore, is it then possible to restore to that point by stopping a VM, and associating that backup file with the VM either by virsh-editing its xml or overwriting the original file with the backup file. Yes it is. Note though that since the VM was likely running at the point when you took the backup the 'restore' operation will look like a cold-boot after a power failure at the exact time when the backup was taken. > > This seems to be my experience in testing this, but there are very few references to this tool compared to the many lengthy discussions about snapshots and other approaches which is a bit puzzling. It would be great to have this understanding confirmed or refined! Snapshots also allow you to capture memory state and also pre-date backups thus they are documented a bit more in depth.
