On 11/04/2009 06:29 PM, Daniel Berteaud wrote:
Hi.
I cannot answer for the sync when the host is suspended, but I think the
best way is to save your guest (virsh save guest /past/to/backup), take
your snapshot, restore the guest (virsh restore /path/to/backup), then
run the backup (of the snapshot and the saved state file).
I've writtent a script which does exactly that:
http://repo.firewall-services.com/misc/virt/virt-backup.pl
It takes care of:
- saving the guest (or just suspend)
- take the snapshot (if possible)
- restore the guest (or just resume)
- dump the snapshot, and optionnaly compress it on the fly
- cleanup everything when you're done
Regards, Daniel
Wow, what a nice script, thank you. If I understand it right, you also
save the VM state, and any dirty pages are in there. The combo (dd of
snapshots) + (vm state) is a consistent backup of the guest.
The only drawback I can see is that the backup can only be restored by
restoring the whole guest, tho. The filesystem dump(s) alone potentially
are not in a sane state. In order to access the data safely you need to
restore a copy of the guest VM in an isolated enviroment, log in and
shutdown. Then you can access the disk images.
Accessing the files is a kind of requirement if you run bacula. Of
course it can be instructed to backup a single big file, but that
defeats completely the idea of fine grained restore (even a single
file). Bacula maintains a catalog of all files in all clients even
multiple versions at different times, that's part of its strengths.
Anyway, it's still possible to think something like this:
save/snapshot/restore/dump on the node, then copy everything on the
backup server (or a dedicated host close to it), restore the copy of the
guest again in an isolated environment, clean shutdown, backup. That
depends on the configuration of the guest, of course... in my case, the
network is attached to a bridge that is configured at boot time by the
node, so all I need is an isolated bridge device (with no real
interfaces attached) on the restore host... although, the disks being
LVs, each one with a different name and device path, a bit of adjustment
on the XML configuration is required. Nothing that a perl (or python)
script can't handle.
This works for full backups, for differential/incremental ones is kind
of overkill, as you copy the LVs entirely everytime. Still it may be
sensible to instruct bacula to make incrementals: they are supposed to
1) reduce bandwidth, 2) reduce storage requirements. 1) is defeated, but
2) still holds.
But I think there must be a better way. :)
All I need is to sync the page cache on the guest just before the
snapshot. sysrq-s would do.
A possibile alternative is the suspend-to-mem and suspend-to-disk stuff.
If they do a sync, it could be feasible to trigger a suspend-to-mem on
the guest, suspend the VM, snapshot, restore VM, restart the guest (I
have not idea how to do that, tho).
.TM.