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.
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
