Hi, Kai,

on Samstag, 15. Jänner 2005 at 11:27 you wrote to amanda-users:

KZ> thanks very much for your work on the documentation. But i agree with
KZ> Erik, that still the definition of the term "bump" is explained with
KZ> "bump" - somehow recursive. My dictionary says it's something like an
KZ> indentation, but that doesn't help newbies (like me) very much...

OK, it says:

> The minimum savings required to trigger an automatic bump from one
> incremental level to the next. If AMANDA determines that the next
> higher backup level will be this much smaller than the current
> level, it will do the next level.

I see that bump->bump-thing ... will correct that.

The basic goal of using these parameters is avoiding too much
incremental backups happening too fast.

As it gets harder to restore from a backup-set with lev4 or similar as
you have to use 5 tapes to get your full data back, you want to avoid
lev4 and just go to lev2 or lev3 ...

So you want to get some benefit from BUMPING to lev2 (which actually
means the switch from level n to level n+1) after you are already on
lev1, and this benefit should be saving tapespace because that lev2
backup is smaller than the lev1.

Now read again: "If AMANDA determines that the next higher backup level
will be this much smaller than the current level, it will do the next
level."

If size_of_lev(n+1) - size_of_lev(n) > bumpsize, then AMANDA decides
to do the lev(n+1), because the savings in space are worth it.

Not enough with this, there is also bumpmult !

Actually it's:

threshold = bumpsize * bumpmult^(level-1)

This introduces a somewhat exponential behavior, bumping from lev2 to
lev3 should be harder than bumping from lev1 to lev2, as you want to
avoid high backup-levels.

There is also "bumpdays" to keep the lev down as well.

---

This as a quick-n-dirty-explanation, hope this helps.

-- 
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor AT oops.co DOT at