libvirt users - Oct 2014 - Re: KVM incremental backup using CBT

Hi
     Looking in to implementing (CBT like) delta backup for KVM.

     The following looks promising..(last paragraph)
      http://wiki.qemu.org/Features/Snapshots2

      * In the last para, there is a mention of copy the blocks from the 
disk using dirty-bitmap as reference. How to accomplish this ? 
block-mirror with bitmap or is there a qemu-img command ? some details 
would be appreciated.

// backup software now reads foo.img using t0_dirty.dbmp to perform incremental
backup, when finished



      * The backup after few runs in the backup store would be base 
image + bunch of delta blocks ? Will this be same as base disk and bunch 
of deltas ? or there is some special way to merge these ?

      * I am assuming this scheme (snapshot, bitmap, block merge etc.) 
should work with base disk in raw (non-qcow) format as well ? Right ? 
i.e. will it work when the storage disk is iscsi, lvm, fc ? std linux 
block device?

      * Are there libvirt-api/verbs for doing some of this or we will 
have to sue the qemu-monitor-command ?

      * What version of qemu/kvm will have the core capabilities and 
which min libvirt version would be sufficient ?

      Is there a better way to do incremental backup / CBT like backup 
than one mentioned here ?

Thanks
/Jd

On 10/10/2014 11:37 AM, Jd wrote:
> Hi
>     Looking in to implementing (CBT like) delta backup for KVM.
Not quite sure what you mean by CBT.
> 
>     The following looks promising..(last paragraph)
>      http://wiki.qemu.org/Features/Snapshots2
> 
Libvirt hasn't yet been patched to take advantage of all the latest qemu
features.  Patches are welcome.  But libvirt already knows how to create
external snapshots and do blockpull (backing files pulled into the
active image so the backing isn't needed any more) and commit (active
files pushed into the backing files), and even though it is not as
full-featured as where we'd like to get, it can already do quite a bit.
>      * In the last para, there is a mention of copy the blocks from the
> disk using dirty-bitmap as reference. How to accomplish this ?
> block-mirror with bitmap or is there a qemu-img command ? some details
> would be appreciated.
block-backup is a new QMP command that libvirt would need to expose; I
don't know whether it is better to overload the existing
virDomainBlockCopy() API for it, or to add a new API.
> 
> // backup software now reads foo.img using t0_dirty.dbmp to perform
> incremental backup, when finished
> 
> 
> 
>      * The backup after few runs in the backup store would be base image
> + bunch of delta blocks ? Will this be same as base disk and bunch of
> deltas ? or there is some special way to merge these ?
> 
>      * I am assuming this scheme (snapshot, bitmap, block merge etc.)
> should work with base disk in raw (non-qcow) format as well ? Right ?
> i.e. will it work when the storage disk is iscsi, lvm, fc ? std linux
> block device?
Yes, you can use qcow2 to store deltas on top of any underlying storage
device.
> 
>      * Are there libvirt-api/verbs for doing some of this or we will
> have to sue the qemu-monitor-command ?
If you come up with a scenario where the only way to do something is via
a raw qemu-monitor-command, please report it as a bug (or better yet
provide a patch) so that a stable libvirt API can be written to do the
same task.
> 
>      * What version of qemu/kvm will have the core capabilities and
> which min libvirt version would be sufficient ?
Until patches materialize, it's hard to predict the future.
> 
>      Is there a better way to do incremental backup / CBT like backup
> than one mentioned here ?
> 
> Thanks
> /Jd
> 
> 
> 
> _______________________________________________
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
> 
-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

On Fri, Oct 10, 2014 at 07:32:06PM -0600, Eric Blake
wrote:
> On 10/10/2014 11:37 AM, Jd wrote:
> > Hi
> >     Looking in to implementing (CBT like) delta backup for KVM.
> 
> Not quite sure what you mean by CBT.
> 
> > 
> >     The following looks promising..(last paragraph)
> >      http://wiki.qemu.org/Features/Snapshots2
> > 
> 
> Libvirt hasn't yet been patched to take advantage of all the latest
qemu
> features.  Patches are welcome.  But libvirt already knows how to create
> external snapshots and do blockpull (backing files pulled into the
> active image so the backing isn't needed any more) and commit (active
> files pushed into the backing files), and even though it is not as
> full-featured as where we'd like to get, it can already do quite a bit.
To expand an example of what Eric wrote here about external snapshots,
some commands to try:

1. Check the current acitve disk image in use:

    $ virsh domblklist vm1


2. Create an external live snapshot:

    $ virsh snapshot-create-as --domain vm1 sn1 \
        --diskspec vda,file=/export/images/sn1.qcow2 \
        --disk-only --atomic --no-metadata

    Note (thanks Eric Blake): Above, if you have QEMU guest agent
    installed in your virtual machine, try --quiesce option with
    'snapshot-create-as' to ensure you have a consistent disk state.

    Now, you have a disk image chain:
    
        base <-sn1 (live QEMU)


3. Take a backup of the original disk in backround:

    $ rsync -avh --progress /export/images/base.img \
        /export/images/copy.img


4. Commit the sn1 contents back into base:

    $ virsh blockcommit vm1 vda --active --verbose --pivot

    Now, the chain is: 
    
        base (live QEMU) 

    with contents from sn1 live committed into base.


5.  Check the current acitve disk image in use again:

    $ virsh domblklist vm1


-- 
/kashyap

Thanks Eric.. inline.
On 10/10/14, 6:32 PM, Eric Blake wrote:
> On 10/10/2014 11:37 AM, Jd wrote:
>> Hi
>>      Looking in to implementing (CBT like) delta backup for KVM.
> Not quite sure what you mean by CBT.
Sorry vmware term.. CBT -> changed block tracking.  (dirty
block)
>
>>      The following looks promising..(last paragraph)
>>       http://wiki.qemu.org/Features/Snapshots2
>>
> Libvirt hasn't yet been patched to take advantage of all the latest
qemu
> features.  Patches are welcome.  But libvirt already knows how to create
> external snapshots and do blockpull (backing files pulled into the
> active image so the backing isn't needed any more) and commit (active
> files pushed into the backing files), and even though it is not as
> full-featured as where we'd like to get, it can already do quite a bit.
>
>>       * In the last para, there is a mention of copy the blocks from
the
>> disk using dirty-bitmap as reference. How to accomplish this ?
>> block-mirror with bitmap or is there a qemu-img command ? some details
>> would be appreciated.
> block-backup is a new QMP command that libvirt would need to expose; I
> don't know whether it is better to overload the existing
> virDomainBlockCopy() API for it, or to add a new API.
So this seems to be already in qemu. How can I try this with KVM 
context. Do I need to build from source ? or some version of KVM already 
has this ?
>
>> // backup software now reads foo.img using t0_dirty.dbmp to perform
>> incremental backup, when finished
>>
>>
>>
>>       * The backup after few runs in the backup store would be base
image
>> + bunch of delta blocks ? Will this be same as base disk and bunch of
>> deltas ? or there is some special way to merge these ?
>>
>>       * I am assuming this scheme (snapshot, bitmap, block merge etc.)
>> should work with base disk in raw (non-qcow) format as well ? Right ?
>> i.e. will it work when the storage disk is iscsi, lvm, fc ? std linux
>> block device?
> Yes, you can use qcow2 to store deltas on top of any underlying storage
> device.
Glad to get confirmation.
>
>>       * Are there libvirt-api/verbs for doing some of this or we will
>> have to sue the qemu-monitor-command ?
> If you come up with a scenario where the only way to do something is via
> a raw qemu-monitor-command, please report it as a bug (or better yet
> provide a patch) so that a stable libvirt API can be written to do the
> same task.
>
>>       * What version of qemu/kvm will have the core capabilities and
>> which min libvirt version would be sufficient ?
> Until patches materialize, it's hard to predict the future.
Could you clarify a bit more .. I am not too familiar with how things 
move from qemu --> kvm  and how the libvirt releases are aligned with 
qemu or kvm releases if they are.
I want to have an environment where I can try this end to end. I have 
ubuntu 14.04.x release.
>
>>       Is there a better way to do incremental backup / CBT like backup
>> than one mentioned here ?
>>
>> Thanks
>> /Jd
>>
>>
>>
>> _______________________________________________
>> libvirt-users mailing list
>> libvirt-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/libvirt-users
>>