Live backups create-snapshot-as and memspec
Hi all! I've been using libvirt for some time and until now I have treated backups of virtual computers as if they where physical computers installing the backup client on the guest. I am now however facing the need to backup a couple a couple of guest at the host level so I've been trying to catch up by reading, googling and by trial and error too. Up to now I've been able to backup a live machine whith a command like the following
virsh snapshot-create-as --domain test --name backup --atomic --diskspec vda,snapshot=external --disk-only
This command creates a file test.backup and in the meantime I can backup the original test.qcow2 but for what I saw this disk image is in a "dirty" state, as if the machine I could restore from this file had been turned off whithout a proper shutdown. I know that I can later restore the machine to its original state by issuing a command like this
virsh blockcommit --domain test vda --active --pivot virsh snapshot-delete test --metadata backup
I have seen that it is possible to create the snapshot using a memspec parameter which would make the backup of the guest as if it where in a clean state, however I haven't found the equivalent of the blockcommit for the memory file, in a sort of speak, to be able to restore the guest to it's original state. Thank you very much! Best regards. David Wells.
On Wed, Feb 24, 2021 at 14:49:19 -0300, David Wells wrote:
Hi all!
I've been using libvirt for some time and until now I have treated backups of virtual computers as if they where physical computers installing the backup client on the guest. I am now however facing the need to backup a couple a couple of guest at the host level so I've been trying to catch up by reading, googling and by trial and error too. Up to now I've been able to backup a live machine whith a command like the following
virsh snapshot-create-as --domain test --name backup --atomic --diskspec vda,snapshot=external --disk-only
This command creates a file test.backup and in the meantime I can backup the original test.qcow2 but for what I saw this disk image is in a "dirty" state, as if the machine I could restore from this file had been turned off whithout a proper shutdown.
I know that I can later restore the machine to its original state by issuing a command like this
virsh blockcommit --domain test vda --active --pivot virsh snapshot-delete test --metadata backup
I have seen that it is possible to create the snapshot using a memspec parameter which would make the backup of the guest as if it where in a clean state, however I haven't found the equivalent of the blockcommit for the memory file, in a sort of speak, to be able to restore the guest to it's original state.
The memory image file doesn't depend on any other state nor does the VM use it after the snapshot is taken, if you don't need it you can delete it. The disk overlay you create by 'virsh snapshot-create-as' records only differences to the original image, but for memory state it doesn't make much sense as the memory is small and changes a lot, so we take a snapshot of the whole memory. Now to restore the state of a VM to a snapshot taken with memory, libvirt's native APIs for reverting don't work on external snapshots yet. You can use 'virsh restore memimg' to load VM's state as the memory snaphsot images have the same format as images created by 'virsh save'. Please note though that the configuration of the VM is taken from the save image if you do so, which includes paths to disk images, which may no longer be correct or desired, but virsh save-image-edit can be used to modify the XML if needed.
El 25/2/2021 a las 11:37, Peter Krempa escribió:
On Wed, Feb 24, 2021 at 14:49:19 -0300, David Wells wrote:
Hi all!
I've been using libvirt for some time and until now I have treated backups of virtual computers as if they where physical computers installing the backup client on the guest. I am now however facing the need to backup a couple a couple of guest at the host level so I've been trying to catch up by reading, googling and by trial and error too. Up to now I've been able to backup a live machine whith a command like the following
virsh snapshot-create-as --domain test --name backup --atomic --diskspec vda,snapshot=external --disk-only This command creates a file test.backup and in the meantime I can backup the original test.qcow2 but for what I saw this disk image is in a "dirty" state, as if the machine I could restore from this file had been turned off whithout a proper shutdown.
I know that I can later restore the machine to its original state by issuing a command like this
virsh blockcommit --domain test vda --active --pivot virsh snapshot-delete test --metadata backup I have seen that it is possible to create the snapshot using a memspec parameter which would make the backup of the guest as if it where in a clean state, however I haven't found the equivalent of the blockcommit for the memory file, in a sort of speak, to be able to restore the guest to it's original state. The memory image file doesn't depend on any other state nor does the VM use it after the snapshot is taken, if you don't need it you can delete it.
The disk overlay you create by 'virsh snapshot-create-as' records only differences to the original image, but for memory state it doesn't make much sense as the memory is small and changes a lot, so we take a snapshot of the whole memory.
Now to restore the state of a VM to a snapshot taken with memory, libvirt's native APIs for reverting don't work on external snapshots yet.
You can use 'virsh restore memimg' to load VM's state as the memory snaphsot images have the same format as images created by 'virsh save'.
Please note though that the configuration of the VM is taken from the save image if you do so, which includes paths to disk images, which may no longer be correct or desired, but virsh save-image-edit can be used to modify the XML if needed.
Hi all! Peter, thank you very much for your reply! So if I understood correctly there is no way, at this time, to backup a live guest in a way that I can restore it to a "clean" state. Also, if I understood correctly, the probability of a corrupt system on restore of the vm is minimized having the qemu guest agent installed on the guest and issue the virsh create-snapshot-as with the --quiesce parameter, is this correct? Thanks in advance! Best regards, David Wells.
the qemu guest agent installed on the guest and issue the virsh create-snapshot-as with the --quiesce parameter, is this correct?
I am doing a "guest-fsfreeze-freeze" and then create the external snapshot. And for vm's that have databases, do a database dump to local dir, before the snapshot.
On Fri, Feb 26, 2021 at 15:29:45 -0300, David Wells wrote:
El 25/2/2021 a las 11:37, Peter Krempa escribió:
On Wed, Feb 24, 2021 at 14:49:19 -0300, David Wells wrote:
Hi all!
I've been using libvirt for some time and until now I have treated backups of virtual computers as if they where physical computers installing the backup client on the guest. I am now however facing the need to backup a couple a couple of guest at the host level so I've been trying to catch up by reading, googling and by trial and error too. Up to now I've been able to backup a live machine whith a command like the following
virsh snapshot-create-as --domain test --name backup --atomic --diskspec vda,snapshot=external --disk-only This command creates a file test.backup and in the meantime I can backup the original test.qcow2 but for what I saw this disk image is in a "dirty" state, as if the machine I could restore from this file had been turned off whithout a proper shutdown.
I know that I can later restore the machine to its original state by issuing a command like this
virsh blockcommit --domain test vda --active --pivot virsh snapshot-delete test --metadata backup I have seen that it is possible to create the snapshot using a memspec parameter which would make the backup of the guest as if it where in a clean state, however I haven't found the equivalent of the blockcommit for the memory file, in a sort of speak, to be able to restore the guest to it's original state. The memory image file doesn't depend on any other state nor does the VM use it after the snapshot is taken, if you don't need it you can delete it.
The disk overlay you create by 'virsh snapshot-create-as' records only differences to the original image, but for memory state it doesn't make much sense as the memory is small and changes a lot, so we take a snapshot of the whole memory.
Now to restore the state of a VM to a snapshot taken with memory, libvirt's native APIs for reverting don't work on external snapshots yet.
You can use 'virsh restore memimg' to load VM's state as the memory snaphsot images have the same format as images created by 'virsh save'.
Please note though that the configuration of the VM is taken from the save image if you do so, which includes paths to disk images, which may no longer be correct or desired, but virsh save-image-edit can be used to modify the XML if needed.
Hi all!
Peter, thank you very much for your reply! So if I understood correctly there is no way, at this time, to backup a live guest in a way that I can restore it to a "clean" state. Also, if I understood correctly, the
No you misunderstood. Creating an external snaphsot with --memspec in fact creates a state capture which can be completely restored in terms of consistency of filesystems and in-memory data. What currently isn't possible is to use the virDomainRevertToSnapshot API to do so, but there are manual steps which can be taken to do so. Obviously state beyond the VM can't be restored, so network connections existing at the time of the snapshot will be broken.
probability of a corrupt system on restore of the vm is minimized having the qemu guest agent installed on the guest and issue the virsh create-snapshot-as with the --quiesce parameter, is this correct?
Yes that is correct, the filesystem is still mounted but the guest agent ensures that caches were flushed before. AFAIK the guest agent even provides guest-OS side hooks which allow to flush databases and others which are not filesystem bound to have the on-disk state as clean as possible.
participants (3)
-
David Wells -
Marc -
Peter Krempa