An application-consistent KVM backup coordinates guest data, virtual disks and the application recovery process. A live disk copy can capture blocks while an application is mid-write. Use a supported backup system or an explicitly tested shutdown/quiescence procedure.
IN THIS ARTICLE
What you need before you begin
Inventory every guest disk, firmware/NVRAM dependency, encryption key and configuration needed to recreate the VM. Define recovery objectives and independent storage. Confirm the backup software supports the installed libvirt/QEMU versions and storage backend.
01 Take an application-consistent backup of a KVM guest
- Choose the consistency method. A clean application shutdown and powered-off guest can provide a straightforward maintenance-window baseline. For live protection, use application-native backups or reviewed hooks integrated with the supported snapshot/backup workflow.
- Verify guest-agent communication if the method uses filesystem freeze/thaw. Ensure failure handling always releases a freeze; do not manually leave filesystems frozen throughout a long bulk copy.
- Configure the backup to include all required disks and VM metadata. Record exclusions explicitly, including independent network storage that is not part of the virtual disk set.
- Start one controlled backup and monitor the job until completion. For libvirt backup APIs, follow the installed-version backup XML and job-status documentation rather than copying a live disk file with an ordinary file-copy command.
- Transfer and retain the recovery copy independently, protect its credentials and integrity, and restore into an isolated VM. Test the application and document the recovery duration.
Does filesystem freeze flush every application transaction?
Not necessarily. Filesystem consistency and application consistency differ. Databases can require native backup coordination, transaction logs or application-specific hooks even when the guest agent successfully freezes filesystems.
Check the backup or recovered data
Confirm the restored guest boots with the required virtual hardware and that its databases pass their own integrity or recovery checks. Compare a known recent application record with the intended recovery point. Ensure alerts detect incomplete jobs and retention does not remove the only working full chain.
Troubleshoot unexpected results
If a backup fails, inspect application-hook, agent, host job and destination errors separately. Verify that any quiesced guest resumed normal writes. Preserve existing valid backups and chain metadata. Do not repair an in-use disk image with qemu-img or assume a partially copied file is recoverable.