How to Back Up KVM Virtual Machines: 5 Methods (Live & Incremental)

A KVM virtual machine consists of an XML definition managed by libvirt and one or more virtual disks, usually qcow2 or raw files. Backing it up means saving both. You can do this with built-in tools such as virsh and qemu-img, either with the VM shut down or, with the right method, while it keeps running. Platforms built on KVM, such as Proxmox VE, oVirt, Red Hat Virtualization and Oracle Linux KVM, add their own tools on top.

Quick answer: To back up a running KVM VM, create an external disk-only snapshot with virsh snapshot-create-as --disk-only, copy the now read-only base disk, and merge the snapshot back with virsh blockcommit --active --pivot. On libvirt 6.0 or later, you can instead run virsh backup-begin, which also supports incremental backups of qcow2 disks through checkpoints. Always save the VM definition with virsh dumpxml as well.

Method 1: Take a KVM Snapshot Before Risky Changes

A KVM snapshot saves the state of a VM, optionally including its memory, so you can roll back quickly, for example before installing updates. By default, virsh snapshot-create-as creates an internal snapshot stored inside the VM’s own qcow2 file.

A snapshot is not a backup: it lives on the same disk as the VM, so if that disk or storage fails, you lose the VM and its snapshots together. Long chains of snapshots also slow down disk performance. Use snapshots for short-term rollback, and delete them once you no longer need them.

Creating snapshot backup in KVM environment needs virsh command. Just type the command below,

virsh snapshot-create-as domain snapshot-name

Domain is the name of the KVM VM, and snapshot-name is the name you give to the snapshot.

To check the list of KVM VM snapshots, type the command below:

virsh snapshot-list domain

To restore VM from KVM VM snapshot, type the command below:

virsh snapshot-revert domain snapshot-name

To delete one KVM VM snapshot, type the command below:

virsh snapshot-delete domain snapshot-name

Method 2: Cold Backup of a KVM VM with virsh

The simplest full backup copies the VM’s definition and disks while the VM is shut down, so the copy is guaranteed to be consistent.

1. Shut down the VM and confirm it’s off:

virsh shutdown vm1
virsh domstate vm1

2. Save the VM definition:

mkdir -p /backup/vm1
virsh dumpxml vm1 > /backup/vm1/vm1.xml

3. Find and copy the disks:

virsh domblklist vm1
cp --sparse=always /var/lib/libvirt/images/vm1.qcow2 /backup/vm1/

Replace the path with the one shown by domblklist, and repeat for every disk. --sparse=always keeps the copy from taking up unused space.

4. Start the VM again:

virsh start vm1

Restore: copy the disk files back to their original paths, then register the VM and start it:

cp --sparse=always /backup/vm1/vm1.qcow2 /var/lib/libvirt/images/
virsh define /backup/vm1/vm1.xml
virsh start vm1

To restore on another KVM host, use the same steps there. Make sure the disk paths, networks and storage pools in the XML file exist on that host, or edit the XML before running virsh define.

Method 3: Live Backup with External Snapshots and blockcommit

This method backs up a running VM on any recent libvirt version. You create a temporary overlay file that receives all new writes, copy the original disk while it’s no longer being written to, then merge the overlay back.

1. Check the current disks:

virsh domblklist vm1

2. Create an external, disk-only snapshot:

virsh snapshot-create-as --domain vm1 --name backup-snap --disk-only --atomic --no-metadata --quiesce

--quiesce flushes the guest file systems for a consistent backup and requires the QEMU guest agent inside the VM. Remove it if the agent isn’t installed. Run virsh domblklist vm1 again: the VM now writes to an overlay file such as vm1.backup-snap.

3. Copy the original disk, which is now read-only:

mkdir -p /backup/vm1
cp --sparse=always /var/lib/libvirt/images/vm1.qcow2 /backup/vm1/
virsh dumpxml vm1 > /backup/vm1/vm1.xml

4. Merge the overlay back into the original disk and switch the VM back to it:

virsh blockcommit vm1 vda --active --pivot --verbose

5. Confirm with virsh domblklist vm1 that the VM uses the original disk again, then delete the overlay file shown in step 2.

Repeat steps 2–5 for each disk if the VM has more than one (vdb, vdc and so on). Restore the same way as in Method 2. In the restored XML file, check that the disk path points to the original disk, not the overlay.

Method 4: Native Full and Incremental Backup with virsh backup-begin

libvirt 6.0 and later, with QEMU 4.2 or later, include a built-in backup API. It backs up running VMs without manual snapshots, and with checkpoints it can perform incremental backups that copy only the blocks changed since the last backup. Incremental backups require qcow2 disks.

Check your versions first with virsh version.

1. Create the definition files for a full backup with a checkpoint. backup-full.xml:

<domainbackup>
  <disks>
    <disk name='vda' type='file'>
      <target file='/backup/vm1/vda-full.qcow2'/>
      <driver type='qcow2'/>
    </disk>
  </disks>
</domainbackup>

checkpoint-1.xml:

<domaincheckpoint>
  <name>cp1</name>
</domaincheckpoint>

2. Run the full backup and wait for it to finish:

virsh backup-begin vm1 backup-full.xml checkpoint-1.xml
virsh domjobinfo vm1 --completed

3. For the next backup, run an incremental backup based on cp1. backup-incr.xml:

<domainbackup>
  <incremental>cp1</incremental>
  <disks>
    <disk name='vda' type='file'>
      <target file='/backup/vm1/vda-incr-1.qcow2'/>
      <driver type='qcow2'/>
    </disk>
  </disks>
</domainbackup>

Create checkpoint-2.xml with the name cp2, then run:

virsh backup-begin vm1 backup-incr.xml checkpoint-2.xml

Each run copies only the blocks changed since the named checkpoint. List checkpoints with virsh checkpoint-list vm1.

Restore: an incremental file contains only changed blocks. Rebuild the disk by linking each incremental file to the previous backup and merging the chain into a new image:

qemu-img rebase -u -b vda-full.qcow2 -F qcow2 vda-incr-1.qcow2
qemu-img convert -O qcow2 vda-incr-1.qcow2 vda-restored.qcow2

Because this method involves several XML files and manual chain management, most teams wrap it in scripts or use backup software for production.

Method 5: Back Up KVM-Based Platforms with Vinchin Backup & Recovery

Native commands work, but scripting snapshots, checkpoints and restores for many VMs quickly becomes hard to maintain. Vinchin Backup & Recovery provides agentless backup for KVM-based platforms, including Proxmox VE, oVirt, Red Hat Virtualization and Oracle Linux KVM (native standalone KVM is not supported at present). It backs up running VMs and manages full, incremental and forever-incremental backups from one web console.

Here is an example of backing up a Proxmox VM:

1. Go to VM Backup > Backup, expand the Proxmox VE inventory, and select the VMs to back up.

2. Select the target node and storage for the backups.

3. Configure the backup strategies. Under Schedule, select Backup as scheduled, set a Full Backup schedule (for example weekly), and add an Incremental Backup schedule (for example daily). To save even more storage, choose Forever Incremental Backup, which takes a full backup only once. You can also enable Speed Kit to speed up incremental backups, plus compression, deduplication and a retention policy.

4. Review the settings and click Submit. Jobs then run automatically, and you can follow them in Monitor Center.

Each backup creates a restore point you can use to restore the whole VM, recover individual files, or migrate the VM to another platform.

Things need to be modified:

1. Metadata

Change vm_name into vm_name_backup

2. UUID

Modify any number to make it distinct from the original one

3. virtual disk label

Change the directory into the new one

4. VNC port

VNC port should be unique

To register VM, type the command below:

# virsh define /etc/libvirt/qemu/vm-name_backup.xml
# virsh start vm_name_backup

How to Clone KVM VM With Virt-Clone?

Virt-clone is the command line tool for KVM VM clone. Before you use it to clone VM, make sure the guest is powered off.

For instance, if you have a QEMU VM in Red Hat Virtualization environment, and its name is demo, type the command below to clone it:

# virt-clone --connect qemu:///system --original demo --name newdemo --file /var/lib/libvirt/images/newdemo.img --file /var/lib/libvirt/images/newdata.img

If you would like to perform a simple automatic clone, type the command below:

# virt-clone --original demo --auto-clone

Here shows a table of comparison of the three native KVM backup methods:

Native KVM tools are flexible, but manual operations can become complicated in large environments.

Easily Backup and Restore VMs on KVM-Based Platforms

It might take a long time to backup VMs on the native KVM but you can have a better solution to backup VMs on KMV-based platforms. Vinchin Backup & Recovery is a professional backup and disaster recovery solution for KVM-based platforms, like Prxmox, oVirt, Oracle Linux KVM, Red Hat Virtualization, oVirt, etc. (Native KVM is not supported for now)

All the VM backup and restore job configurations are completed with wizards in a user-friendly web console. You just need to add the host into Vinchin backup server, and then you can make backup of any VMs on the host agentlessly.

Besides, Vinchin Backup & Recovery will also help manage heterogeneous virtual environment by allowing you to move VM between different virtualization platforms.

Here is an example of backing up Proxmox VM:

1.  Navigate to VM Backup > Backup, expand the Proxmox VE inventory tree, and select the KVM host as the backup source.

2. Select the target node and storage device to set the backup destination.

3. Customize the backup strategies, choose to either start the backup task immediately or schedule it daily, weekly, or monthly using incremental, full, or differential backup methods.

4. Check the backup details and click Submit once confirmed they are correct.

You can try this solution with a 60-day full-featured free trial. It just takes a few minutes to deploy in your virtual environment.

KVM Backup Best Practices

1. Back up both disks and XML. A disk without its VM definition is hard to restore quickly.

2. Use consistent backups. Shut down the VM, or install the QEMU guest agent and use --quiesce, so applications and file systems are in a clean state.

3. Combine full and incremental backups. For example, take a weekly full backup and daily incrementals to save time and storage.

4. Keep backups off the host. Copy them to another server, NAS or cloud storage, so a host failure doesn’t destroy both the VM and its backups.

5. Clean up snapshots. Don’t leave overlay files or old snapshots in place, because they slow down VMs and fill up storage.

6. Test restores regularly. Restore a VM to a test host on a schedule to confirm your backups work.

KVM Backup FAQs

1. Can I back up a KVM VM while it’s running?

Yes. Use an external snapshot with blockcommit (Method 3) or virsh backup-begin (Method 4). Install the QEMU guest agent in the VM so the backup can quiesce the file systems.

2. Does KVM support incremental backup?

Yes. With libvirt 6.0 or later, virsh backup-begin uses checkpoints to back up only the blocks changed since the last backup, which works for qcow2 disks. Backup software for KVM-based platforms also provides incremental and forever-incremental backups.

3. Is virt-clone a backup tool?

No. virt-clone creates a new VM with a new name, UUID and MAC address from a powered-off VM. It’s useful for duplicating VMs, but a clone isn’t kept as a restorable backup, and it doesn’t support versioning or incremental copies.

4. Can you automate KVM backup?

Yes. Run backup scripts from cron, or use backup software that schedules jobs, applies retention policies and alerts you on failures.

5. How often should you back up KVM VMs?

It depends on how much data you can afford to lose. A common schedule is a weekly full backup and a daily incremental backup. For critical workloads, consider continuous data protection.

6. What should I do if backup storage is almost full?

Expand the storage, or delete old restore points you no longer need. A backup retention policy removes outdated backups automatically.

7. How do I verify that a KVM backup works?

Check that the job completed without errors, then test the backup by restoring it to a test host. Vinchin Backup & Recovery can also verify VM backups automatically in an isolated environment.

8. Can I restore just files from a KVM backup?

Yes. Native qcow2 backups can be mounted with guestmount (from libguestfs) to copy individual files. Vinchin’s granular restore also extracts files directly from VM backups.

Conclusion

You can back up KVM virtual machines with built-in tools: snapshots for quick rollback, a cold copy with virsh and cp, live backups with external snapshots and blockcommit, and native full and incremental backups with virsh backup-begin. Whichever you choose, save the VM’s XML along with its disks, and test your restores.

For KVM-based platforms such as Proxmox VE, oVirt and Red Hat Virtualization, Vinchin Backup & Recovery automates scheduled full and incremental backups and restores from one console. Try it free for 60 days.