<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 3, 2016 at 3:58 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"><div dir="ltr"><span class="">On 3 February 2016 at 17:52, Sam Yaple <span dir="ltr"><<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div>This is a very similiar method to what Ekko is doing. The json mapping in Ekko is a manifest file which is a sqlite database. The major difference I see is Ekko is doing backup trees. If you launch 1000 instances from the same glance image, you don't need 1000 fulls, you need 1 full and 1000 incrementals. Doing that means you save a ton of space, time, bandwidth, IO, but it also means n number of backups can reference the same chunk of data and it makes deletion of that data much harder than you describe in Cinder. When restoring a backup, you don't _need_ a new full, you need to start your backups based on the last restore point and the same point about saving applies. It also means that Ekko can provide "backups can scale with OpenStack" in that sense. Your backups will only ever be your changed data.</div><div><br></div><div>I recognize that isn't probably a huge concern for Cinder, with volumes typically being just unique data and not duplicate data, but with nova I would argue _most_ instances in an OpenStack deployment will be based on the same small subset of images and thats alot of duplicate data to consider backing up especially at scale.</div> </div></div></div></blockquote></div><br clear="all"></div></span><div class="gmail_extra">So this sounds great. If your backup formats are similar enough, it is worth considering putting a backup export function in that spits out a cinder-backup compatible JSON file (it's a dead simple format) and perhaps an import for the same. That would allow cinder backup and Ekko to exchange data where desired. I'm not sure if this is possible, but I'd certainly suggest looking at it.<br><br></div></div></blockquote><div>This is potentially possible. The issue I see would be around compression/encryption of the different chunks (in ekko we refer to them as segments). But we will probably be able to work this out in time. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">Thanks for keeping the dialog open, it has definitely been useful.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></blockquote><div>I have enjoyed the exchange as well. I am a big fan of open-source and community. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"> <br><div><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></font></span></div>
</blockquote></div><br></div></div>