Libguestfs - Aug 2010 - Question about using guestfish --ro as a backup solution

> <monolive> what is the risk if I backup a running VM ? using
> guestfish --ro ?  I understand that my open files might be funny but
> the issue should be solve by a fsck ?  it won't work for an open DB
It's a bit different from this.

What happens is that the libguestfs appliance / kernel attaches to the
disk, which is in a potentially unclean *and* potentially changing
state.  When libguestfs does the mount, the journal recovery is
performed (against a throw-away snapshot of the original disk -- if
you use the --ro option, the original disk is not written to at all).
However the disk is still changing and the libguestfs kernel could
interpret this in all sorts of ways: eg. panicking or silently reading
corrupt data.

The news is: DON'T use guestfish --ro as your backup solution, UNLESS:

(1) you don't care about the integrity of your backups, or

(2) you can prove that nothing is writing to the disk (eg. the VM is
switched off), or

(3) you take a snapshot of the disk first (eg. LVM snapshot), which is
really just a special case of (2), or

(4) the filesystem that you are backing up is frozen[a], which is also
a special case of (2).

Run a backup daemon inside the guest instead.  There are plenty of
network backup programs around.  Choose your favorite one and install
it in your VM.

Rich.

[a] http://lwn.net/Articles/287435/

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

On 08/13/2010 03:08 PM, Richard W.M. Jones wrote:
>
>> <monolive>  what is the risk if I backup a running VM ? using
>> guestfish --ro ?  I understand that my open files might be funny but
>> the issue should be solve by a fsck ?  it won't work for an open DB
>
> It's a bit different from this.
>
> What happens is that the libguestfs appliance / kernel attaches to the
> disk, which is in a potentially unclean *and* potentially changing
> state.  When libguestfs does the mount, the journal recovery is
> performed (against a throw-away snapshot of the original disk -- if
> you use the --ro option, the original disk is not written to at all).
> However the disk is still changing and the libguestfs kernel could
> interpret this in all sorts of ways: eg. panicking or silently reading
> corrupt data.
>
> The news is: DON'T use guestfish --ro as your backup solution, UNLESS:
>
> (1) you don't care about the integrity of your backups, or
>
> (2) you can prove that nothing is writing to the disk (eg. the VM is
> switched off), or
>
> (3) you take a snapshot of the disk first (eg. LVM snapshot), which is
> really just a special case of (2), or
>
> (4) the filesystem that you are backing up is frozen[a], which is also
> a special case of (2).
>
> Run a backup daemon inside the guest instead.  There are plenty of
> network backup programs around.  Choose your favorite one and install
> it in your VM.
>
Thanks for the answer. Quite a few backup solution do have a cost per 
client, doing it at the hypervisor level is making our life easier.

I do not mind doing step 3 before running the guestfish --ro, if it 
enables me to have data integrity.

Regards.
Olivier