KVM Snapshot/Backup Script
-
What if the original VM disk (.qcow2) was destroyed or lost (say failure). Could the VM be recreated from that said snap taken? (Restored from snap save location)
Snapshots would not work if the base file is written to or doesn't exist.
As @stacksofplates responded
the snapshot only lives long enough to copy the disk to the specified location and is then merged back into the original disk. Here's what it would look like using a disk called vm-test.qcow2.
Think of the process as cloning the original disk without shutting down the vm, the snapshot is just temporal ceases to exist once the original file is copied.
As most snapshots will take larger space on the originating VM storage location. Have snaps offloaded to a NFS Share -- less expensive storage than the originating VM location
-
Right, we aren't copying the snapshot, we are copying the disk before the snapshot was taken. Then the snapshot is blockcommitted back into the original.
-
@ntoxicator said in KVM Snapshot/Backup Script:
What if the original VM disk (.qcow2) was destroyed or lost (say failure). Could the VM be recreated from that said snap taken? (Restored from snap save location)
Yes, the saved disk (not the snapshot) can be copied back to the normal image directory and you can start the VM again.
This is assuming you are using images and not block storage. If you've just mounted the LUN through the hypervisor and are using block storage, this won't work. If you've mounted the LUN to a directory and created a file system on it to store images, then this will work.
-
@ntoxicator when you grab a snapshot on libvirt/kvm is like if you grab a snapshot in LVM or ZFS: the snap is a (tempeorary) log of changes since it was taken (usually, but not necessarily a COW). it is used to allow the freeze of the data at a given time, infact the actual VM disk is not written anymore, but the snapshot is.
when you have done with the processing of the VM disk (whatever this working on is) you re-merge back the snapshot (you commit it) so that the actual VM disk gets all the write changes occurred between the snapshotting and the processing of the VM disk.
this ensures that the VM disk doesn't change while you backup it!
**note ** that this not implies that the disk is in a coherent state: it is simply frozen. the fact that the disk is correctly flushed and a proper write barrier is posed on it when snapshotted depends on other factors, which kvm honors via host/guest FS settings.
A brief about barriers is here. Here is a description of what to expect from a KVM/libvirt snapshot. -
@stacksofplates I know this is an old thread but I have a question about this script. Why are you backing up the snapshot? Shouldn't the base image be backed up instead right before the block commit? Therefore, if you want to roll back, you just copy the original base image out of your specified backup directory back over the broken base image and away you go.
Unless I don't understand how external snapshots work, I don't see the purpose holding onto a snapshot AFTER you have committed it. The base image before the commit is the "backup" that's needed.
-
@biggen said in KVM Snapshot/Backup Script:
@stacksofplates I know this is an old thread but I have a question about this script. Why are you backing up the snapshot? Shouldn't the base image be backed up instead right before the block commit? Therefore, if you want to roll back, you just copy the original base image out of your specified backup directory back over the broken base image and away you go.
Unless I don't understand how external snapshots work, I don't see the purpose holding onto a snapshot AFTER you have committed it. The base image before the commit is the "backup" that's needed.
It's not copying the snapshot. This line tars up the disk image in wherever you define for your backup location and names it the snapshot name with the date.
tar -czvf $location/$snap-$today.tar.gz $diskPath -
@stacksofplates Ah ok. I misread the script last night when I was looking it over. I thought since it was renaming it “snapshot” that it wasn’t copying the base image. I missed the $diskpath variable at the top of the script. Thanks for clearing that up!
This is a handy little script. I ended up installing the QEMU guest agent in my VM so I’ll add the “—quiesce” switch to the backup command line. Thanks for sharing this!
-
We are using this, by the way. Just deployed one this past week or so.
