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:[EMAIL PROTECTED]