Hi, I did a design session on Friday though my proposal was to capture the delta as qcow2. Here is the link to ether pad notes.
https://etherpad.openstack.org/p/juno-cinder-changed-block-list Do you see synergies between what you are proposing and my proposal? Shouldn¹t we standardize on one format for all backups? I believe Cinder backup API currently uses JSON based list with pointers to all swift objects that make up the backup data of a volume. Regards, Murali Balcha On 5/18/14, 12:02 PM, "Mike Perez" <thin...@gmail.com> wrote: >On 12:45 Mon 12 May , Zhangleiqiang (Trump) wrote: >> Hi, all: >> >> I have planned to add the support to create qcow2 format file in NFS >>driver ([1]). From the comment of Eric Harney, I know that cinder-backup >>service currently assumes the volume is raw-formatted, and enable >>creating qcow2 in NFS driver will break backups of NFS volumes . >> >> After reading the code of backup service, I find we can first mount >>the qcow2 volume as a NBD device and then pass the NBD device as the >>"source volume_file" to backup service. Similar method of mounting qcow2 >>as NBD device has already used in Nova now. I think we can add it to NFS >>driver for backup, and it can be used for GlusterFS too. >> >> Any advice? Is there something I have not expected? > >This approach makes sense to me. Thanks for looking into this. > >-- >Mike Perez > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
