On Monday 24 April 2006 20:54, Eric Warnke wrote:
> Clarification on the differentials comment
>
> What I'm suggesting is...
>
> Full = Full
> Incremental = Changes since last Full or Incremental
> Differential = Changes since last Full ( effectively becoming an
> incremental since last full ).
>
> Right now, incremental track from either full, differential, or incremental
> meaning you can not discard/recycle the differential before a new full,
> what I'm suggesting is that should not be the case. By decoupling the
> incremental from differentials you can manage very long retention periods (
> ie in our case 90+ days ). Differentials would then be a "roll-up" of the
> incremental so when you need to restore you just need to pull the
> incremental back to the most recent differently and the full. You should
> be able to then discard differentials at any time as a space/restore speed
> tradeoff.
I'm sorry, but I really don't understand much of what you are saying in the
above, probably because of terminology such as decouple and "roll-up" which
is not generally used in Bacula terminology, so I don't know precisely what
you mean.
In Bacula you can indeed "discard differentials at any time", with one minor
exception: you must always keep the most recent one. Of course, in doing so,
you may lose the ability to restore to certain points in time. This is much
the same as you can always discard any full backup except the most recent
one.
In addition to being able to discard all but the most recent differential, you
can discard all incrementals made between the full and the most recent
differential.
In restoring a system to the current state, Bacula will only look at the most
recent Full, the most recent Differential, and all the Incrementals since the
last Differential. All other backups are ignored.
The only reason why I could imagine wanting to discard differentials at any
time, is that you don't have enough backup media to handle all your data and
thus you are willing to give up the ability to restore to various points in
the past. If that is what you really want, you can do it to a very large
extent with the current system.
However, at the current time, you may need to do some of it manually, because
I don't think the current prunning is smart enough to ensure that it doesn't
wipe out the last valid backup copy -- something that a cleaver person with a
small amount of time on his hands could quickly remedy by enhancing the
SQL/alogorithm.
>
> Cheers,
> Eric
>
> On 4/24/06, Meidal, Knut <[EMAIL PROTECTED]> wrote:
> > 4) The way that incremental and differentials are structured does not
> > allow
> > for good differential pooling since incremental can be based on
> > differentials. Because of this you can't recycle your differentials
> > before
> > you re-run a full backup. If incremental were only based on fulls or
> > incremental, you can recycle your differentials on a faster cycle to
> > reduce
> > tape space for in exchange for longer restore times for older files.
> >
> > -> That is an interesting point. Any subsequent differentials obsoletes
> > previous when aiming for recovering to most current state.
> > The problem I see, is that recycling a differential will orphan all the
> > incrementals referring to them(between diff and new diff or full), making
> > them useless.
> > I can't seem to understand your second point if incrementals were only
> > based
> > on full or inc...
> > If you wanted to that, you could simply remove the diffs from the
> > schedule,
> > and never run one? I can't seem to see the useability of a lone
> > differential
> > that can't be used for baseline for subsequent incrementals.
> > I've been known to misunderstand, so bear with me..
> >
> >
> >
> > Knut Meidal
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
