Integration with KVM VM Snapshots #252
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#252
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I've got a couple virtual machines running using kvm and qcow2 disk images. To get a consistent snapshot of the disk, I basically create a snapshot that creates a new image file that points to the active one, which gets all new writes to the disk. I cp/rsync the now readonly disk to a separate location for backing up. And then I effectively undo the snapshot which merges any changes into the disk image since the process started. This is all handled as a pre backup script shown below (This is close to the script I use, but there is an optimization in my setup that reduce the amount that needs to be copied)
And then I backup the /.backups/vm directory. The nice thing about this is that it entirely runs as a pre backup command which keeps the time that the vm is running against the temporary image to a minimum. A qcow2 image is required I believe for this to work.
I don't currently handle restoration, though it doesn't seem too difficult since you just need to copy the images back to the original location and then load the xml file that is backed up. I haven't yet tried it though, since I just put this code in place.
Again, thank you for filing this! The approach seems fairly different from my understanding of typical filesystem-level snapshots (btrfs, lvm, etc.). There, you create a read-only snapshot for a particular a point in time, without disturbing writes to the normal filesystem. But here, you're saying that with these VM-based qcow2 snapshots, it's effectively making the VM filesystem temporarily read-only until the backup is done and the writes can be merged back? Or am I misunderstanding?
Is there a way to do the qcow2 snapshotting more akin to traditional filesystem snapshotting, where the VM's filesystem is not disturbed and can continue doing writes the whole time?
You mostly have it right, with the caveat that the VM continues to run just fine except its writes are going to a different image file. The qcow2 file format can have a chain of image files where each one is a delta relative to the underlying one (and all the underlying ones are effectively read only). This can be used to create a base image file and have multiple vm's point to the same base image but not need to have a unique copy of all the data. For snapshotting as done in the script, it's useful because you can temporarily create a new image file which points to the active image file while a vm is running. So all new changes go into the new file and the existing image is read only. So I set it up so that it creates this temporary image, and then I copy the existing image out so that I can quickly merge the temporary file into the normal vm iamge and delete the temporary image. (You could just create the temporary file and run the back up excluding the temporary file instead). It just made sense to me to keep the temporary image active for as short of time as possible since there are theoretical performance implications.
Got it. It sounds very similar to the way that Docker images work at this level.
Not just performance.. If I'm understanding all of this properly (which I may not be), then does the VM have a period of time in which any writes it does are inaccessible for read from within the VM? Even if they are merged in / pivoted at the conclusion of backups?