<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 6, 2016 at 5:12 PM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Actually, keeping track of changed blocks on cinder volumes would make the cinder incremental backup substantially more efficient... Something could push them into cinder at detach time, and an api call for cinder to pull them at live backup time, and cinder backup can do the rest... Not sure of the none-cinder bits of the architecture, but certainly an interesting idea. In the event something goes wrong, cinder can assume the while device has changed or fall back to the current mechanism, so it is back compatible from a tenant point of view...</p>
<div class="gmail_quote"><div><div class="h5"></div></div></div></blockquote><div>The mechanism that nova could call right now has no libvirt counterpart. So with Ekko I am talking to the qemu process through the monitor socket to initiate these commands. QEMU spits out the data I need to backup, I am as of now unsure if the changed block bitmap itself can be extracted or if it is all an internal tracking (I haven't looked into this).</div><div><br></div><div>I can see a future where, though nova-api's, both Cinder and Ekko can perform backups without the raw data having to traverse through nova itself, just the metadata such as changed-blocks and what not. This would be my preferred solution rather than have Nova itself run the backup and transfer of data to the backing storage (not to mention scheduling and retention). Additionally it would mean that neither Ekko nor Cinder would need to talk to the hypervisors directly and can still utilize that low-level info.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div class="h5">On 6 Feb 2016 17:56, "Sam Yaple" <<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 6, 2016 at 3:00 PM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 2016-02-05 16:38:19 +0000 (+0000), Sam Yaple wrote:<br>
> I always forget to qualify that statement don't I? Nova does not<br>
> have a mechanism for _incremental_ backups. Nor does Nova have<br>
> compression or encryption because AFAIK that api only creates a<br>
> snapshot. I would also point out again that snapshots != backups,<br>
> at least not for those who care about backups.<br>
<br>
</span>And just to be clear, you assert that the Nova team would reject<br>
extending their existing backup implementation to support this, so<br>
the only real solution is to make another project.<br></blockquote><div><br></div><div>I don't know if Nova would reject it or not, but as discussed it could be extended to Cinder. Should Nova ever backup Cinder volumes? Additionally, why don't we combine networking into Nova? Or images? Or volumes? What I do assert is that we have done alot of work to strip out components from Nova, backups don't seem like a good candidate to shove into Nova. </div><div><br></div><div>Luckily since Ekko and Nova (just like Ekko and Freezer) don't have any conflicting operations should Ekko be built separate and merged into Nova it would be fairly painless process since there are no overlapping services.</div><div><br></div><div>Integration with Nova where Nova controls the hypervisor and Ekko requests operations through the Nova api before doing the backup is another question, and that is reasonable in my opinion. This is likely an issue that can be addressed down the road rather than at this moment, though.</div></div><br></div></div>
<br></div></div><span class="">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div>
</blockquote></div><br></div></div>