<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><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><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><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><br>Or you just accept a higher error rate. (How high depends on the implementation.)</div><div><br></div><div>And "Yes", multi-terabyte volumes <i>are</i> a challenge.</div><div><br></div><div><br></div></div></div></div>