libvirt storage pools and qcow2 snapshots are not a backup

What it is

libvirt's snapshot XML format describes a point-in-time state of a domain's disks (and optionally memory). virsh snapshot-create-as <domain> <name> creates one without hand-writing XML. With QEMU and qcow2 disks, a snapshot without --disk-only or an external --memspec/--diskspec is normally an internal snapshot: the snapshot data is stored inside the same qcow2 file as the guest's current state (the same qcow2 feature qemu-img snapshot works with). An external snapshot (for example --disk-only) instead turns the current file into a read-only backing image and starts a new overlay file that receives all later writes; the overlay holds only the differences against its backing file, which is what makes it small and fast to create. Check what you got with virsh snapshot-dumpxml <domain> <name> (snapshot='internal' or 'external').

Why it matters

An internal snapshot is a second version of the data multiplexed into one file. If that qcow2 file is truncated, its header corrupted, or the underlying storage device fails, the current state and every internal snapshot are lost together — there is no independent copy. External snapshots at least separate the base image from later writes, but the base image is still a single file on the same storage the guest depends on; neither form protects against deleting the wrong file, losing the storage pool, or a hypervisor-wide failure. A snapshot is a rollback point, not a copy held elsewhere.

How to apply

• Create an internal snapshot for a quick pre-change rollback point: virsh snapshot-create-as guest1 pre-upgrade --description "before package upgrade".
• List and revert: virsh snapshot-list guest1, virsh snapshot-revert guest1 pre-upgrade. Reverting is destructive: everything written since the snapshot is lost. Deleting external snapshots with virsh needs libvirt 9.0 or later and reverting to them 9.9 or later; older versions refuse.
• Delete snapshots you no longer need (virsh snapshot-delete guest1 pre-upgrade); accumulated internal snapshots keep old clusters allocated and grow the qcow2 file.
• Inspect the image: qemu-img info -U /var/lib/libvirt/images/guest1.qcow2 shows format, virtual size, backing file and internal snapshots (-U/--force-share is needed while a guest holds the image lock). Run qemu-img check only with the guest shut off; the qemu-img manual warns never to modify an image in use and that querying one may show inconsistent state.
• For an actual backup, copy the disk image (or its exported content) to separate storage or another host, in addition to any snapshot.

Pitfalls

• Treating virsh snapshot-create-as output as proof of a safe rollback; it only protects against mistakes inside the guest, not against the image being lost.
• Letting internal snapshots pile up (the qcow2 file keeps growing), or using qemu-img snapshot (or any other modifying qemu-img command) on the image of a running guest — that can destroy the image; use virsh while the guest runs.
• Forgetting the memory state: a --disk-only snapshot captures disks but not guest RAM, so reverting yields a crash-consistent state like after a power loss unless the filesystems were quiesced (--quiesce, which needs the guest agent).