Backup, Pause and FSCK

[kiwi.paul]

Hi,

I'm running a few VMs on a server and have been working on backup strategies.
My requirements are to minimise downtime, and make it simple and very reliable.
Space is less of a concern.

My current strategy is, for each VM:
- shutdown VM
- copy folder
- restart VM
- tar, compress and encrypt the folder, moving it to the remote storage location.

Advantages are that the folder is guaranteed clean, and restores are trivial (untar).
I run this in the early hours and each VM is down for a few minutes (SSDs FTW).

I'm looking at improving on this - to remove the requirement for a daily shutdown as some
of the VMs take a long time to start. Pausing the VM would seem to be ideal, but that leaves the
hard drive looking like there was a crash, so you need to FSCK it before saving it away.

With pause, before compressing in the script above,I need to do this to repair the
VDI (which I've copied to /tmp):
- modprobe nbd max_part=16
- qemu-nbd -c /dev/nbd0 /tmp/VM/*.vdi
- fsck -y /dev/nbd0p2
- qemu-nbd -d /dev/nbd0

Advantages are that there is no shutdown and reboot, saving several minutes for some VMs.
Of course the time to copy is unchanged.
The restore is still trivial, but the fact I'm doing an FSCK is a little worrying in case it might
not succeed (these are ext4, so they *should* be fine).

I'd appreciate input from some wiser heads here - does this make sense? Is anyone doing this
long term and are there any pitfalls?
Many thanks.
Paul

[socratis]

Pausing the VM would seem to be ideal, but that leaves the hard drive looking like there was a crash, so you need to FSCK it before saving it away.

You could be Saving the VM while closing it, instead of Pausing it. That would create a .sav additional file with the contents of the VM RAM/hardware state. As long as you restore it on the same host (i.e. no host hardware changes) you should be all set.

If something goes wrong or different (you change the host), you can simply Discard the saved state of the restored VM, and it would be akin to your VM losing power and forced to reboot.