Ok, even though this can be done with many other methods, I’ll explain mine. I’ll also provide youtube videos for the procedure and demonstration as well.
Unlike offline backups, online backups require minimalist suspend – save – resume actions (hopefully within small amount of time – which depends your modifications and RAM usage) while taking the snapshot. The requirement for this suspend has similar reasons to live migration –state is hold and saved then it continues to execute.
As described in our offline backups post, we could take internal or external backups. But in this post we’ll discuss external backups particularly to take backups.
Taking the snapshot and its important features
We have two objectives:
- To be able to take external snapshot file
- To be able to take the snapshot online
virsh is very versatile tool which have commands to accomplish this tasks. There is a very critical difference between online backup and offline backup, it is the memory (RAM) that makes the major difference.
If your snapshot lacks RAM information then your snapshot file will be corrupted, and likely it will run a fsck on startup, but this would be a good case, the worse is if VM is serving a database like MySQL, the database file may be corrupted as well, since RAM is most probably used and dirty for the database instance usage. So to get to a valid backup, RAM must be saved! Without this, backing an online guest will fail (even if it looks like a valid backup).
In short I’ll describe the scenario of backing up process (yours will be %99 same). Then I will give the commands for online external backup.
Assume that your backups are taken with the 1 hour interval. So starting from time 01:00 our first backup file will be named with our commands with the regarding name, in this cases . Below you’ll see the command to take online external backup that also supports taking memory into account. (Note that “burn” is the domain (VM name))
In 01:00 we run the following command:
virsh snapshot-create-as burn snap1-burn snap1-desc --diskspec vda,snapshot=external,file=/home/dede/burn_vda_snap1.qcow2 --memspec file=/home/dede/burn_mem_snap1.qcow2,snapshot=external --atomic
In 02:00 next backup takes place:
virsh snapshot-create-as burn snap2-burn snap2-desc --diskspec vda,snapshot=external,file=/home/dede/burn_vda_snap2.qcow2 --memspec file=/home/dede/burn_mem_snap2.qcow2,snapshot=external --atomic
03:00:
virsh snapshot-create-as burn snap3-burn snap3-desc --diskspec vda,snapshot=external,file=/home/dede/burn_vda_snap3.qcow2 --memspec file=/home/dede/burn_mem_snap3.qcow2,snapshot=external --atomic
04:00:
virsh snapshot-create-as burn snap4-burn snap4-desc --diskspec vda,snapshot=external,file=/home/dede/burn_vda_snap4.qcow2 --memspec file=/home/dede/burn_mem_snap4.qcow2,snapshot=external --atomic
Now we have 4 snapshot files for image changes:
- snap1-burn.qcow2
- snap2-burn.qcow2
- snap3-burn.qcow2
- snap4-burn.qcow2
These files are holding image changes. They holds new writes, deletions or any other file system changes occured to the base image.
And we also have 4 memory files. These memory files holds complete memory of the VM. You may expect more snapshot will be written for the memory if you have a big memory allocated VM. As a quick note: you had better consider using a SSD storage to save memory snapshots, which enables quicker online external backups.
- burn_mem_snap1.qcow2
- burn_mem_snap3.qcow2
- burn_mem_snap4.qcow2
In command we define image backup with its path starting with “/home/dede”, dede is the user name. To take memory snapshot we define snapshot file with “–memspec”.
What are these files now?
These files are holding the complete difference between base image and the snapshot. So, there is no connection between snap1-burn and snap2-burn. But we expect some similarities off course.
Memory snapshot is similar, It has not to be similar chained memory snapshots. They holds the memory. But we expect similarities between chained snapshots if memory layout is not changing very much.
Maintaining the backup file chain
Having with these 8 snapshot files (4 image, 4 memory), you will see a 24 image and 24 memory snapshot in the end of day. This is a long snapshot chain. System admin can decide how many snapshot file to keep, but I think hourly, daily and monthly golden backups should be kept for the backup process.
In this tutorial I’ll explain how to maintain backup chain (snapshot chain) to have a short one. For example, you can merge snapshots of two backup into one backup with following command.
virsh blockcommit --domain burn vda --base /VMs/kvm_vms/burn.qcow2 --top /home/dede/burn_vda_snap1.qcow2 --wait --verbose
This command will merge changes of “burn_vda_snap1.qcow2” into base image “burn.qcow2”. After this command, your base image will contain changes of burn_vda_snap1.qcow2.
Important note: With utilizing online backups, it is NOT enough to have vm image file (burn.qcow2) only. But you also need memory snapshot of the corresponding VM image snapshot, in this case: burn_mem_snap_1.
After this command burn.qcow2 will be merged with its snapshot and the snapshot is no longer needed, but memory snapshot should be kept as described above. So, this backup’s image file (burn_vda_snap1.qcow2) can be deleted. This can be repeated to maintain snapshot chain.
To take our example in this post, following scenario can be seen.
At 02:00, we merge snap1 into base image and keep snap1’s memory snapshot file. After a successful merge snap1’s image snapshot can be deleted (do not confuse memory snapshot, it should be kept!!!). Remember that at 02:00 we’re also creating new snapshot (snap2 and snap2’s memory snapshot). After the following command completed and its image snapshot file deleted you’ll have 4 files:
- burn.qcow2
- burn_mem_snap1.qcow2
- snap2_burn.qcow2
- burn_mem_snap2.qcow2
Notice that we’ve deleted snap1_burn.qcow2, as we no longer needed it.
virsh blockcommit --domain burn vda --base /VMs/kvm_vms/burn.qcow2 --top /home/dede/burn_vda_snap1.qcow2 --wait --verbose
At 03:00 we run the following command:
virsh blockcommit --domain burn vda --base /VMs/kvm_vms/burn.qcow2 --top /home/dede/burn_vda_snap2.qcow2 --wait --verbose
This command merges snap2’s image snapshot into base image. After this command, you can also delete snap2’s image snapshot and snap1’s memory snapshot. But this time, snap2’s memory snapshot should be kept. You should have below files:
- burn.qcow2
- burn_mem_snap2.qcow2
- snap3_burn.qcow2
- burn_mem_snap3.qcow2
At 04:00 you run below command to take similar actions described before:
virsh blockcommit --domain burn vda --base /VMs/kvm_vms/burn.qcow2 --top /home/dede/burn_vda_snap3.qcow2 --wait --verbose
So this procedure can be applied to have small backup/snapshot chain, and to have online external backups.
As described before, you can keep a golden backup for each day, month and year. Daily incremental backups can also be taken with this method.
Return from snapshot
To return snapshot virsh command will be used. Below command will restore snapshot. Virsh will find true related files to restore the snapshot.
virsh restore <file>
For example:
virsh restore snap3_burn.qcow
will bring you the VM’s 03:00 state (whole online state).
When I add youtube demonstration, I’ll update the post.
note to self 