<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 3, 2016 at 4:53 PM, Preston L. Bannister <span dir="ltr"><<a href="mailto:preston@bannister.us" target="_blank">preston@bannister.us</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"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 3, 2016 at 6:32 AM, Sam Yaple <span dir="ltr"><<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</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"><div class="gmail_extra"><div class="gmail_quote"><div>[snip] </div></div></div></div></blockquote><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"><div class="gmail_quote"><div> 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></div></div></blockquote><div><br></div></span><div>As an incidental note...<br><br></div><div>You have to collect full backups, periodically. To do otherwise assumes <i>absolutely no failures</i> anywhere in the entire software/hardware stack -- ever -- and no failures in storage over time. (Which collectively is a tad optimistic, at scale.) Whether due to a rare software bug, a marginal piece of hardware, or a stray cosmic ray - an occasional bad block will slip through.<br></div></div></div></div></blockquote><div> </div><div>A new full can be triggered at any time should there be concern of a problem. (see my next point)</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 class="gmail_quote"><div><br>More exactly, you need some means of doing occasional full end-to-end verification of stored backups. Periodic full backups are one safeguard. How you go about performing full verification, and how often is a subject for design and optimization. This is where things get a <i>bit</i> more complex. :)</div></div></div></div></blockquote><div> </div><div>Yes an end-to-end verification of the backup would be easy to implement, but costly to run. But thats more on the user to decided those things. With a proper scheduler this is less an issue for Ekko, and more a backup policy issue.</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 class="gmail_quote"><div><br>Or you just accept a higher error rate. (How high depends on the implementation.)</div></div></div></div></blockquote><div> </div><div>And its not a full loss, its just not a 100% valid backup. Luckily youve only lost a single segment (a few thousand sectors) chances are the critical stuff you want isn't there. That data can still be recovered.</div><div>And object-storage with replication makes it very, very hard to loss data when properly maintained (look at S3 and the data its lost over time). We have checksum/hash verification in place already so the underlying data must be valid or we don't restore. But your points are well received.</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 class="gmail_quote"><div><br></div><div>And "Yes", multi-terabyte volumes <i>are</i> a challenge.</div><div></div></div></div></div></blockquote><div><br></div><div>And increasingly common...</div></div><br></div></div>