<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 3, 2016 at 1:41 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 2 February 2016 at 02:28, Sam Yaple <span dir="ltr"><<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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"><br><div class="gmail_quote"><span></span>I disagree with this statement strongly as I have stated before. Nova has snapshots. Cinder has snapshots (though they do say cinder-backup). Freezer wraps Nova and Cinder. Snapshots are not backups. They are certainly not _incremental_ backups. They can have neither compression, nor encryption. With this in mind, Freezer does not have this "feature" at all. Its not that it needs improvement, it simply does not exist in Freezer. So a separate project dedicated to that one goal is not unreasonable. The real question is whether it is practical to merge Freezer and Ekko, and this is the question Ekko and the Freezer team are attempting to answer.<span></span></div></div></div></blockquote><div><br></div></span><div>You're misinformed of the cinder feature set there - cinder has both snapshots (usually fast COW thing on the same storage backend) and backups (copy to a different storage backend, usually swift but might be NFS/ceph/TSM) - the backups support incremental and compression. Separate encryption to the volume encryption is not yet supported or implemented, merely because nobody has written it yet. There's also live backup (internally via a snapshot) merged last cycle.<br><br></div></div></div></div></blockquote><div>You are right Duncan. I was working on outdated information that Cinder does not have incremental backups. I apologize for the misstep there, we haven't started on the Cinder planning yet so I haven't looked into it in great detail.</div><div><br></div><div>Looking into it, however, shows Cinder has no mechanism to delete backups in the middle of a chain since you use dependent backups (please correct me if I am wrong here). This means after a number of incremental backups you _must_ take another full to ensure the chain doesn't get to long. That is a problem Ekko is purposing to solve as well. Full backups are costly in terms of IO, storage, bandwidth and time. A full backup being required in a backup plan is a big problem for backups when we talk about volumes that are terabytes large.</div><div><br></div><div>Luckily, digging into it it appears cinder already has all the infrastructure in place to handle what we had talked about in a separate email thread Duncan. It is very possible Ekko can leverage the existing features to do it's backup with no change from Cinder. This isn't the initial priority for Ekko though, but it is good information to have. Thank you for your comments!</div><div><br></div></div></div></div>