A VM snapshot records a recoverable point within a particular virtualization and storage arrangement. It can help with a short maintenance rollback, but often depends on the same disks and host as the live VM. Treat it as one recovery mechanism, not the entire backup strategy.
IN THIS ARTICLE
Information to have ready
Identify whether the snapshot includes disks, memory or both, and whether it is internal or uses an external backing chain. Confirm platform support, free storage and application-consistency requirements. Record an independent backup before a risky change.
01 Check snapshot coverage and recovery requirements
- Inspect the existing snapshot and disk-chain inventory through the managing platform. Understand which files and metadata are required to return to the selected point.
- Choose a clearly named snapshot immediately before the intended change and record its purpose and expiry. Use the supported quiescence or shutdown workflow when the application requires it.
- Perform the maintenance and validate the guest. Keep the rollback decision within the period where losing post-snapshot writes is acceptable.
- If reverting is necessary, stop conflicting application activity and consider external systems that cannot be rolled back with the disk. Restore through the supported platform action.
- After acceptance, remove or consolidate obsolete snapshots with the platform-supported process. Monitor space and task progress while the chain is consolidated.
02 Example: inventory VM snapshots without deleting or reverting them
On a libvirt host you administer, inspect snapshots associated with the guest. Replace VM_NAME with the actual domain. These commands list snapshot metadata and current disk mappings; they do not create, merge, delete or revert a snapshot.
sudo virsh -c qemu:///system snapshot-list VM_NAME --tree
sudo virsh -c qemu:///system domblklist VM_NAME --detailsRead the result: Compare the snapshot history with the actual storage and backup records. Snapshot metadata managed elsewhere may not appear in this list, and a visible snapshot can still depend on base images on the same failing storage. Its existence does not prove there is an independent, recoverable backup.
Confirm which layers and application data the snapshot captures, and test a separate recovery procedure. Do not manually delete a backing image to reclaim space. Chain consolidation and snapshot removal need the supported platform workflow and enough temporary capacity to complete safely.
What happens to changes made after reverting?
The restored guest returns to the selected state, so later local changes can disappear. External transactions, emails and other systems are not automatically reversed and may need reconciliation.
Check the backup or recovered data
Confirm the current guest state, disk chain and application data match the intended outcome. Check that backup software still recognizes every required disk. Restore an independent backup into an isolated environment to validate protection from host or storage loss.
Troubleshoot unexpected results
If a chain is unclear or a backing file is missing, stop manual file deletion and preserve all remaining components. A file that looks old may still contain essential blocks. Never use qemu-img modification commands against an image actively used by a VM. Obtain a storage-consistent recovery plan before repairing metadata.