amanda report

[ddaasd]

Hello,
I
am not very
confident with amanda report.
 
Can
anyone
explain me what mean the following:
 
1.
planner:
Incremental of server:/home/samba/pub bumped to level 2.
 
2.  planner: Full dump of server:/var/lib
promoted from 6 days ahead.
 
3.
planner:
Last full dump of server:/src on tape MyDaily overwritten in 2 runs. 
 
 
I
am not sure
what bumped to level 2, promoted from 6 days ahead and overwritten in 2
runs
mean.
 
Also
I would
like to know, how Amanda chooses when to make a full backup or an
incremental
one.
 

-- 
ddaas

amanda report

[Michael P. Blinn]

  A few questions about my report. I have a cron set to force level 0 dumps
a minute or two before the actual backup goes into place so that I can get a
full level 0 on each tape.

I understand "can't switch to incremental dump" because it was forced to be
dump 0, right?

But why would the entire backup fail for this one machine? It is on and
available!

Thanks in advance,
  -Michael Blinn


> FAILURE AND STRANGE DUMP SUMMARY:
>   mail   /configs lev 0 FAILED [can't switch to incremental dump]
>   mail   /var/lib/mysql lev 0 FAILED [can't switch to incremental
dump]
>   mail   /usr/local/apache lev 0 FAILED [can't switch to incremental
dump]
>
>
> STATISTICS:
>   Total   Full  Daily
>       
> Estimate Time (hrs:min)0:00
> Run Time (hrs:min) 0:12
> Dump Time (hrs:min)0:12   0:00   0:12
> Output Size (meg) 158.60.0  158.6
> Original Size (meg)   607.40.0  607.4
> Avg Compressed Size (%)26.1--26.1   (level:#disks ...)
> Filesystems Dumped2  0  2   (1:2)
> Avg Dump Rate (k/s)   221.6--   221.6
>
> Tape Time (hrs:min)0:00   0:00   0:00
> Tape Size (meg) 0.00.00.0
> Tape Used (%)   0.00.00.0
> Filesystems Taped 0  0  0
> Avg Tp Write Rate (k/s) -- -- --
>
>
> NOTES:
>   planner: Adding new disk mail:/usr/local/apache.
>   planner: Adding new disk mail:/var/lib/mysql.
>   planner: Adding new disk mail:/configs.
>   planner: Last full dump of localhost://ntserver/ppidocs on tape daily5
overwritten in 2 runs.
>
>
> DUMP SUMMARY:
>  DUMPER STATSTAPER STATS
> HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS  KB/s
> -- - 
> localhost-sinesswork 1   19320   3968  20.5   0:54  73.7   N/A   N/A
> localhost-er/ppidocs 1  602623 158400  26.3  11:19 233.3   N/A   N/A
> mail /configs0 FAILED ---
> mail -cal/apache 0 FAILED ---
> mail -/lib/mysql 0 FAILED ---
>
> (brought to you by Amanda version 2.4.2p2)

Re: amanda report

[Jon LaBadie]

On Fri, Feb 25, 2005 at 04:01:38PM +0100, ddaasd wrote:
> 
> 
> 


Could you please post in text, not html.
I'd like to read your messages and possibly respond.


-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: amanda report

[Gene Heskett]

On Friday 25 February 2005 10:01, ddaasd wrote:

First, Please do not post in html.  Many of us do not automaticly 
decode html because of the security aspects.  Set your mail agent to 
text only.

>Hello,
>I am not very confident with amanda report.
>Can anyone explain me what mean the following:
>1. planner: Incremental of server:/home/samba/pub bumped to level 2.
>2.  planner: Full dump of server:/var/lib promoted from 6 days
> ahead.
>3. planner: Last full dump of server:/src on tape MyDaily
> overwritten in 2 runs.
>I am not sure what bumped to level 2, promoted from 6 days ahead and
> overwritten in 2 runs mean.
>Also I would like to know, how Amanda chooses when to make a full
> backup or an incremental one.

The above is strictly advisory on the part of amanda, its adjusting 
the schedule with an eye toward equalizing the amount of media used 
on each run.  Amanda will, particularly for the first few tapecycle's 
worth of runs, actively move the level 0 and incrementals around 
within the dumpcycle time period as amanda tries to accomplish this.  
The only thing that will disturb this is if you actually have more 
data to backup than you have tape capacity available to do in the 
allotted dumpcycle days.  In forceing the issue here, I have never, 
ever seen amanda put off a level 0 that was due by more than 2 days.  
The fact that it has to do that is evidence that your dumpcycle is 
too short for the amount of data, or you just started and the 
disklist wasn't commented such that approximately a tapes full of new 
dle's are done each night until the whole list is exposed.

You can also help amanda in the balanceing dept by using many small 
dle entries as opposed to just one big / entry, as this gives amanda 
a much more fine grained view of the system.  Doing 2 machines here, 
I have about 50 dle's specified, and the media usage is about 87% 
every night, and no one dle exceeds 4GB, with many under 200 megs.  
You'll have to use tar, not dump, in order to do that.  Each has its 
own set of warts of course, but in the long run most of us have come 
into the tar camp.  There are version problems with tar, so make sure 
its one of 1.13-19, 1.13-25, or 1.15-1.  1.13 (no suffix) in 
particular is badly borked.  I've been using 1.15-1 here for about a 
month, and so far there have been no 'glitches'.

Amanda's general view of how to do it means that the level 0's are 
scattered among the last dumpcycle's used tapes, so that at any one 
time, a full, neary bare metal recovery is the last 'dumpcycle's 
worth of tapes.  Call it a set if you'd like.  There is no concept of 
a full on this tape, and the incrementals on the next x tapes as 
thats extremely wastefull of the tape media.

Similarly, you can get a pretty good idea of whats compressable, and 
what isn't by setting the individual dle's to a compressing made, 
then inpecting your emails for the compression achieved when 
processing that dle.  Those dle's that only compress to 85% would be 
good ones to switch the dumptype on so that the system doesn't waste 
a lot of time trying to squeeze the last byte out of a file thats not 
compressible.  A whole dir full of tar.gz or .bz2's?   Forget it, 
they aren't going to compress near enough to make the cpu spinning 
worth the effort.  OTOH, I have a couple of dle's that happily 
conpress to less than 10% of their uncompressed size.

You'll soon get the feel for amanda I think, and amanda IS looking out 
for your best interests.  Use the emails you get to do some judicious 
fine tuning here and there and in a little while it will be marching 
along smoothly with your only job being to keep amanda supplied with 
usable media for the next run.

The only thing that bothers me about what you posted is the tapes 
name.  It seems to imply that its the only tape you have, and thats 
not a workable solution unless your dumpcycle is 0, forcing a full of 
everything on every run.  I don't really think thats what you wanted.

See the amanda.conf entry about tape names, and just set them as 
MyDaily-01 thru MyDaily-xx where xx is the number set in the 
'tapecycle' entry in your amanda.conf file.  Because of holidays & 
people forgetting to load the right tape(s), there isn't much hope 
for those who think they can label a tape 'Monday', and have it still 
being used on Monday 2 weeks down the log.  The chances of that 
actually happening are somewhere between zilch and point oh oh oh 
zip.  You will get our sympathies, and a couple of "I told you so's", 
but not much else, usually tendered with a smiley :-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

re: amanda report

[ddaasd]

Hi guys,
Sorry that I've sent the email in HTML format. I didn't know that some 
of you prefer text based mails.

--
Best regards,
ddaas

Re: amanda report

[ddaasd]

Alex, thanks again. It's clearer now.
Best regards,
ddaas
Alexander Jolk wrote:
Hi,
actually, have you read `the chapter'?  Go to www.amanda.org, it is 
linked from the front page.  Many of your questions are answered in 
great detail over there.

1. planner: Incremental of server:/home/samba/pub bumped to level 2.

Just a note to you, amanda is doing a level 2 on this host.
2.  planner: Full dump of server:/var/lib promoted from 6 days ahead.

Another note to you, that DLE could have waited another 6 days before 
needing a full, but amanda thought it more efficient to schedule a full 
right now.  You know that amanda tries hard to do a full backup at most 
every `dumpcycle' days, but this time, she found a full wouldn't need 
much less space than an incremental, so she went ahead for the full.

3. planner: Last full dump of server:/src on tape MyDaily overwritten 
in 2 runs.

Exactly what it says.  You have only one full dump of this DLE, it's on 
tape `MyDaily' which is scheduled to be overwritten in 2 runs.  Unless 
you add more tapes before that day.  And I don't know whether she hasn't 
done a full on this run, or will do on her next.

Also I would like to know, how Amanda chooses when to make a full 
backup or an incremental one.

At least 1 full every dumpcycle days; in between, incrementals iff the 
space savings are big enough.  See amanda.conf with the parameters 
bumpsize and friends.

Alex

Re: amanda report

[ddaasd]

Sorry for the html post. I didn't know.
> The only thing that bothers me about what you posted is the tapes
> name.  It seems to imply that its the only tape you have, and thats
> not a workable solution unless your dumpcycle is 0, forcing a full of
> everything on every run.  I don't really think thats what you wanted.
I didn't receive those messages from planner in only one report. I've 
received them from time to time. I've just written everything that was 
unclear to me.

I have 8 tapes. This is enaugh for a weeek. I've already ordered another 
8 tapes for one more week.

Best regards,
ddaas
Gene Heskett wrote:
On Friday 25 February 2005 10:01, ddaasd wrote:
First, Please do not post in html.  Many of us do not automaticly 
decode html because of the security aspects.  Set your mail agent to 
text only.


Hello,
I am not very confident with amanda report.
Can anyone explain me what mean the following:
1. planner: Incremental of server:/home/samba/pub bumped to level 2.
2.  planner: Full dump of server:/var/lib promoted from 6 days
ahead.
3. planner: Last full dump of server:/src on tape MyDaily
overwritten in 2 runs.
I am not sure what bumped to level 2, promoted from 6 days ahead and
overwritten in 2 runs mean.
Also I would like to know, how Amanda chooses when to make a full
backup or an incremental one.

The above is strictly advisory on the part of amanda, its adjusting 
the schedule with an eye toward equalizing the amount of media used 
on each run.  Amanda will, particularly for the first few tapecycle's 
worth of runs, actively move the level 0 and incrementals around 
within the dumpcycle time period as amanda tries to accomplish this.  
The only thing that will disturb this is if you actually have more 
data to backup than you have tape capacity available to do in the 
allotted dumpcycle days.  In forceing the issue here, I have never, 
ever seen amanda put off a level 0 that was due by more than 2 days.  
The fact that it has to do that is evidence that your dumpcycle is 
too short for the amount of data, or you just started and the 
disklist wasn't commented such that approximately a tapes full of new 
dle's are done each night until the whole list is exposed.

You can also help amanda in the balanceing dept by using many small 
dle entries as opposed to just one big / entry, as this gives amanda 
a much more fine grained view of the system.  Doing 2 machines here, 
I have about 50 dle's specified, and the media usage is about 87% 
every night, and no one dle exceeds 4GB, with many under 200 megs.  
You'll have to use tar, not dump, in order to do that.  Each has its 
own set of warts of course, but in the long run most of us have come 
into the tar camp.  There are version problems with tar, so make sure 
its one of 1.13-19, 1.13-25, or 1.15-1.  1.13 (no suffix) in 
particular is badly borked.  I've been using 1.15-1 here for about a 
month, and so far there have been no 'glitches'.

Amanda's general view of how to do it means that the level 0's are 
scattered among the last dumpcycle's used tapes, so that at any one 
time, a full, neary bare metal recovery is the last 'dumpcycle's 
worth of tapes.  Call it a set if you'd like.  There is no concept of 
a full on this tape, and the incrementals on the next x tapes as 
thats extremely wastefull of the tape media.

Similarly, you can get a pretty good idea of whats compressable, and 
what isn't by setting the individual dle's to a compressing made, 
then inpecting your emails for the compression achieved when 
processing that dle.  Those dle's that only compress to 85% would be 
good ones to switch the dumptype on so that the system doesn't waste 
a lot of time trying to squeeze the last byte out of a file thats not 
compressible.  A whole dir full of tar.gz or .bz2's?   Forget it, 
they aren't going to compress near enough to make the cpu spinning 
worth the effort.  OTOH, I have a couple of dle's that happily 
conpress to less than 10% of their uncompressed size.

You'll soon get the feel for amanda I think, and amanda IS looking out 
for your best interests.  Use the emails you get to do some judicious 
fine tuning here and there and in a little while it will be marching 
along smoothly with your only job being to keep amanda supplied with 
usable media for the next run.

The only thing that bothers me about what you posted is the tapes 
name.  It seems to imply that its the only tape you have, and thats 
not a workable solution unless your dumpcycle is 0, forcing a full of 
everything on every run.  I don't really think thats what you wanted.

See the amanda.conf entry about tape names, and just set them as 
MyDaily-01 thru MyDaily-xx where xx is the number set in the 
'tapecycle' entry in your amanda.conf file.  Because of holidays & 
people forgetting to load the r

Re: amanda report

[Gene Heskett]

On Saturday 26 February 2005 12:58, ddaasd wrote:
>Sorry for the html post. I didn't know.
>
> > The only thing that bothers me about what you posted is the tapes
> > name.  It seems to imply that its the only tape you have, and
> > thats not a workable solution unless your dumpcycle is 0, forcing
> > a full of everything on every run.  I don't really think thats
> > what you wanted.
>
>I didn't receive those messages from planner in only one report.
> I've received them from time to time. I've just written everything
> that was unclear to me.

I see.

>I have 8 tapes. This is enaugh for a weeek. I've already ordered
> another 8 tapes for one more week.
>
Good.  This will allow a much saner dumpcycle and tapecycle setting.

Suggestion.  Don't put them all in the tapecycle, save back the last 1 
or 2 so that if a tape should upchuck for some reason, you have an 
instant spare that only needs to be labeled with the next number in 
the sequence (don't re-use an old label, at least till that label is 
expired at the end of tapecycle by amanda) and placed in service.

[...]

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: amanda report

[ddaasd]

So, I will have 16 tapes. How can I optimize their usage?
You say I should keep 1 or 2 tapes to replace a defect one. So I have 15 
working tapes.

I would like not to backup in weekend because there is no activity.
My Dell PowerVault has an auto-changer with 8 slots for 8 tapes.
I would like to have 8 tapes offsite and to change them once a week.
What would be your values for the most important parameters from 
amanda.conf (dumpcycle, runspercycle, runtapes etc).

Thanks a lot,
ddaas
Gene Heskett wrote:
I have 8 tapes. This is enaugh for a weeek. I've already ordered
another 8 tapes for one more week.
Good.  This will allow a much saner dumpcycle and tapecycle setting.
Suggestion.  Don't put them all in the tapecycle, save back the last 1 
or 2 so that if a tape should upchuck for some reason, you have an 
instant spare that only needs to be labeled with the next number in 
the sequence (don't re-use an old label, at least till that label is 
expired at the end of tapecycle by amanda) and placed in service.

[...]

Re: amanda report

[Gene Heskett]

On Saturday 26 February 2005 15:19, ddaasd wrote:
>So, I will have 16 tapes. How can I optimize their usage?
>You say I should keep 1 or 2 tapes to replace a defect one. So I
> have 15 working tapes.
>
>I would like not to backup in weekend because there is no activity.
>
>My Dell PowerVault has an auto-changer with 8 slots for 8 tapes.
>I would like to have 8 tapes offsite and to change them once a week.

Unless you are going to use a runtapes greater than 1, you will not 
use 8 tapes a week when the runspercycle is only 5.  Thats up to you.  
However, if in a given week, you only actually used 6 tapes, then 
amanda will get upset if you take all 8 tapes offsite.

I don't recall what the capacity of a powervault tape is so you'll 
have to judge that for yourself.  I think what you will wind up doing 
though, is to remove for offsite storage, only those tapes that have 
actually been used according to the emails it will send you, or from 
the printouts if you have that enabled, something I'd also recommend.
Whether its 8 tapes if it runs to the second tape some nights AND you 
have runtapes = 2, or 5 (the minimum it would use in 5 runs that 
week), those are the ones that should go to offsite storage.

I detect a bit of do it my way urge in these messages, rather than 
amanda's way, and while you may be able to force the issue by 
constraining amanda, amanda will work much better in the long run if 
you just let amanda do what amanda does best.  You will get more 
efficiency in terms of tape use by just letting amanda 'do her 
thing'.  It rather reminds me of an old saw about dogs and cats:

To a dog, you are the master.  To a cat, you are just staff.

Amanda is a cat.

>
>What would be your values for the most important parameters from
>amanda.conf (dumpcycle, runspercycle, runtapes etc).
>
I'd suggest:
dumpcycle 7, runspercycle 5, tapecycle 15.

This will, assuming 'runtapes' defaults to 1, give you backups 3 
generations deep.  And one spare tape.  Also less paranoia about 
losing it all. :-)

This will work unless you have enough data to require a second (or 
more) tape per run.

>Thanks a lot,
>
>ddaas
>
>Gene Heskett wrote:

[...]

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: amanda report

[ddaasd]

Gene,
You helped me a lot. Thank you very much for your time. I am going to 
fallow your advice.

Best regards,
ddaas
Gene Heskett wrote:
On Saturday 26 February 2005 15:19, ddaasd wrote:
So, I will have 16 tapes. How can I optimize their usage?
You say I should keep 1 or 2 tapes to replace a defect one. So I
have 15 working tapes.
I would like not to backup in weekend because there is no activity.
My Dell PowerVault has an auto-changer with 8 slots for 8 tapes.
I would like to have 8 tapes offsite and to change them once a week.

Unless you are going to use a runtapes greater than 1, you will not 
use 8 tapes a week when the runspercycle is only 5.  Thats up to you.  
However, if in a given week, you only actually used 6 tapes, then 
amanda will get upset if you take all 8 tapes offsite.

I don't recall what the capacity of a powervault tape is so you'll 
have to judge that for yourself.  I think what you will wind up doing 
though, is to remove for offsite storage, only those tapes that have 
actually been used according to the emails it will send you, or from 
the printouts if you have that enabled, something I'd also recommend.
Whether its 8 tapes if it runs to the second tape some nights AND you 
have runtapes = 2, or 5 (the minimum it would use in 5 runs that 
week), those are the ones that should go to offsite storage.

I detect a bit of do it my way urge in these messages, rather than 
amanda's way, and while you may be able to force the issue by 
constraining amanda, amanda will work much better in the long run if 
you just let amanda do what amanda does best.  You will get more 
efficiency in terms of tape use by just letting amanda 'do her 
thing'.  It rather reminds me of an old saw about dogs and cats:

To a dog, you are the master.  To a cat, you are just staff.
Amanda is a cat.

What would be your values for the most important parameters from
amanda.conf (dumpcycle, runspercycle, runtapes etc).
I'd suggest:
dumpcycle 7, runspercycle 5, tapecycle 15.
This will, assuming 'runtapes' defaults to 1, give you backups 3 
generations deep.  And one spare tape.  Also less paranoia about 
losing it all. :-)

This will work unless you have enough data to require a second (or 
more) tape per run.


Thanks a lot,
ddaas
Gene Heskett wrote:

[...]

Re: amanda report

[Jon LaBadie]

On Sat, Feb 26, 2005 at 09:19:49PM +0100, ddaasd wrote:
> So, I will have 16 tapes. How can I optimize their usage?
> You say I should keep 1 or 2 tapes to replace a defect one. So I have 15 
> working tapes.
> 
> I would like not to backup in weekend because there is no activity.
> 
> My Dell PowerVault has an auto-changer with 8 slots for 8 tapes.
> I would like to have 8 tapes offsite and to change them once a week.
> 
> 
> What would be your values for the most important parameters from 
> amanda.conf (dumpcycle, runspercycle, runtapes etc).
> 

You and Gene seem to have settled on 7,5,1, and 15 or 16 for tapecycle.

Given that, for offsite I'd suggest you consider your tapes as groups
of 5, i.e. 3 groups.  One group will be in use, one group offsite,
and the final group will be either the next group to be in use or
the group that was most recently in use.  The former ensures you
are ready to switch groups over the weekend, the latter keeps some
more recent backups on-site for recovery.

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: amanda report

[Joshua Baker-LePain]

On Wed, 31 Jul 2002 at 9:47am, Michael P. Blinn wrote

>   A few questions about my report. I have a cron set to force level 0 dumps
> a minute or two before the actual backup goes into place so that I can get a
> full level 0 on each tape.

Why do it that way?  Just use 'dumpcycle 0' and it should do the same 
thing.

> I understand "can't switch to incremental dump" because it was forced to be
> dump 0, right?

Sort of.  You don't seem to be using a tape, so amanda was probably in 
degraded mode.  What is your reserve set to in amanda.conf?  If it's the 
default, there's no room saved in degraded mode for level 0s, and you're 
not letting it switch to incrementals, thus the FAILs.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Re: amanda report

[Mitch Collinsworth]

Hmm...  Looks like you didn't have a (usable) tape in the drive.
Were the level 0 dumps of these new disks bigger than would fit on
your holding disk(s)?

-Mitch


On Wed, 31 Jul 2002, Michael P. Blinn wrote:

>   A few questions about my report. I have a cron set to force level 0 dumps
> a minute or two before the actual backup goes into place so that I can get a
> full level 0 on each tape.
>
> I understand "can't switch to incremental dump" because it was forced to be
> dump 0, right?
>
> But why would the entire backup fail for this one machine? It is on and
> available!
>
> Thanks in advance,
>   -Michael Blinn
>
>
> > FAILURE AND STRANGE DUMP SUMMARY:
> >   mail   /configs lev 0 FAILED [can't switch to incremental dump]
> >   mail   /var/lib/mysql lev 0 FAILED [can't switch to incremental
> dump]
> >   mail   /usr/local/apache lev 0 FAILED [can't switch to incremental
> dump]
> >
> >
> > STATISTICS:
> >   Total   Full  Daily
> >       
> > Estimate Time (hrs:min)0:00
> > Run Time (hrs:min) 0:12
> > Dump Time (hrs:min)0:12   0:00   0:12
> > Output Size (meg) 158.60.0  158.6
> > Original Size (meg)   607.40.0  607.4
> > Avg Compressed Size (%)26.1--26.1   (level:#disks ...)
> > Filesystems Dumped2  0  2   (1:2)
> > Avg Dump Rate (k/s)   221.6--   221.6
> >
> > Tape Time (hrs:min)0:00   0:00   0:00
> > Tape Size (meg) 0.00.00.0
> > Tape Used (%)   0.00.00.0
> > Filesystems Taped 0  0  0
> > Avg Tp Write Rate (k/s) -- -- --
> >
> >
> > NOTES:
> >   planner: Adding new disk mail:/usr/local/apache.
> >   planner: Adding new disk mail:/var/lib/mysql.
> >   planner: Adding new disk mail:/configs.
> >   planner: Last full dump of localhost://ntserver/ppidocs on tape daily5
> overwritten in 2 runs.
> >
> >
> > DUMP SUMMARY:
> >  DUMPER STATSTAPER STATS
> > HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS  KB/s
> > -- - 
> > localhost-sinesswork 1   19320   3968  20.5   0:54  73.7   N/A   N/A
> > localhost-er/ppidocs 1  602623 158400  26.3  11:19 233.3   N/A   N/A
> > mail /configs0 FAILED ---
> > mail -cal/apache 0 FAILED ---
> > mail -/lib/mysql 0 FAILED ---
> >
> > (brought to you by Amanda version 2.4.2p2)
>
>

Re: amanda report

[Joshua Baker-LePain]

On Wed, 31 Jul 2002 at 10:07am, Michael P. Blinn wrote

> I have had dumpcycle set to 0 for months, and yet I continue to have lots of
> level 1 backups. I saw a post through the last about forcing it each day and
> thought this would cure the problem. - Will fixing the below (reserve) allow
> dumpcycle 0 to do its thing and negate the need for the force command?

Yep -- it should.

> I'm not using a tape because for some reason backups fail and the network
> dies whenever amdump runs to a bad tape. I couldn't find a utility to test
> tapes for back blocks (or whatever they're called on streaming media) so
> until I can find out which of my tapes are dying, I just amflush them the
> next day.

So, yes, you're in degraded mode.  Set your reserve to 90 (or higher) and 
have at it.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Re: amanda report

[Michael P. Blinn]

First off, thanks Joshua for responding so quickly.

> >   A few questions about my report. I have a cron set to force level 0
dumps
> > a minute or two before the actual backup goes into place so that I can
get a
> > full level 0 on each tape.
>
> Why do it that way?  Just use 'dumpcycle 0' and it should do the same
> thing.

I have had dumpcycle set to 0 for months, and yet I continue to have lots of
level 1 backups. I saw a post through the last about forcing it each day and
thought this would cure the problem. - Will fixing the below (reserve) allow
dumpcycle 0 to do its thing and negate the need for the force command?

> > I understand "can't switch to incremental dump" because it was forced to
be
> > dump 0, right?
>
> Sort of.  You don't seem to be using a tape, so amanda was probably in
> degraded mode.  What is your reserve set to in amanda.conf?  If it's the
> default, there's no room saved in degraded mode for level 0s, and you're
> not letting it switch to incrementals, thus the FAILs.

I'm not using a tape because for some reason backups fail and the network
dies whenever amdump runs to a bad tape. I couldn't find a utility to test
tapes for back blocks (or whatever they're called on streaming media) so
until I can find out which of my tapes are dying, I just amflush them the
next day.

Thanks again,
  -Michael Blinn

Problem in Amanda Report

[Nicolas Maire]

Hi,
 
I'm a new user of Amanda. It's been running fine for some time since I got this job but I'm now getting a problem in the mail report of one of the backup servers, specifically in the Dump Summary : there are 2 result lines for each entrey in the disklist file, one says save was ok, the other just says MISSING. Here is an example (hostnames and directories generalized for security purposes) :

 
host1    /directory/saved 0 5820990    5821024 -- 268:26 361.4    4:30    21583.3
host1    /directory/saved MISSING
 
This happens for every host on that server, everyday since it started, whatever the dump level is and whether or not the dumps can fit in a single tape or need 2. This doesn't happen on the second backup server (cloned machine, except for the disklist).

 
Does anyone have an idea ?
ThanksNicolas Maire

unclear (wrong?) amanda report

[Henk Martijn]

Hi,

Today I found in amanda's report among others the following lines


NOTES:
  planner: Incremental of ursus:c0t3d0 bumped to level 2.
  taper: tape VOL6 kb 5810080 fm 23 [OK]

DUMP SUMMARY:
  DUMPER STATS  TAPER STATS
HOSTNAME  DISK   L  ORIG-KB   OUT-KB COMP%  MMM:SS   KB/s  MMM:SS   KB/s
-- -- --

ursus c0t3d0 0  5769600  5769600   --   121:10  793.6  121:11  793.5

(brought to you by Amanda version 2.4.1p1)


Planner says it will do a level 2 incremental, but it does a level 0 
Why?

Henk Martijn
ACREO AB   
Electrum 236 Tel:+46 8 632 7795
S-164 40 KistaFax:+46 8 750 5430
Sweden   e-mail: [EMAIL PROTECTED]




BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Henk Martijn
TEL;WORK:08-632 77 95
ORG:;Bildgenerering / EIT
EMAIL;WORK;PREF:[EMAIL PROTECTED]
N:Martijn;Henk
X-GWUSERID:henmar
END:VCARD

regenerating an amanda report

[David Carter]

Hello all,

I didn't receive a mail report this morning from amanda, although I can see
that the backups completed successfully, and the tape contents look good. 

Is there a way I can re-generate the amdump report that I usually get via
email?

David Carter
McLeodUSA Information Systems
[EMAIL PROTECTED]
281-465-1835

Re: Problem in Amanda Report

[Olivier Nicole]

Hi,

This happens for every host on that server, everyday since it started, 
whatever the dump level is and whether or not the dumps can fit in a 
single tape or need 2. This doesn't happen on the second backup server 
(cloned machine, except for the disklist).
 
Does anyone have an idea ?


I would double check the disklist, copy disklist from one server to the 
other and see if anything similar could be reproduced.


Best regards,

Olivier

Re: unclear (wrong?) amanda report

[Johannes Niess]

"Henk Martijn" <[EMAIL PROTECTED]> writes:


[...]

> Planner says it will do a level 2 incremental, but it does a level 0.
> Why?

Henk,

I've seen this, too. I supect that "level 2" is the answer from the
client during estimate phase. After getting information from all
clients the server commands a level 0 because there is tape space/dump
cycle etc. The messages are a bit misleading.

Johannes Nieß

Re: regenerating an amanda report

[Bill Carlson]

On Wed, 15 Aug 2001, David Carter wrote:

> Hello all,
>
> I didn't receive a mail report this morning from amanda, although I can see
> that the backups completed successfully, and the tape contents look good.
>
> Is there a way I can re-generate the amdump report that I usually get via
> email?
>

Look at the amreport command (man amreport as well). You can point it at a
log file and it will regenerate the report. Very handy.

Later,

Bill Carlson
-- 
Systems Programmer[EMAIL PROTECTED]  | Anything is possible,
Virtual Hospital  http://www.vh.org/  | given time and money.
University of Iowa Hospitals and Clinics  |
Opinions are mine, not my employer's. |

Re: regenerating an amanda report

[Joshua Baker-LePain]

On Wed, 15 Aug 2001 at 1:37pm, David Carter wrote

> I didn't receive a mail report this morning from amanda, although I can see
> that the backups completed successfully, and the tape contents look good.
>
> Is there a way I can re-generate the amdump report that I usually get via
> email?
>
man amreport:

amreport [ config ] [ -l logfile ] [ -f outputfile ] [  -p postscriptfile ]

where logfile is the log.$DATE.$RUN file, outputfile is where you want the
report put if you don't want it emailed, and postscriptfile is where you
want the printable label put if you don't want it sent to lpr.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Re: regenerating an amanda report

[Joshua Baker-LePain]

On Wed, 15 Aug 2001 at 3:51pm, Joshua Baker-LePain wrote

Yeah, I did write that on Aug 15.  And I *didn't* send it out again...

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Re: regenerating an amanda report

[Gene Heskett]

Gene Heskett sends Greetings to Joshua Baker-LePain;

 JB> On Wed, 15 Aug 2001 at 3:51pm, Joshua Baker-LePain wrote

 JB> Yeah, I did write that on Aug 15.  And I *didn't* send it out
 JB> again...

Yeah, I have a regular rash of old messages this morning.  ???

Cheers, Gene
-- 
  Gene Heskett, CET, UHK   |Amiga A2k Zeus040, 70MB ram, 31 gigs
   | Linux @ 500mhz, 320MB ram, 50 gigs
 email gene underscore heskett at iolinc dot net
#Amiga based X10 home automation program EZHome, see at:#
   
This messages reply content, but not any previously quoted material,
is © 2001 by Gene Heskett, all rights reserved.
-- 

Re: regenerating an amanda report

[Gene Heskett]

On Wednesday 15 August 2001 03:51 pm, Joshua Baker-LePain wrote:
>On Wed, 15 Aug 2001 at 1:37pm, David Carter wrote
^

Does anyone know whats going on here?  I've about 110 of these old 
messages apparently resent over the weekend.

[...]

Cheers, Gene

Total tape usage in Amanda report

[Olivier Nicole]

Hello,

Is there a way to have the total tape usage in Amanda report?

It happens that sometime Amanda runs out of tape after 50 GB (which is
normal for a 50GB SLR100 tape) but sometime only after 8GB which
clearly means there is a problem. But Amanda reports do not show any
total and I have to compute it by hand to see when there is a problem
and when there is not.

Best regards,

Olivier

removing Warning Message from Amanda Report..

[Denise Ives]

Amanda is running fine. I am running fulldumps to tape on weekends and
letting amanda have incrementals dump to holding disk during the
off-days. (since I am limited to the amount of tapes i can use)

I have just been asked to remove these Tape Error message from the
daily Amanda Reports:


i.e.
"*** THE DUMPS DID NOT FINISH PROPERLY"
"*** A TAPE ERROR OCCURRED" {no tape online].



Does anyone know how I can make this happen?
Can it happen?

Thank you.





To: [EMAIL PROTECTED]
Subject: daily AMANDA MAIL REPORT FOR November 14, 2000

*** THE DUMPS DID NOT FINISH PROPERLY!

*** A TAPE ERROR OCCURRED: [no tape online].
*** PERFORMED ALL DUMPS TO HOLDING DISK.

THESE DUMPS WERE TO DISK.  Flush them onto a new tape.
Tonight's dumps should go onto 1 tape: a new tape.


STATISTICS:
  Total   Full  Daily
      
Dump Time (hrs:min)0:02   0:00   0:00   (0:02 start)
Output Size (meg)1241.80.0 1241.8
Original Size (meg)  1241.80.0 1241.8
Avg Compressed Size (%) -- -- -- 
Tape Used (%)   3.50.03.5   (level:#disks ...)
Filesystems Dumped9  0  9   (1:9)
Avg Dump Rate (k/s)  1881.4--  1881.4
Avg Tp Write Rate (k/s) -- -- -- 







-- 
Denise E. Ives  [EMAIL PROTECTED]
Systems Engineer734.822.2037

Multilingual Internet Domain Name Registrations - http://www.walid.com

Re: Total tape usage in Amanda report

[Michael Loftis]

Uhm...Yes it does...

Just after the STATISTICS section you should have (by default):

USAGE BY TAPE:
 LabelTime  Size  %Nb
 CDO801   2:18 34005742k   99.4   546
 CDO798   1:33 27109731k   79.217


That'll list the total it got onto the tape.

--On March 24, 2006 10:03:45 AM +0700 Olivier Nicole <[EMAIL PROTECTED]> 
wrote:



Hello,

Is there a way to have the total tape usage in Amanda report?

It happens that sometime Amanda runs out of tape after 50 GB (which is
normal for a 50GB SLR100 tape) but sometime only after 8GB which
clearly means there is a problem. But Amanda reports do not show any
total and I have to compute it by hand to see when there is a problem
and when there is not.

Best regards,

Olivier





--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: Total tape usage in Amanda report

[Olivier Nicole]

> Uhm...Yes it does...
> Just after the STATISTICS section you should have (by default):

My mistake, it sure is there, but I never noticed it :(

Thank you,

Olivier

Re: Total tape usage in Amanda report

[Michael Loftis]

--On March 24, 2006 10:35:38 AM +0700 Olivier Nicole <[EMAIL PROTECTED]> 
wrote:



Uhm...Yes it does...
Just after the STATISTICS section you should have (by default):


My mistake, it sure is there, but I never noticed it :(


NP...note that those numbers are just the amount of successfully taped 
DLEs, so, they can be a little misleading if say they say something like 
33GB (of a 40GB tape) if the next DLE it wanted to put on the tape was say 
8GB.




Thank you,

Olivier





--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: Total tape usage in Amanda report

[Paul Bijnens]

On 2006-03-24 05:01, Michael Loftis wrote:



--On March 24, 2006 10:35:38 AM +0700 Olivier Nicole <[EMAIL PROTECTED]> 
wrote:



Uhm...Yes it does...
Just after the STATISTICS section you should have (by default):


My mistake, it sure is there, but I never noticed it :(


NP...note that those numbers are just the amount of successfully taped 
DLEs, so, they can be a little misleading if say they say something like 
33GB (of a 40GB tape) if the next DLE it wanted to put on the tape was 
say 8GB.


In the NOTES section you find the value where Amanda bumped into EOT:


USAGE BY TAPE:
  Label Time  Size  %Nb
  DAILY49   1:55  2648712k   68.935

NOTES:
  taper: tape DAILY49 kb 3944576 fm 36 writing file: No space left on 
device

  driver: going into degraded mode because of tape error.


This is a 4 Gbyte DDS2 tape, and amanda bumped into EOT near the
expected value, 3944576 kb (while writing file 36).
The successful backups take 2648723 kb.
(And yes, the failed backup was 1.5 Gbyte, too large for that gap.)


--
Paul Bijnens, xplanation Technology ServicesTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***

Re: Total tape usage in Amanda report

[Olivier Nicole]

> In the NOTES section you find the value where Amanda bumped into EOT:

Now I have problem with this:

STATISTICS:
Output Size (meg)7728.0 7492.9  235.1

Is correct, I can check that there is about 8GB written on that tape.


NOTES:
  taper: tape CSIM-set-3-00 kb 1775424 fm 11 writing file: short write

But I cannot see what this 1775424 KB means, it is by no way related
to the 7728 MB above.

Olivier

Re: Total tape usage in Amanda report

[Paul Bijnens]

On 2006-03-24 09:00, Olivier Nicole wrote:

In the NOTES section you find the value where Amanda bumped into EOT:


Now I have problem with this:

STATISTICS:
Output Size (meg)7728.0 7492.9  235.1


This is not about the tape, but the amount that was dumped.




Is correct, I can check that there is about 8GB written on that tape.


(How did you check that? )

First is the dumping, then the taping.

In the simple case, the two amounts should be the same.
But it can be different:

- with "autoflush true" and some dumps in the holdingdisk from
  the previous day, the taped amount will be greater.

- running into EOT or getting a write error on tape (what is the
  difference :-) ) will result in a smaller amount.

Amanda reports 2 values for each tape:
In the statistics section the amount of "useful" images on the tape.
And in the notes section, the amount written when amanda stopped writing
to tape, and the error condition at that point (or "OK" if no error).




NOTES:
  taper: tape CSIM-set-3-00 kb 1775424 fm 11 writing file: short write

But I cannot see what this 1775424 KB means, it is by no way related
to the 7728 MB above.


When posting your complete STATISTICS + NOTES section, I could verify
your conclusions...


Here is a complete section:

==start==
STATISTICS:
  Total   Full  Incr.
      
Estimate Time (hrs:min)0:06
Run Time (hrs:min) 3:17
Dump Time (hrs:min)0:49   0:21   0:28
Output Size (meg)4360.9 2065.4 2295.6
Original Size (meg)  5950.2 2629.5 3320.8
Avg Compressed Size (%)73.3   78.5   69.1   (level:#disks ...)
Filesystems Dumped   36  9 27   (1:21 2:5 5:1)
Avg Dump Rate (k/s)  1522.5 1706.4 1387.9

Tape Time (hrs:min)1:55   0:13   1:41
Tape Size (meg)  2586.6  291.0 2295.6
Tape Used (%)  68.97.8   61.1   (level:#disks ...)
Filesystems Taped35  8 27   (1:21 2:5 5:1)
Avg Tp Write Rate (k/s)   385.4  379.2  386.2

USAGE BY TAPE:
  Label Time  Size  %Nb
  DAILY49   1:55  2648712k   68.935


NOTES:
  taper: tape DAILY49 kb 3944576 fm 36 writing file: No space left on 
device

  driver: going into degraded mode because of tape error.
==end==

There was 4360.9 MB dumped (36 filesystems)
But there was only 2586.6 MB taped (35 filesystems),
and one filesystem is left in the holdingdisk.

And actually the next day, we got this report:

==start==
STATISTICS:
  Total   Full  Incr.
      
Estimate Time (hrs:min)0:06
Run Time (hrs:min) 2:49
Dump Time (hrs:min)0:44   0:16   0:28
Output Size (meg)3746.0 1384.3 2361.7
Original Size (meg)  5516.9 2381.7 3135.3
Avg Compressed Size (%)67.9   58.1   75.3   (level:#disks ...)
Filesystems Dumped   36  6 30   (1:21 2:8 5:1)
Avg Dump Rate (k/s)  1444.2 1453.3 1438.9

Tape Time (hrs:min)2:49   1:08   1:41
Tape Size (meg)  3848.3 1561.3 2287.1
Tape Used (%) 102.4   41.5   60.9   (level:#disks ...)
Filesystems Taped25  3 22   (1:17 2:4 5:1)
Avg Tp Write Rate (k/s)   389.5  392.1  387.7

USAGE BY TAPE:
  Label Time  Size  %Nb
  DAILY50   2:49  3940694k  102.425


NOTES:
  taper: tape DAILY50 kb 3945024 fm 26 writing file: No space left on 
device

  driver: going into degraded mode because of tape error.
==end==

Now only 3746.0 MB was dumped (36 filesystems), but we taped 3848.3 MB.
Amanda put the holdingdiskfile of the previous day on this tape, and
then tries fit as much as possible from today too: apparently 24
images from today.  Today there were 12 images left in the holdingdisk.
(but their total size is smaller than the single one yesterday.)
Because the average amount to backup is usually around 3500 MByte,
I expect that tomorrow even more data will fit on tape, maybe even
more than 36 images (while there are only 36 DLE's in that config).


--
Paul Bijnens, xplanation Technology ServicesTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...

Re: removing Warning Message from Amanda Report..

[John R. Jackson]

>I have just been asked to remove these Tape Error message from the
>daily Amanda Reports:
>...
>"*** THE DUMPS DID NOT FINISH PROPERLY"
>"*** A TAPE ERROR OCCURRED" {no tape online].
>
>Does anyone know how I can make this happen?
>Can it happen?

That's going to be a project.  Even if you could just get rid of the
messages, which is not going to be easy (I took a quick look at the
code -- they come from pretty deep inside things), I'm not sure other
parts of Amanda (e.g. amreport) aren't going to catch on to the fact
that nothing made it to tape and start whining.

If the goal is to just get rid of this one error indication, I'd probably
do something equally evil and run the E-mail through a filter (e.g. via
procmail), search very, very carefully for this exact error situation
and then clean it up (Perl is your friend :-).

>Denise E. Ives

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Re: removing Warning Message from Amanda Report..

[David Lloyd]

Ummm, what happens when you get a REAL error?

DL

Re: removing Warning Message from Amanda Report..

[John R. Jackson]

>Ummm, what happens when you get a REAL error?

Considering the limited number of tapes, I don't think getting errors
is an acceptable option for Denise :-).  And it certainly wasn't yet
another thing I wanted to bug her about :-).

It is, however, another reason this would be a tough project to
do correctly.  If it was limited to the case of "no tape online", it
might be doable, and that would fit OK with the folks that run this way
(holding disk only for some portion of the dumpcycle).  But you're right
that it's just one more reason it would have to be done very carefully
so real errors didn't get lost.

>DL

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Re: removing Warning Message from Amanda Report..

[Johannes Niess]

Denise Ives <[EMAIL PROTECTED]> writes:

> Amanda is running fine. I am running fulldumps to tape on weekends and
> letting amanda have incrementals dump to holding disk during the
> off-days. (since I am limited to the amount of tapes i can use)
> 
> I have just been asked to remove these Tape Error message from the
> daily Amanda Reports:
> 
> 
> i.e.
> "*** THE DUMPS DID NOT FINISH PROPERLY"
> "*** A TAPE ERROR OCCURRED" {no tape online].
> 
> 
> 
> Does anyone know how I can make this happen?
> Can it happen?

Denise,

A clean solution is not possible at the moment. This would require
setting /dev/null as the tape device in amanda.conf and convincing the
programmers to add an optional parameter for the tape device to the
amflush command.

Until this is done, I'd experiment with two versions of amanda.conf:
One with the real tape device and one with /dev/null. Cron can do that
for you. AFAIK the required version of Amanda is 2.4.2.

Johannes Niess

Re: removing Warning Message from Amanda Report..

[John R. Jackson]

>... This would require
>setting /dev/null as the tape device in amanda.conf ...

No, no, no.  At 2.4.2 Amanda treats tapedev set to /dev/null as a
special case and **throws away** all the dump images (this is meant
for debugging).

If you want to set tapedev to something to cause Amanda to not use a
tape, set it to /dev/no-such-device (or anything else that is certain
to not exist).

>Johannes Niess

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

y didn't amanda report this as an error?

[Deb Baddorf]

From a client  machine,  the admin sent me this:

Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on signal 11 
(core dumped)

The above message shows gzip crashed on daesrv last night.  It crashed
because there is a hardware problem on that machine, but since it was
probably part of an amanda backup that did not work as expected, I wanted
to be sure amanda had reported something about it to you.   -client admin
Amanda herself had reported a strange error in her mail report:

daesrv.fna /usr lev 0 STRANGE
.
| DUMP: 33.76% done, finished in 1:20
? sendbackup: index tee cannot write [Broken pipe]
| DUMP: Broken pipe
| DUMP: The ENTIRE dump is aborted.
? index returned 1
??error [/sbin/dump returned 3, compress got signal 11]? dumper: strange 
[missing size line from sendbackup]
? dumper: strange [missing end line from sendbackup]
\

But it appears that she went ahead and stored the partial data on tape
anyway,   and considered this a good level 0 backup.   (admin config due
shows the next level 0 is 7 days away)
daesrv.fnal.gov /usr 0 0 3605024 -- 47:40 1260.7 12:35 4773.9

Why doesn't amanda recognize this as a failure?
Am I missing something that I should have noticed?
Or am I reading it wrong (the fact that "due" implies a level 0 was done)?
Deb Baddorf
---
Deb Baddorf [EMAIL PROTECTED]  840-2289
"Nobody told me that living happily ever after would be such hard work ..."
S. White<

Re: y didn't amanda report this as an error?

[Jon LaBadie]

On Wed, Sep 24, 2003 at 01:54:49PM -0500, Deb Baddorf wrote:
> From a client  machine,  the admin sent me this:
> 
> Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on signal 11 
> (core dumped)
> 
> The above message shows gzip crashed on daesrv last night.  It crashed
> because there is a hardware problem on that machine, but since it was
> probably part of an amanda backup that did not work as expected, I wanted
> to be sure amanda had reported something about it to you.   -client admin
> 
> Amanda herself had reported a strange error in her mail report:
> 
> daesrv.fna /usr lev 0 STRANGE
> .
> | DUMP: 33.76% done, finished in 1:20
> ? sendbackup: index tee cannot write [Broken pipe]

Note the problem was in making the index, not the backup.

> | DUMP: Broken pipe
> | DUMP: The ENTIRE dump is aborted.
> ? index returned 1
> ??error [/sbin/dump returned 3, compress got signal 11]? dumper: strange 
> [missing size line from sendbackup]
> ? dumper: strange [missing end line from sendbackup]
> \
> 
> 
> But it appears that she went ahead and stored the partial data on tape
> anyway,   and considered this a good level 0 backup.   (admin config due
> shows the next level 0 is 7 days away)
> 
> daesrv.fnal.gov /usr 0 0 3605024 -- 47:40 1260.7 12:35 4773.9
> 
> Why doesn't amanda recognize this as a failure?
> Am I missing something that I should have noticed?
> Or am I reading it wrong (the fact that "due" implies a level 0 was done)?

Did your report show it was "taped".  If so I suspect the backup is ok,
but using amrecover with the index will be suspect/problematical.

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: y didn't amanda report this as an error?

[Deb Baddorf]

At 03:36 PM 9/24/2003 -0400, Jon LaBadie wrote:
On Wed, Sep 24, 2003 at 01:54:49PM -0500, Deb Baddorf wrote:
> From a client  machine,  the admin sent me this:
>
> Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on 
signal 11
> (core dumped)
>
> The above message shows gzip crashed on daesrv last night.  It crashed
> because there is a hardware problem on that machine, but since it was
> probably part of an amanda backup that did not work as expected, I wanted
> to be sure amanda had reported something about it to you.   -client admin
>
> Amanda herself had reported a strange error in her mail report:
>
> daesrv.fna /usr lev 0 STRANGE
> .
> | DUMP: 33.76% done, finished in 1:20
> ? sendbackup: index tee cannot write [Broken pipe]

Note the problem was in making the index, not the backup.
Wel  but the client was doing it's own compressing.   So when the
gzipper failed,  the whole backup failed.   At only 33% finished.
I just did a test amrestore  (true,  amrecover wouldn't touch it).
Got about 1/3 the amount of data that ought to be on that disk.
So I think it really did fail,   but registered it as a successful level 0
backup.  :-(

> | DUMP: Broken pipe
> | DUMP: The ENTIRE dump is aborted.
> ? index returned 1
> ??error [/sbin/dump returned 3, compress got signal 11]? dumper: strange
> [missing size line from sendbackup]
> ? dumper: strange [missing end line from sendbackup]
> \
>
>
> But it appears that she went ahead and stored the partial data on tape
> anyway,   and considered this a good level 0 backup.   (admin config due
> shows the next level 0 is 7 days away)
>
> daesrv.fnal.gov /usr 0 0 3605024 -- 47:40 1260.7 12:35 4773.9
>
> Why doesn't amanda recognize this as a failure?
> Am I missing something that I should have noticed?
> Or am I reading it wrong (the fact that "due" implies a level 0 was done)?
Did your report show it was "taped".  If so I suspect the backup is ok,
but using amrecover with the index will be suspect/problematical.
--
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: y didn't amanda report this as an error?

[Jon LaBadie]

On Wed, Sep 24, 2003 at 05:30:59PM -0500, Deb Baddorf wrote:
> At 03:36 PM 9/24/2003 -0400, Jon LaBadie wrote:
> >On Wed, Sep 24, 2003 at 01:54:49PM -0500, Deb Baddorf wrote:
> >> From a client  machine,  the admin sent me this:
> >>
> >> Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on 
> >signal 11
> >> (core dumped)
> >>
> >> The above message shows gzip crashed on daesrv last night.  It crashed
> >> because there is a hardware problem on that machine, but since it was
> >> probably part of an amanda backup that did not work as expected, I wanted
> >> to be sure amanda had reported something about it to you.   -client admin
> >>
> >> Amanda herself had reported a strange error in her mail report:
> >>
> >> daesrv.fna /usr lev 0 STRANGE
> >> .
> >> | DUMP: 33.76% done, finished in 1:20
> >> ? sendbackup: index tee cannot write [Broken pipe]
> >
> >Note the problem was in making the index, not the backup.
> 
> Wel  but the client was doing it's own compressing.   So when the
> gzipper failed,  the whole backup failed.   At only 33% finished.
> I just did a test amrestore  (true,  amrecover wouldn't touch it).
> Got about 1/3 the amount of data that ought to be on that disk.
> So I think it really did fail,   but registered it as a successful level 0
> backup.  :-(

Certainly sounds like a situation that amanda should not have
recorded as a valid level 0.  Has anyone else noted this?
There have been several reports showing failed pipes in
the index stream for various reasons.  I wonder if those also
were reported as valid dumps.

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: y didn't amanda report this as an error?

[Phil Homewood]

Jon LaBadie wrote:
> There have been several reports showing failed pipes in
> the index stream for various reasons.  I wonder if those also
> were reported as valid dumps.

Now that you mention it, I have had this, a couple of times in the
last week. Am still trying to debug it, but:

sendbackup: start [hammer:/home level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? sendbackup: index tee cannot write [Broken pipe]  
? index returned 1
??error [/bin/tar got signal 13, compress got signal 11]? dumper: strange [missing 
size line from sendbackup]
? dumper: strange [missing end line from sendbackup] 

[...]

hammer   /home   0   0   1568   --0:08 184.4   0:04 442.5

The "listed incremental dir" shows:

-rw---1 backup   backup  0 Sep 23 23:20 hammer_home_0.new

The filesystem in question is some 13Gb. Apparently the compress
process is SEGVing, but I'm not seeing a core anywhere. Amanda
version is 2.4.4-2 (Debian package), server and client are the
same machine. Not seeing this on any other boxes, and I have
another Debian box with a very similar configuration working
fine.
-- 
Phil Homewood, Systems Janitor, http://www.SnapGear.com
[EMAIL PROTECTED] Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

Re: y didn't amanda report this as an error?

[Jean-Louis Martineau]

Hi Deb,

Which release of amanda are you using?

amanda-2.4.4p1 will report a failed dump for this kind error and
reschedule a level 0 for the next day.

That was fixed on 2003-04-26.

Jean-Louis

On Wed, Sep 24, 2003 at 01:54:49PM -0500, Deb Baddorf wrote:
> From a client  machine,  the admin sent me this:
> 
> Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on signal 11 
> (core dumped)
> 
> The above message shows gzip crashed on daesrv last night.  It crashed
> because there is a hardware problem on that machine, but since it was
> probably part of an amanda backup that did not work as expected, I wanted
> to be sure amanda had reported something about it to you.   -client admin
> 
> Amanda herself had reported a strange error in her mail report:
> 
> daesrv.fna /usr lev 0 STRANGE
> .
> | DUMP: 33.76% done, finished in 1:20
> ? sendbackup: index tee cannot write [Broken pipe]
> | DUMP: Broken pipe
> | DUMP: The ENTIRE dump is aborted.
> ? index returned 1
> ??error [/sbin/dump returned 3, compress got signal 11]? dumper: strange 
> [missing size line from sendbackup]
> ? dumper: strange [missing end line from sendbackup]
> \
> 
> 
> But it appears that she went ahead and stored the partial data on tape
> anyway,   and considered this a good level 0 backup.   (admin config due
> shows the next level 0 is 7 days away)
> 
> daesrv.fnal.gov /usr 0 0 3605024 -- 47:40 1260.7 12:35 4773.9
> 
> 
> Why doesn't amanda recognize this as a failure?
> Am I missing something that I should have noticed?
> Or am I reading it wrong (the fact that "due" implies a level 0 was done)?
> Deb Baddorf
> ---
> Deb Baddorf [EMAIL PROTECTED]  840-2289
> "Nobody told me that living happily ever after would be such hard work ..."
> S. White<
> 
> 

-- 
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: y didn't amanda report this as an error?

[Deb Baddorf]

At 09:39 AM 9/25/2003 -0400, Jean-Louis Martineau wrote:
Hi Deb,

Which release of amanda are you using?
server is running Amanda-2.4.3  on FreeBSD 4.7-RELEASE-p3
client is running Amanda-2.4.3b4 on FreeBSD 4.8-RELEASE i386
amanda-2.4.4p1 will report a failed dump for this kind error and
reschedule a level 0 for the next day.
amadmin CONFIG due NODE DISK
indicated the next level 0 wasn't scheduled for 7 days yet
(I forced one)

That was fixed on 2003-04-26.

Jean-Louis

On Wed, Sep 24, 2003 at 01:54:49PM -0500, Deb Baddorf wrote:
> From a client  machine,  the admin sent me this:
>
> Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on 
signal 11
> (core dumped)
>
> The above message shows gzip crashed on daesrv last night.  It crashed
> because there is a hardware problem on that machine, but since it was
> probably part of an amanda backup that did not work as expected, I wanted
> to be sure amanda had reported something about it to you.   -client admin
>
> Amanda herself had reported a strange error in her mail report:
>
> daesrv.fna /usr lev 0 STRANGE
> .
> | DUMP: 33.76% done, finished in 1:20
> ? sendbackup: index tee cannot write [Broken pipe]
> | DUMP: Broken pipe
> | DUMP: The ENTIRE dump is aborted.
> ? index returned 1
> ??error [/sbin/dump returned 3, compress got signal 11]? dumper: strange
> [missing size line from sendbackup]
> ? dumper: strange [missing end line from sendbackup]
> \
>
>
> But it appears that she went ahead and stored the partial data on tape
> anyway,   and considered this a good level 0 backup.   (admin config due
> shows the next level 0 is 7 days away)
>
> daesrv.fnal.gov /usr 0 0 3605024 -- 47:40 1260.7 12:35 4773.9
>
>
> Why doesn't amanda recognize this as a failure?
> Am I missing something that I should have noticed?
> Or am I reading it wrong (the fact that "due" implies a level 0 was done)?
> Deb Baddorf
> ---
> Deb Baddorf [EMAIL PROTECTED]  840-2289
> "Nobody told me that living happily ever after would be such hard work ..."
> S. White<
>
>

--
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
---
Deb Baddorf [EMAIL PROTECTED]  840-2289
"Nobody told me that living happily ever after would be such hard work ..."
S. White<

Re: y didn't amanda report this as an error?

[Phil Homewood]

Phil Homewood wrote:
> Now that you mention it, I have had this, a couple of times in the
> last week. Am still trying to debug it, but:
> 
> ??error [/bin/tar got signal 13, compress got signal 11]? dumper: strange [missing 
> size line from sendbackup]

Turns out this also appears to be bad hardware, in case anyone's
collecting responses.

> hammer   /home   0   0   1568   --0:08 184.4   0:04 442.5

[left in to show that amanda still considers this a successful dump]
-- 
Phil Homewood, Systems Janitor, http://www.SnapGear.com
[EMAIL PROTECTED] Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

Re: y didn't amanda report this as an error?

[Sven Rudolph]

Jon LaBadie <[EMAIL PROTECTED]> writes:

> On Wed, Sep 24, 2003 at 01:54:49PM -0500, Deb Baddorf wrote:
> > From a client  machine,  the admin sent me this:
> > 
> > Sep 24 02:45:32 daesrv /kernel: pid 7638 (gzip), uid 2: exited on signal 11 
> > (core dumped)
> > 
> > The above message shows gzip crashed on daesrv last night.  It crashed
> > because there is a hardware problem on that machine, but since it was
> > probably part of an amanda backup that did not work as expected, I wanted
> > to be sure amanda had reported something about it to you.   -client admin
> > 
> > Amanda herself had reported a strange error in her mail report:
> > 
> > daesrv.fna /usr lev 0 STRANGE
> > .
> > | DUMP: 33.76% done, finished in 1:20
> > ? sendbackup: index tee cannot write [Broken pipe]
> 
> Note the problem was in making the index, not the backup.

But this is not relazed to a gzip. The gzip for the index always runs
on the server.

Instead this sound like /tmp full, probably on the client.

> > | DUMP: Broken pipe
> > | DUMP: The ENTIRE dump is aborted.
> > ? index returned 1
> > ??error [/sbin/dump returned 3, compress got signal 11]? dumper: strange 
> > [missing size line from sendbackup]
> > ? dumper: strange [missing end line from sendbackup]
> > \

And this is a result of the failed gzip; as already mentioned.

Sven

Tape usage in the amanda report(only 50% used)

[Huiqun]

Hi all:

Recently I setup amanda 2.4.p2 on our Solaris system, it seems working fine.
I'm using a HP DDS2 tape which has a 4GB capacity, I got the following
tapetype value from this mailing list:

define tapetype HP-DDS2 {
comment "HP DDS2"
# data got from amanda email archive
length 3780 mbytes
filemark 3 kbytes
speed 380 kbytes
}

Following is part of my Amanda report:
STATISTICS:
  TotalFullDaily
   
Estimate Time (hrs:min)   0:01
Run Time (hrs:min)1:18
Dump Time (hrs:min)   0:44 0:42 0:02
Output Size (meg) 1906.7   1832.6   74.1
Original Size (meg)   6904.9   6761.3   143.6
Avg Compressed Size (%)   27.6 27.1 51.6 (level:#disks ...)
Filesystems Dumped963 (1:3)
Avg Dump Rate (k/s)   745.2746.1723.6
Tape Time (hrs:min)   1:18 1:15 0:03
Tape Size (meg)   1907.0   1832.8   74.2
Tape Used (%) 50.5 48.5 2.0 (level:#disks ...)
Filesystems Taped  96   3 (1:3)
Avg Tp Write Rate (k/s)   419.5 419.8   411.8

The report says my Tape Size is only 2GB, and the Output Size is  2GB also.
Thus some of my file system failed dumping to the tape because the dump is
too big(it's not correct, that file system is only 900MB).
I also noticed the Tape Used value is only 50%.

Is my Tapetype setting correct?

Thanks

Huiqun Liu
System Administrator

Re: Tape usage in the amanda report(only 50% used)

[Gene Heskett]

On Friday 18 October 2002 00:06, Huiqun wrote:
>Hi all:
>
>Recently I setup amanda 2.4.p2 on our Solaris system, it seems
> working fine. I'm using a HP DDS2 tape which has a 4GB capacity,
> I got the following tapetype value from this mailing list:
>
>define tapetype HP-DDS2 {
>comment "HP DDS2"
># data got from amanda email archive
>length 3780 mbytes
>filemark 3 kbytes
>speed 380 kbytes
>}
>
>Following is part of my Amanda report:
>STATISTICS:
>  TotalFullDaily
>   
>Estimate Time (hrs:min)   0:01
>Run Time (hrs:min)1:18
>Dump Time (hrs:min)   0:44 0:42 0:02
>Output Size (meg) 1906.7   1832.6   74.1
>Original Size (meg)   6904.9   6761.3   143.6
>Avg Compressed Size (%)   27.6 27.1 51.6 (level:#disks
> ...) Filesystems Dumped963 (1:3)
>Avg Dump Rate (k/s)   745.2746.1723.6
>Tape Time (hrs:min)   1:18 1:15 0:03
>Tape Size (meg)   1907.0   1832.8   74.2
>Tape Used (%) 50.5 48.5 2.0 (level:#disks ...)
>Filesystems Taped  96   3 (1:3)
>Avg Tp Write Rate (k/s)   419.5 419.8   411.8
>
>The report says my Tape Size is only 2GB, and the Output Size is 
> 2GB also. Thus some of my file system failed dumping to the tape
> because the dump is too big(it's not correct, that file system is
> only 900MB). I also noticed the Tape Used value is only 50%.
>
>Is my Tapetype setting correct?

It sure looks good from here, that looks pretty much like my own 
tapetype settings as I'm also using that tape.  I also see that you 
are compressing the data with an amanda choice in the dumptype.

That leaves two questions.

1. Does that version of solaris perchance have a 2 gig file size 
limit?

2. Are you also trying to use the drives builtin hardware 
compression?

If 1, then it sounds like its update solaris time.  Not much we can 
do for it from here.

If 2, then be aware that highly compressed data, when fed to the 
hardware compressor in the drive, will actually grow, and from the 
data rate reported for that drive, my guess is thats its enabled, 
otherwise most of those drives top out at about 380k/sec.

You are reporting figures in the 420k/sec range, suggesting its 
compressing a bit here and there, so it appears you aren't feeding 
it anything that it can gain much ground on.  With hardware on, and 
raw text to the drive which it can squeeze pretty good, the data 
rate should be up in the 700k/sec area.

But to be honest, I can't say as I'm aware of the data growing by 
100% under those conditions, maybe 15 to 20 percent has been most 
users experience.

Maybe Jon or Jean-louis will chime in with a better idea, but thats 
what I get for the data given.

Turning off the compression on a tape thats been written in the 
compressed mode is a bit of a trick as the tape keeps resetting the 
compression to on during the recognition phase when its inserted 
into the drive, and I've posted a procedure to do that turnoff here 
on this list enough times to bore most of the list but you should 
be able to find it in the archives.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.18% setiathome rank, not too shabby for a WV hillbilly

Re: Tape usage in the amanda report(only 50% used)

[Jon LaBadie]

On Fri, Oct 18, 2002 at 12:06:54PM +0800, Huiqun wrote:
> Hi all:
> 
> Recently I setup amanda 2.4.p2 on our Solaris system, it seems working fine.
> I'm using a HP DDS2 tape which has a 4GB capacity, I got the following
> tapetype value from this mailing list:
> 
> define tapetype HP-DDS2 {
> comment "HP DDS2"
> # data got from amanda email archive
> length 3780 mbytes
> filemark 3 kbytes
> speed 380 kbytes
> }
> 
> Following is part of my Amanda report:
> STATISTICS:
>   TotalFullDaily
>    
> Estimate Time (hrs:min)   0:01
> Run Time (hrs:min)1:18
> Dump Time (hrs:min)   0:44 0:42 0:02
> Output Size (meg) 1906.7   1832.6   74.1
> Original Size (meg)   6904.9   6761.3   143.6
> Avg Compressed Size (%)   27.6 27.1 51.6 (level:#disks ...)
> Filesystems Dumped963 (1:3)
> Avg Dump Rate (k/s)   745.2746.1723.6
> Tape Time (hrs:min)   1:18 1:15 0:03
> Tape Size (meg)   1907.0   1832.8   74.2
> Tape Used (%) 50.5 48.5 2.0 (level:#disks ...)
> Filesystems Taped  96   3 (1:3)
> Avg Tp Write Rate (k/s)   419.5 419.8   411.8
> 
> The report says my Tape Size is only 2GB, and the Output Size is  2GB also.
> Thus some of my file system failed dumping to the tape because the dump is
> too big(it's not correct, that file system is only 900MB).
> I also noticed the Tape Used value is only 50%.
> 
> Is my Tapetype setting correct?

Nothing is wrong that I see.  It is a very typical result.

Amanda does not try to fill each tape to its full capacity.

Your report says there were 9 DLEs (Disk List Entries) dumped.
Six DLEs were dumped at level 0 (full dumps) and 3 were incremental, level 1's.

Total amount of data dumped from disk was 6.9 GB (Orig Size).
Most of that (6.76 GB) came from the level 0 dumps.

Those 6.9 GB of data were very compressible (you must be using gzip) and
were shrunk to only 1.9GB (Output Size).

Of those 1.9 GB, 1.9 GB were able to be written to tape (Tape Size).

Looks pretty good to me :))

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: Tape usage in the amanda report(only 50% used)

[Gene Heskett]

On Friday 18 October 2002 00:06, Huiqun wrote:
>Hi all:
>
>Recently I setup amanda 2.4.p2 on our Solaris system, it seems
> working fine. I'm using a HP DDS2 tape which has a 4GB capacity,
> I got the following tapetype value from this mailing list:
>
>define tapetype HP-DDS2 {
>comment "HP DDS2"
># data got from amanda email archive
>length 3780 mbytes
>filemark 3 kbytes
>speed 380 kbytes
>}
>
>Following is part of my Amanda report:
>STATISTICS:
>  TotalFullDaily
>   
>Estimate Time (hrs:min)   0:01
>Run Time (hrs:min)1:18
>Dump Time (hrs:min)   0:44 0:42 0:02
>Output Size (meg) 1906.7   1832.6   74.1
>Original Size (meg)   6904.9   6761.3   143.6
>Avg Compressed Size (%)   27.6 27.1 51.6 (level:#disks
> ...) Filesystems Dumped963 (1:3)
>Avg Dump Rate (k/s)   745.2746.1723.6
>Tape Time (hrs:min)   1:18 1:15 0:03
>Tape Size (meg)   1907.0   1832.8   74.2
>Tape Used (%) 50.5 48.5 2.0 (level:#disks ...)
>Filesystems Taped  96   3 (1:3)
>Avg Tp Write Rate (k/s)   419.5 419.8   411.8
>
>The report says my Tape Size is only 2GB, and the Output Size is 
> 2GB also. Thus some of my file system failed dumping to the tape
> because the dump is too big(it's not correct, that file system is
> only 900MB). I also noticed the Tape Used value is only 50%.

Humm, I made one other assumption, and that was that either the 
holding disk area isn't in the paths of the filesystems in the 
disklist, or that it was specifically excluded.  Backing up the 
holding disk is a moving target since amanda is writing to it as 
she does the dumps.  It could get recursive and eat up a lot of 
tape. 

>Is my Tapetype setting correct?
>
>Thanks
>
>Huiqun Liu
>System Administrator

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.18% setiathome rank, not too shabby for a WV hillbilly