Re: explanation of the following dump reports -
On Sat, Nov 11, 2000 at 05:25:35AM -0200, Alexandre Oliva wrote: IIRC, some people have reported that it won't bump to higher-level incrementals before the lower-level ones make it to tape. I.e., it doesn't ``trust'' incrementals in the holding disk. IMO, it should. It depend of the `reserve' parameter in 2.4.1p1, it must 100 to trust the dump in the holding disk. In 2.4.2, it always trust the dump in the holding disk, maybe we should use a parameter for this. Jean-Louis -- 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: explanation of the following dump reports -
On Nov 11, 2000, Jean-Louis Martineau [EMAIL PROTECTED] wrote:
On Sat, Nov 11, 2000 at 05:25:35AM -0200, Alexandre Oliva wrote:
IIRC, some people have reported that it won't bump to higher-level
incrementals before the lower-level ones make it to tape. I.e., it
doesn't ``trust'' incrementals in the holding disk. IMO, it should.
It depend of the `reserve' parameter in 2.4.1p1, it must 100 to
trust the dump in the holding disk.
In 2.4.2, it always trust the dump in the holding disk, maybe we
should use a parameter for this.
I could have sworn people have reported the behavior I describe above
against 2.4.2-beta1. But, if you say so, I believe you :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: explanation of the following dump reports -
It depend of the `reserve' parameter in 2.4.1p1, it must 100 to trust the dump in the holding disk. Are you saying all Denise has to do to get the daily bumps is set "reserve" to 99? Jean-Louis John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: explanation of the following dump reports -
On Sat, Nov 11, 2000 at 11:50:59AM -0500, John R. Jackson wrote: It depend of the `reserve' parameter in 2.4.1p1, it must 100 to trust the dump in the holding disk. Are you saying all Denise has to do to get the daily bumps is set "reserve" to 99? Yep, It should work. Jean-Louis -- 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: explanation of the following dump reports -
Denise Ives wrote: Can anyone please explain to me what Amanda did here after the full dump to tape daily118 on Tuesday 7 Nov 2000 ? To me it looks like Amanda did a level 1 dump on Wednesday am to the holding disk, then another level 1 dump on Thursday am, then another level 1 on Friday am. Yes, exactly. Your AMANDA works fine, where is the problem? You don't have any tape in the drive, so it dumps to the holding disk. You just have to use amflush to flush the images onto tape. Bump level is set to 0. In my amanda.conf I see bumpsize 50 Mb # minimum savings (threshold) to bump level 1 - 2 bumpdays 2 # minimum days at each level bumpmult 1.5# threshold = bumpsize * bumpmult^(level-1) but not "bump level" as parameter which one could set. The bump level is indirectly determined by AMANDA under consideration of the above parameters. Again, I don't see anything wrong here. Also what promoted from x days ahead? (planner: Full dump of admin1.corp.walid.com:sda9 promoted from 4 days ahead.) Typical computer program output in english - the verb "was" was deliberately eaten up. Examples: "Done", meaning "We are done", not "We have done something". "File saved", meaning "File was saved", not "File saved something". "Dump promoted", meaning "Dump was promoted", not "Dump promoted something". If you ask "promoted what?" here, then you understand it in the last meaning, which was not the intended one. In brief, it's passive voice, not active, just the verb is omitted for brevity. What I really disgust, is something similar that has crept in the english language used by computer professionals: "The program does not compile" - compile _what_? "The software ships with a CD" - ships _what_? In this situation, to ask "what" is justified, because here we don't just omit something for brevity, we rape a language - but that's another story. -- Regards Chris Karakas Dont waste your cpu time - crack rc5: http://www.distributed.net
Re: explanation of the following dump reports -
... To me it looks like Amanda did a level 1 dump on Wednesday am to the holding disk, then another level 1 dump on Thursday am, then another level 1 on Friday am. Yes, exactly. Your AMANDA works fine, where is the problem? The problem is that off line of discussions on this list, I suggested Denise change the various bump* parameters to zero to try and make Amanda bump levels every day. The theory being that this would minimize the size of each image in the holding disk and so she would get as much as possible in there during the week. Chris is correct that in a normal arrangement, doing the same level over and over is expected behavior. But in Denise's case it didn't do what she (or I) expected. Since this was my bright idea :-), Denise, could you E-mail mail to me (and not the list -- just to avoid the noise) the amdump.NN files that go along with the reports you sent in this thread (7, 8, 9 of Nov)? I'll look through what planner was doing and see if I can figure out what went "wrong". Note that nothing is really bad in this setup. The dumps you got are perfectly valid. They just take up more holding disk space than you might like. One final question. You don't happen to have "record no" still set from some testing, do you? Actually, why don't you go ahead and E-mail me your amanda.conf and disklist, too. And please E-mail them direct, i.e. attachments or stdin to your mailer. If you use copy/paste, things get badly mangled. If that's a problem, let me know and I'll set up a temporary ftp drop area. Also what promoted from x days ahead? (planner: Full dump of admin1.corp.walid.com:sda9 promoted from 4 days ahead.) Again, in the normal setup (definitely **not** Denise's :-), Amanda would try to "balance" the full dumps across the dumpcycle so roughly the same amount of work is done each day. It's just telling you that it is trying to do that (move a full dump earlier than expected). In your case it doesn't matter because you don't have a tape in the drive and any full dumps planner schedules will be ignored in favor of the degraded mode partial. Denise Ives Chris Karakas John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: explanation of the following dump reports -
On Nov 10, 2000, "John R. Jackson" [EMAIL PROTECTED] wrote:
... To me it looks like Amanda did a
level 1 dump on Wednesday am to the holding disk, then another level 1
dump on Thursday am, then another level 1 on Friday am.
The problem is that off line of discussions on this list, I suggested
Denise change the various bump* parameters to zero to try and make Amanda
bump levels every day.
IIRC, some people have reported that it won't bump to higher-level
incrementals before the lower-level ones make it to tape. I.e., it
doesn't ``trust'' incrementals in the holding disk. IMO, it should.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
