Prevented bump?
I have a daily backup routine that I have changed around (duh me) and now
does not want to complete its daily cycle. I believe it gets stuck on
backing up an NT partition using user-tar and compression on the server.
Could this be a faulty tape or have I just jimmied something incorrectly?
The log says: INFO planner Preventing bump of localhost://ntserver/ppidocs
as directed, INFO planner Preventing bump of
localhost://ntserver/businesswork as directed. -- Can someone please
assist?
Thanks,
Michael Blinn
People Places, Inc.
amanda.conf:
dumpuser "backup" # the user to run dumps under
inparallel 4# maximum dumpers that will run in parallel (max 63)
netusage 600 Kbps # maximum net bandwidth for Amanda, in KB per sec
dumpcycle 0 days# the number of days in the normal dump cycle
maxcycle 1 days
runspercycle 1 # the number of amdump runs in dumpcycle days
tapecycle 5 tapes # the number of tapes in rotation
bumpsize 20 Mb # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
etimeout 300# number of seconds per filesystem for estimates.
dtimeout 1800
ctimeout 2
runtapes 1
define dumptype nt-comp {
user-tar
compress server fast
priority high
}
backup:/usr/local/etc/amanda/daily$ /usr/local/sbin/amstatus daily
Using /var/amanda/daily/amdump from Tue Jun 11 01:00:01 EST 2002
localhost://ntserver/businesswork0 60095k dumping28288k (
47.07%) (1:00:26)
localhost://ntserver/ppidocs 0 122022k wait for dumping
mail:/configs0 32k finished (1:00:45)
mail:/usr/local/apache 0 19107k wait for dumping
mail:/var/lib/mysql 0 768k finished (1:00:43)
SUMMARY part real estimated
size size
partition : 5
estimated : 5 202024k
failed : 0 0k ( 0.00%)
wait for dumping: 2 141129k ( 69.86%)
dumping to tape : 0 0k ( 0.00%)
dumping : 128288k60095k ( 47.07%) ( 14.00%)
dumped : 2 800k 800k (100.00%) ( 0.40%)
wait for writing: 00k0k ( 0.00%) ( 0.00%)
writing to tape : 00k0k ( 0.00%) ( 0.00%)
failed to tape : 00k0k ( 0.00%) ( 0.00%)
taped : 2 800k 800k (100.00%) ( 0.40%)
3 dumpers idle : no-bandwidth
taper idle
network free kps: 1964
holding space : 236800k ( 79.74%)
dumper0 busy : 0:00:30 ( 68.59%)
dumper1 busy : 0:00:00 ( 0.65%)
taper busy : 0:00:18 ( 42.60%)
0 dumpers busy : 0:00:00 ( 0.00%)
1 dumper busy : 0:00:30 ( 67.94%) start-wait: 0:00:14 (
49.83%)
client-constrained: 0:00:13 (
45.14%)
no-bandwidth: 0:00:01 (
5.03%)
2 dumpers busy : 0:00:00 ( 0.65%)
-
Michael Blinn
IT Guy, People Places, Inc.
[EMAIL PROTECTED]
-
...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea, Europe
is the less, as well as if a promontory were, as well as if a manor of thy
friend's or of thine own were. Any man's death diminishes me, because I am
involved in mankind; and therefore never send to know for whom the bell
tolls; it tolls for thee... - Meditation 17, Devotions Upon Emergent
Occasions, 1624
aggressive bump
If I understand the concept of bumpting, then because I'm using virtual tapes, I think I want total bumping to be done -- if there is such a thing. I don't care at all how many "tapes" my backup is scattered over. I inherited my amanda setup from my predecessor in this job and I have never messed with the bump settings. But we are moving from physical tapes to virtual tapes. Here are the current values: bumpsize 500 mb # minimum savings (threshold) to bump level 1 -> 2 bumpdays 1 # minimum days at each level bumpmult 4 # threshold = bumpsize * bumpmult^(level-1) I'm a little unclear on how backup levels and tape cycle interact. It would be fine with me if there was always just one copy of each file on the virtual tapes. -- --- John G. Heim, 608-263-4189, jh...@math.wisc.edu
Re: bump*
Got it - i made the change needed. On Thu, 2 Nov 2000, John R. Jackson wrote: > >It looks like we are ready for a level 3. > > As I mentioned in some other E-mail, Amanda has its own ideas about what > level to run when. In general, it avoids "bumping" to the next level any > more than it has to. This simplifies what needs to be done for a restore. > > In your case, you want to minimize the amount of data in the holding disk, > so may want to change the bump* parameters in amanda.conf (set them all > to zero) to encourage Amanda to go to the next level every day. > > >Denise E. Ives > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Meaning of "bump"
Hi, I am running Fedora Core 3 which comes with amanda installed and I have just started to set it up. In amanda.conf "bumpsize", "bumpmult" and "bumpdays" should be specified. My problem is that I don't know exactly what this "bump" and the associated "level" mean. Would someone please explain these terms to me? Thanks. -- Regards, Erik P. Olsen
Re: aggressive bump
On Oct 14, 2013, at 5:39 PM, "John G. Heim"
wrote:
> If I understand the concept of bumpting, then because I'm using virtual
> tapes, I think I want total bumping to be done -- if there is such a thing.
> I don't care at all how many "tapes" my backup is scattered over.
>
> I inherited my amanda setup from my predecessor in this job and I have never
> messed with the bump settings. But we are moving from physical tapes to
> virtual tapes. Here are the current values:
>
> bumpsize 500 mb # minimum savings (threshold) to bump level 1
> -> 2
> bumpdays 1# minimum days at each level
> bumpmult 4# threshold = bumpsize * bumpmult^(level-1)
>
>
> I'm a little unclear on how backup levels and tape cycle interact. It would
> be fine with me if there was always just one copy of each file on the virtual
> tapes.
>
> --
> ---
> John G. Heim, 608-263-4189, jh...@math.wisc.edu
I think you are saying don't DON'T want bumping. Bumping is going down to a
level-2 backup from a level-1, so as to reduce the amount of data being saved.
I think you are saying you only want level 0 backups done. I do this for my
"archival" tapes, which should not contain level-1 backups and thus be reliant
on
some other tape. I use these settings:
dumpcycle 0# the number of days in the normal ARCHIVE cycle
tapecycle 9000 tapes # some infinite number; always fresh tape for archives
inside my dumptype's I include:
define dumptype dailyNormal {
BDnormal #read in the other file
strategy noinc #nothing but full backups; don't even calculate other
sizes
skip-incr yes
}
Am I hearing you correctly?
Deb Baddorf
Fermilab
The question about the 'force-bump' and the 'force-no-bump'
Hi all I think about the backup schedules as follow: 1st full backup(LV0) 2nd partial backup(LV1) 3rd partial backup(LV1) 4th partial backup(LV1) 'force', 'forcd-bump', and 'forcd-no-bump' each option of the amadmin command had been executed specifying it before the amdump command was executed. 1st $ amadmin DailySet_HD force rh5cli /var/test $ amdump DailySet_HD 2nd $ amadmin DailySet_HD force-bump rh5cli /var/test $ amdump DailySet_HD 3rd $ amadmin DailySet_HD force-no-bump rh5cli /var/test $ amdump DailySet_HD 4th $ amadmin DailySet_HD force-no-bump rh5cli /var/test $ amdump DailySet_HD When the dumpcycle was '1 week' , the backup level was as follows: 1st full backup(LV0) 2nd partial backup(LV1) 3rd partial backup(LV1) 4th partial backup(LV1) But the dumpcycle was '0', the backup level was as follow: 1st full backup(LV0) 2nd partial backup(LV1) 3rd full backup(LV0) 4th full backup(LV0) In this case, is it a specification of amanda that the full backup is executed because dumpcycle is 0 even if option 'force-no-bump' is executed? Your prompt reply would be greatly appreciated. Thanks in advance.
Re: Meaning of "bump"
Hi, Erik, on Freitag, 14. Jänner 2005 at 22:41 you wrote to amanda-users: EPO> Hi, EPO> I am running Fedora Core 3 which comes with amanda installed and I have EPO> just started to set it up. In amanda.conf "bumpsize", "bumpmult" and EPO> "bumpdays" should be specified. My problem is that I don't know exactly EPO> what this "bump" and the associated "level" mean. EPO> Would someone please explain these terms to me? I don't want repeat my new mantra too often, as it might get worn out too early ... : Have you read the description of those parameters at http://www.amanda.org/docs/amanda.8.html ? If there are any questions left then, please let us know. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Meaning of "bump"
Hi Stefan, hi Erik, Stefan G. Weichinger wrote: Hi, Erik, on Freitag, 14. Jänner 2005 at 22:41 you wrote to amanda-users: EPO> Hi, EPO> I am running Fedora Core 3 which comes with amanda installed and I have EPO> just started to set it up. In amanda.conf "bumpsize", "bumpmult" and EPO> "bumpdays" should be specified. My problem is that I don't know exactly EPO> what this "bump" and the associated "level" mean. EPO> Would someone please explain these terms to me? I don't want repeat my new mantra too often, as it might get worn out too early ... : Have you read the description of those parameters at http://www.amanda.org/docs/amanda.8.html ? If there are any questions left then, please let us know. thanks very much for your work on the documentation. But i agree with Erik, that still the definition of the term "bump" is explained with "bump" - somehow recursive. My dictionary says it's something like an indentation, but that doesn't help newbies (like me) very much... thanks, Kai
Re: Meaning of "bump"
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]
Re: Meaning of "bump"
On Sat, 2005-01-15 at 10:03 +0100, Stefan G. Weichinger wrote: > Hi, Erik, > > on Freitag, 14. JÃnner 2005 at 22:41 you wrote to amanda-users: > > EPO> Hi, > > EPO> I am running Fedora Core 3 which comes with amanda installed and I have > EPO> just started to set it up. In amanda.conf "bumpsize", "bumpmult" and > EPO> "bumpdays" should be specified. My problem is that I don't know exactly > EPO> what this "bump" and the associated "level" mean. > > EPO> Would someone please explain these terms to me? > > I don't want repeat my new mantra too often, as it might get worn out > too early ... : > > Have you read the description of those parameters at > http://www.amanda.org/docs/amanda.8.html ? Yes, I have (and am) reading it. Description of the parameters does not explain the basic philosophy behind amanda. Luckily I got a private mail with a very good explanation which made it easier to understand the parameters. In fact I think it was the level term which puzzled me. If you can't grasp the level term it doesn't make sense to talk about bumping from one level to another. > > If there are any questions left then, please let us know. -- Regards, Erik P. Olsen
Re: Meaning of "bump"
Hi Stefan, - Original Message - From: "Stefan G. Weichinger" <[EMAIL PROTECTED]> To: amanda-users@amanda.org Subject: Re: Meaning of "bump" Date: Sat, 15 Jan 2005 12:08:31 +0100 > 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. yes, that's what i meant > 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. that's exactly what i would like to read in the docs (Bumping means switching backup levels or so). > 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." i understand this in the context you gave - but i was completely unsure about it when i read it for the first time. please don't take it too serious - i simply think that people enjoy reading the docs more when this is clearer. > 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. perfectly - that's what i was looking for :-) thanks, Kai
Re: Meaning of "bump"
Hi, Erik, on Samstag, 15. Jänner 2005 at 13:59 you wrote to amanda-users: EPO> On Sat, 2005-01-15 at 10:03 +0100, Stefan G. Weichinger wrote: >> Have you read the description of those parameters at >> http://www.amanda.org/docs/amanda.8.html ? EPO> Yes, I have (and am) reading it. Description of the parameters does not EPO> explain the basic philosophy behind amanda. Yes, that's true. I will try to remember this when doing further docs-work. EPO> Luckily I got a private mail EPO> with a very good explanation which made it easier to understand the EPO> parameters. In fact I think it was the level term which puzzled me. If EPO> you can't grasp the level term it doesn't make sense to talk about EPO> bumping from one level to another. Yes ... I hope you have grasped both terms now in a satisfying way ;-) -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Meaning of "bump"
Hi, Kai, on Samstag, 15. Jänner 2005 at 13:59 you wrote to amanda-users: KZ> Hi Stefan, >> 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. KZ> that's exactly what i would like to read in the docs (Bumping KZ> means switching backup levels or so). I will look through the docs ASAP to see if this explanation really is completely missing and correct it. It's good to point me at those issues as it is sometimes hard to "forget what you know" when it comes to writing docs. Over the years one gets so used to some of the concepts that one gets a bit blind sometimes ... >> 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." KZ> i understand this in the context you gave - but i was KZ> completely unsure about it when i read it for the first time. KZ> please don't take it too serious - i simply think that people KZ> enjoy reading the docs more when this is clearer. Yep, goes onto my to-fix-list. >> This as a quick-n-dirty-explanation, hope this helps. KZ> perfectly - that's what i was looking for :-) So I will just cut and paste. ;-) just kidding ... -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Meaning of "bump"
Hi, on Samstag, 15. Jänner 2005 at 16:59 I wrote to amanda-users: KZ>> that's exactly what i would like to read in the docs (Bumping KZ>> means switching backup levels or so). SGW> I will look through the docs ASAP to see if this explanation really is SGW> completely missing and correct it. It's good to point me at those SGW> issues as it is sometimes hard to "forget what you know" when it comes SGW> to writing docs. Over the years one gets so used to some of the SGW> concepts that one gets a bit blind sometimes ... One more on this: A grep for "bump" in the docs-tree showed that there REALLY is no explanation anywhere. Thanks for showing me that ... Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
bump* dumptype parameters tuning
Hi, It's with some shame that I must admit that through the long years of using amanda I've never really played with the bump* parameters for DLEs! I'm now in a situation that might benefit from some tuning using those to aggressively encourage bumping the gnutar incremental levels. The drawback of potentially needing more tapes for recovery is not really a constraint for me. I have a DLE (~5TB) for which the estimates are done on the server -- the client, a NAS/filer, doesn't support anything else, so the DLE usage info is really just from the historical usage not the current one. Any ideas/hints on how should I proceed from what is currently (default values I guess) configured? bumppercent 20 bumpsize20480K bumpdays1 bumpmult4.0 Would setting bumpdays to higher values (2 or 3 days) pull in the direction I want to go? Since bumppercent != 0, bumpsize is ignored from the man page, so I guess the only important parameter left is bumppercent. Should I increase it or decrease it? I'm having a hard time understanding what the doc says for amanda.conf says... thanks! jf
MSG: planner: Preventing bump of ...
Friends, please ... During amanda bkp process, I had been received the message ==>> planner: Preventing bump of ... <<== Always the msg is for the same directory. Is this a problem or just an information message ? See the report: === NOTES: . . . planner: Skipping full dump of prods6.hc.unicamp.br://samara/Projetos tomorrow. ===>>> planner: Preventing bump of prods6.hc.unicamp.br://samara/Projetos as directed. planner: Skipping full dump of prods6.hc.unicamp.br://samara/QUALIDADE tomorrow. . . . DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s - . . . prods6.hc //pdchc/gsi 1 111395 16435 14.8 0:29 570.7 N/A N/A ===>>> prods6.hc //samara/Projetos12152500 23.2 3:10 2.6 N/A N/A prods6.hc //samara/QUALIDADE 11971972 49.3 1:01 16.0 N/A N/A prods6.hc //samara/SWDES 1 17654 2332 13.2 0:14 163.8 N/A N/A prods6.hc //samara/Secretaria 12055416 20.2 0:09 46.9 N/A N/A prods6.hc //samara/VB_INT 14793 1282 26.7 0:51 25.1 N/A N/A prods6.hc //samara/prods5-bkp 1 115276 106555 92.4 3:28 511.4 N/A N/A prods6.hc /nihc_home 5 365620 278518 76.2 5:33 836.0 N/A N/A prods6.hc /nihc_var5 501690 220733 44.0 7:06 518.0 N/A N/A . . . (brought to you by Amanda version 2.4.3b4) == Tks so much, Floriano ==>> this msg occurs with FULL or INC bkp preocess !! best regards . ==
bump to 2 means 0?
Hey Gang, Anyone seen this before? NOTES: planner: Incremental of www.thepilot.com:/usr/local/apache bumped to level 2. yet the actual summary says: DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- --- www.thepilot.com /usr/local/apache 0 1085260 170688 15.7 7:21 387.0 0:58 2929.5 Notice it shows that it did a full... It appears to have gotten all of it but I'm just curious as to why planner said level to but it actually performed a level 0. =G=
Re: bump* dumptype parameters tuning
On Mon, Apr 09, 2018 at 01:20:05PM -0400, Jean-Francois Malouin wrote: > Hi, > > It's with some shame that I must admit that through the long years of using > amanda I've never really played with the bump* parameters for DLEs! > > I'm now in a situation that might benefit from some tuning using those > to aggressively encourage bumping the gnutar incremental levels. The > drawback of potentially needing more tapes for recovery is not really a > constraint for me. > > I have a DLE (~5TB) for which the estimates are done on the server -- > the client, a NAS/filer, doesn't support anything else, so the DLE usage > info is really just from the historical usage not the current one. Any > ideas/hints on how should I proceed from what is currently (default > values I guess) configured? > > bumppercent 20 > bumpsize20480K > bumpdays1 > bumpmult4.0 > > Would setting bumpdays to higher values (2 or 3 days) pull in the > direction I want to go? > > Since bumppercent != 0, bumpsize is ignored from the man page, so I > guess the only important parameter left is bumppercent. Should I > increase it or decrease it? I'm having a hard time understanding what > the doc says for amanda.conf says... As you note, your bumpsize is ignored. The bumpdays parameter gives the minimum number of dumps at each level that must be done before the next higher level is even considered. bumpdays is often recommended to be set to > 1. The rationale being that if you have two level 1 dumps, one could be lost without much concern. But if you only have a single level 1, losing it could be a big problem. I question your multiplier in "bumpmult 4.0". It says to go from level 1 to level 2 the level 2 needs to be 20% smaller than the level 1. But to go to level 3, the size of the expected level 3 dump must be 80% (4.0 x 20%) smaller than the expected size of a level 2. And it will be really hard to get to level 4 as it must be 320% smaller than the expected level 3 (4.0 x 80%). I'd suggest picking a bumpdays with which you are comfortable, get that multiplier down (1.0? 1.2?), comment out bumpsize, then see if 20% gives you what you want, if not start adjusting it. BTW, if you make a specific dumptype for that DLE, you can play with the bump settings in that one dumptype definition without affecting other DLEs. They would be using the global values. Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: bump* dumptype parameters tuning
Hi, * Jon LaBadie [20180409 17:34]: > On Mon, Apr 09, 2018 at 01:20:05PM -0400, Jean-Francois Malouin wrote: > > Hi, > > > > It's with some shame that I must admit that through the long years of using > > amanda I've never really played with the bump* parameters for DLEs! > > > > I'm now in a situation that might benefit from some tuning using those > > to aggressively encourage bumping the gnutar incremental levels. The > > drawback of potentially needing more tapes for recovery is not really a > > constraint for me. > > > > I have a DLE (~5TB) for which the estimates are done on the server -- > > the client, a NAS/filer, doesn't support anything else, so the DLE usage > > info is really just from the historical usage not the current one. Any > > ideas/hints on how should I proceed from what is currently (default > > values I guess) configured? > > > > bumppercent 20 > > bumpsize20480K > > bumpdays1 > > bumpmult4.0 > > > > Would setting bumpdays to higher values (2 or 3 days) pull in the > > direction I want to go? > > > > Since bumppercent != 0, bumpsize is ignored from the man page, so I > > guess the only important parameter left is bumppercent. Should I > > increase it or decrease it? I'm having a hard time understanding what > > the doc says for amanda.conf says... > > As you note, your bumpsize is ignored. > > The bumpdays parameter gives the minimum number > of dumps at each level that must be done before > the next higher level is even considered. > > bumpdays is often recommended to be set to > 1. > The rationale being that if you have two level 1 > dumps, one could be lost without much concern. > But if you only have a single level 1, losing it > could be a big problem. > > I question your multiplier in "bumpmult 4.0". > It says to go from level 1 to level 2 the level 2 > needs to be 20% smaller than the level 1. But > to go to level 3, the size of the expected level 3 > dump must be 80% (4.0 x 20%) smaller than the > expected size of a level 2. And it will be really > hard to get to level 4 as it must be 320% smaller > than the expected level 3 (4.0 x 80%). > > I'd suggest picking a bumpdays with which you are > comfortable, get that multiplier down (1.0? 1.2?), > comment out bumpsize, then see if 20% gives you > what you want, if not start adjusting it. > > BTW, if you make a specific dumptype for that > DLE, you can play with the bump settings in that > one dumptype definition without affecting other > DLEs. They would be using the global values. Thank you for the explanations. I will start experimenting with: bumppercent 20 bumpdays 2 bumpmult 1.2 and what it leads to. Kind regards, jf > > Jon > -- > Jon H. LaBadie j...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C)
Re: MSG: planner: Preventing bump of ...
Hello Floriano, You did a 'amadmin force-no-bump prods6.hc.unicamp.br //samara/Projetos' The command is in effect until the dump is written to tape. Jean-Louis On Fri, Oct 25, 2002 at 10:06:14AM +, Prods6 - AMANDA - Bkp Mannager wrote: > Friends, please ... > > During amanda bkp process, I had been received the message > ==>> planner: Preventing bump of ... <<== > Always the msg is for the same directory. > > Is this a problem or just an information message ? > > See the report: > === > > NOTES: > . . . > planner: Skipping full dump of prods6.hc.unicamp.br://samara/Projetos > tomorrow. > ===>>> planner: Preventing bump of > prods6.hc.unicamp.br://samara/Projetos as directed. > planner: Skipping full dump of > prods6.hc.unicamp.br://samara/QUALIDADE tomorrow. > . . . > > DUMP SUMMARY: >DUMPER > STATSTAPER STATS > HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS > KB/s MMM:SS KB/s > > - > . . . > prods6.hc //pdchc/gsi 1 111395 16435 14.8 0:29 > 570.7 N/A N/A > ===>>>prods6.hc //samara/Projetos12152500 23.2 > 3:10 2.6 N/A N/A > prods6.hc //samara/QUALIDADE 11971972 49.3 1:01 > 16.0 N/A N/A > prods6.hc //samara/SWDES 1 17654 2332 13.2 0:14 > 163.8 N/A N/A > prods6.hc //samara/Secretaria 12055416 20.2 0:09 > 46.9 N/A N/A > prods6.hc //samara/VB_INT 14793 1282 26.7 0:51 > 25.1 N/A N/A > prods6.hc //samara/prods5-bkp 1 115276 106555 92.4 3:28 > 511.4 N/A N/A > prods6.hc /nihc_home 5 365620 278518 76.2 5:33 > 836.0 N/A N/A > prods6.hc /nihc_var5 501690 220733 44.0 7:06 > 518.0 N/A N/A > . . . > > (brought to you by Amanda version 2.4.3b4) > == > > Tks so much, Floriano > > ==>> this msg occurs with FULL or INC bkp preocess !! > > best regards . > == -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: bump to 2 means 0?
Hi, Yes, seen that message many times. What happens is following: planner decides the savings would let the drive bump to level 2, produces this message and goes on with planning. Later it finds out, this drive is due for a level 0, so it skips the bump and does a level 0 instead. Quite normal, nothing to worry about. Christoph Galen Johnson schrieb: Hey Gang, Anyone seen this before? NOTES: planner: Incremental of www.thepilot.com:/usr/local/apache bumped to level 2. yet the actual summary says: DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- --- www.thepilot.com /usr/local/apache 0 1085260 170688 15.7 7:21 387.0 0:58 2929.5 Notice it shows that it did a full... It appears to have gotten all of it but I'm just curious as to why planner said level to but it actually performed a level 0. =G=
Does 'force bump' roughly equate to 'strategy incronly'?
One day next week I want to prevent any level 0 dumps, and run only incrementals for that one night. It's not obvious to me from the docs that 'amadmin force bump' will actually prevent amanda from concluding that it's time for a level 0. Would 'force bump' serve my purpose? (My guess = no.) There is more than one runcycle in our tape cycle, and we won't be over-writing the most recent level 0 for any dump. I recognize that changing strategy to 'incronly' for all dumptypes in amanda.conf should have the desired effect, but would prefer to do this through amadmin. TIA. Bryan
Re: Does 'force bump' roughly equate to 'strategy incronly'?
On Wed, Dec 21, 2011 at 10:01:36AM -0500, Bryan Hodgson wrote: > > One day next week I want to prevent any level 0 dumps, and run only > incrementals for that one night. > > It's not obvious to me from the docs that 'amadmin force bump' will > actually prevent amanda from concluding that it's time for a level > 0. Would 'force bump' serve my purpose? (My guess = no.) > > There is more than one runcycle in our tape cycle, and we won't be > over-writing the most recent level 0 for any dump. > I looked at the man page and I agree the question is not addressed: "if a level 0 were due, would force-bump cause an incremental instead?" Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
Re: Does 'force bump' roughly equate to 'strategy incronly'?
On Wed, Dec 21, 2011 at 01:11:00PM -0500, Jon LaBadie wrote: > On Wed, Dec 21, 2011 at 10:01:36AM -0500, Bryan Hodgson wrote: > > > > One day next week I want to prevent any level 0 dumps, and run only > > incrementals for that one night. > > > > It's not obvious to me from the docs that 'amadmin force bump' will > > actually prevent amanda from concluding that it's time for a level > > 0. Would 'force bump' serve my purpose? (My guess = no.) > > > > There is more than one runcycle in our tape cycle, and we won't be > > over-writing the most recent level 0 for any dump. > > > I looked at the man page and I agree the question is not addressed: > "if a level 0 were due, would force-bump cause an incremental instead?" > > Jon Okay, so it's not just me. Thanks. 124 file systems, 2 are due today, all others are due for level 0 in 4 to 6 days. And, of course, amanda usually moves some forward early. Okay, so I switched dumpcycle to 3 and all DLEs to force-bump for tonight's run. amadmin due now thinks there are some level 0's due today. We'll see what happens. Bryan
Re: Does 'force bump' roughly equate to 'strategy incronly'?
On Wed, Dec 21, 2011 at 03:42:32PM -0500, Bryan Hodgson wrote: > On Wed, Dec 21, 2011 at 01:11:00PM -0500, Jon LaBadie wrote: > > On Wed, Dec 21, 2011 at 10:01:36AM -0500, Bryan Hodgson wrote: > > > > > > One day next week I want to prevent any level 0 dumps, and run only > > > incrementals for that one night. > > > > > > It's not obvious to me from the docs that 'amadmin force bump' will > > > actually prevent amanda from concluding that it's time for a level > > > 0. Would 'force bump' serve my purpose? (My guess = no.) > > > > > > There is more than one runcycle in our tape cycle, and we won't be > > > over-writing the most recent level 0 for any dump. > > > > > I looked at the man page and I agree the question is not addressed: > > "if a level 0 were due, would force-bump cause an incremental instead?" > > > > Jon > > Okay, so it's not just me. Thanks. > > 124 file systems, 2 are due today, all others are due for level 0 in > 4 to 6 days. And, of course, amanda usually moves some forward > early. > > Okay, so I switched dumpcycle to 3 and all DLEs to force-bump for > tonight's run. amadmin due now thinks there are some level 0's due > today. We'll see what happens. > > Bryan > It didn't work. No obvious reason. planner results look okay, but amdump failed as soon as planner finished with all DLEs showing 'RESULTS MISSING' via amreport. Ran unforce-bump on DLEs, reset dumpcycle to its regular value, and amdump runs successfully. Not a problem, will steer a different course. Bryan
Re: Does 'force bump' roughly equate to 'strategy incronly'?
There is a planner bug with force-bump when a dle is overdue.
The attached patch should fix it.
As a workaround, you can set a large dumpcycle (eg. 1).
force-bump will prevent full, but it will also bump the level, this
might not be what you want.
Setting a large dumpcycle and a small maxpromoteday should do
incremental without bumping the level.
Jean-Louis
On 12/22/2011 07:20 AM, Bryan Hodgson wrote:
On Wed, Dec 21, 2011 at 03:42:32PM -0500, Bryan Hodgson wrote:
On Wed, Dec 21, 2011 at 01:11:00PM -0500, Jon LaBadie wrote:
On Wed, Dec 21, 2011 at 10:01:36AM -0500, Bryan Hodgson wrote:
One day next week I want to prevent any level 0 dumps, and run only
incrementals for that one night.
It's not obvious to me from the docs that 'amadmin force bump' will
actually prevent amanda from concluding that it's time for a level
0. Would 'force bump' serve my purpose? (My guess = no.)
There is more than one runcycle in our tape cycle, and we won't be
over-writing the most recent level 0 for any dump.
I looked at the man page and I agree the question is not addressed:
"if a level 0 were due, would force-bump cause an incremental instead?"
Jon
Okay, so it's not just me. Thanks.
124 file systems, 2 are due today, all others are due for level 0 in
4 to 6 days. And, of course, amanda usually moves some forward
early.
Okay, so I switched dumpcycle to 3 and all DLEs to force-bump for
tonight's run. amadmin due now thinks there are some level 0's due
today. We'll see what happens.
Bryan
It didn't work. No obvious reason. planner results look okay, but
amdump failed as soon as planner finished with all DLEs showing
'RESULTS MISSING' via amreport. Ran unforce-bump on DLEs, reset
dumpcycle to its regular value, and amdump runs successfully.
Not a problem, will steer a different course.
Bryan
diff --git a/server-src/planner.c b/server-src/planner.c
index 4e70e24..5b61c97 100644
--- a/server-src/planner.c
+++ b/server-src/planner.c
@@ -3051,7 +3051,8 @@ static int promote_hills(void)
}
for(dp = schedq.head; dp != NULL; dp = dp->next) {
- days = est(dp)->next_level0; /* This is > 0 by definition */
+ days = est(dp)->next_level0;
+ if (days < 0) days = 0;
if(daysskip_full && dp->strategy != DS_NOFULL &&
dp->strategy != DS_INCRONLY) {
sp[days].disks++;
