<div dir="ltr">Depends on your aim. <div><br></div><div>Be aware that the OpenStack community does not really have a good handle on "backup", on efficiency at scale, and the differing levels of service.</div><div><br></div><div>From the perspective of building efficient backup at scale, the existing OpenStack APIs make almost no sense.</div><div><br></div><div>If your deployment is on Ceph, there are some interesting optimizations that fit some fairly specific levels of service. But as you (seem to?) have noted, backup into the same pool is not always what you want.<br></div><div><br></div><div>To be clear, I was tasked several months back with figuring out backup for OpenStack, at a vendor that does a lot of at-scale backup. Easy to do backup badly. Harder to do efficient backup at scale.</div><div><br></div><div>The key is that you want to backup Nova instances, not Cinder volumes. The operation then tracks changes between backups at the Nova level, not Cinder.  Otherwise you are copying/scanning entire volumes at the Cinder level - not efficient. The underlying operations needed are ... not quite there.</div><div><br></div><div>Thus the current confused situation around OpenStack backup. :)</div><div><br></div><div><br><br><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 2:39 PM, Sebastien Han <span dir="ltr"><<a href="mailto:sebastien.han@enovance.com" target="_blank">sebastien.han@enovance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One of the extra benefit could be that you’re doing backup on another Ceph cluster (potentially on another location).<br>
However this will never prevent you from corruption since if corruption already occurred then it will be replicated.<br>
<br>
Like Erik mentioned a catastrophic situation were you lose all the monitors and get corrupted fs/leveldb store (just happened to someone on the ceph ML) would be a disaster.<br>
Having another healthy cluster can be useful.<br>
<div><div class="h5"><br>
> On 30 Jan 2015, at 20:35, Erik McCormick <<a href="mailto:emccormick@cirrusseven.com">emccormick@cirrusseven.com</a>> wrote:<br>
><br>
> It doesn't buy you a lot in that sort of setup, but it would put it in a different pool and thus different placement groups and OSDs. It could potentially protect you from data loss in some catastrophic situation.<br>
><br>
> -Erik<br>
><br>
> On Fri, Jan 30, 2015 at 2:08 PM, Jonathan Proulx <<a href="mailto:jon@jonproulx.com">jon@jonproulx.com</a>> wrote:<br>
> Hi All,<br>
><br>
> I can see the obvious distinction between cinder-snapshot and<br>
> cinder-backup being that snapshots would live on the same storage back<br>
> end as the active volume (using that ever snapshotting that provides)<br>
> where the backup would be to different storage.<br>
><br>
> We're using Ceph for volume and object storage so it seems like<br>
> running cinder-backup in that case (with active, snap, and backup<br>
> would be all in essentially the same backend) would not make a whole<br>
> lot of sense.<br>
><br>
> Is my thinking right on this or are there advantages of 'backup' over<br>
> 'snapshot' that I'm not considering?<br>
><br>
> -Jon<br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br>
<br>
</div></div>Cheers.<br>
––––<br>
Sébastien Han<br>
Cloud Architect<br>
<br>
"Always give 100%. Unless you're giving blood."<br>
<br>
Phone: <a href="tel:%2B33%20%280%291%2049%2070%2099%2072" value="+33149709972">+33 (0)1 49 70 99 72</a><br>
Mail: <a href="mailto:sebastien.han@enovance.com">sebastien.han@enovance.com</a><br>
Address : 11 bis, rue Roquépine - 75008 Paris<br>
Web : <a href="http://www.enovance.com" target="_blank">www.enovance.com</a> - Twitter : @enovance<br>
<br>
<br>_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div><br></div>