--On Tuesday, August 30, 2005 18:35:12 -0400 Jon LaBadie <jon AT jgcomp DOT 
com> wrote:

> On Tue, Aug 30, 2005 at 01:48:28PM -0700, Joe Rhett wrote:
>> > On 8/30/05, Joe Rhett <jrhett AT meer DOT net> wrote:
>> >> tracking ability, but let's use 3 tapes and write not a single byte to
>> >> them?
>> 
>> On Aug 30, 2005, at 1:18 PM, Cam wrote:
>> > What's retarded? your configuration? you really didn't give enough 
>> > information for anyone to help you.
>> 
>> We've been running in this configuration for 5+ years now.  The 
>> configuration works.
> 
> And not using samba, right Joe :))
> 
> 
>> ... .  Yes, I could supply the configuration but it 
>> really doesn't change anything.  Amanda should not use 3 tapes and 
>> write 0 bytes to them, no matter what the configuration is.
>> 
> 
> Couple of items from your original post.
> 
>> The dumps were flushed to tapes svk17, svk18, svk19.
>> The next 7 tapes Amanda expects to used are: svk20, svk21, svk01,
>> svk02, svk03, svk04, svk05.
> 
> Looks like runtapes is 7.
> 
>> Output Size (meg)           0.0        0.0        0.0
> 
> Nothing made it to any holding disk.
> 
>>  taper: tape svk17 kb 34286880 fm 1 writing file: short write
>>  taper: retrying customer-plat1:/.1 on new tape: [writing file: short
>> write]
>>  taper: tape svk18 kb 34227328 fm 1 writing file: short write
>>  taper: retrying customer-plat1:/.1 on new tape: [writing file: short
>> write]
>>  taper: tape svk19 kb 0 fm 0 [OK]
> 
> This looks like the dump was going directly to tape and was too large to
> fit your 35GB tape.  So it was retried and of course was still too big.
> 
>>  customer- / lev 1 FAILED 20050825 [too many taper retries]
> 
> This seems to be an improvement over what I would have expected.
> I recall amanda continuing through any and all runtapes tapes.
> It would have done 7 attempts in your config.  At least now it
> stops after a couple of attempts.
> 
> As to whether amanda's behavior is reasonable, well ...
> 
> It is nearly impossible, perhaps totally impossible, to tell if the taping
> failed because of reaching the end of the tape or a tape or hardware error.
> Is having a backup important enough to continue and try again or should the
> first failure, possibly a bad/worn out tape terminate all the remaining 
> backups?

In order to tell if Amanda is deficient in some way, we need some more 
information.
According to the original post, this was an amflush run, so this DLE must be 
sitting
on a holdindisk.  Since normally Amanda refuses to backup a DLE that won't fit 
on
a tape and give a warning, I see two possibilities:
1. Your tapelength is set incorrectly in your config, so Amanda thinks a dump 
will
   fit when it won't
2. For some reason the dump ended up larger than the estimate, perhaps due to a
   changing filesystem or using both H/W compression on already compressed data.

Is your tapelength set to something less than 34.2GB?
How big is the dump in the holdingdisk (not how big the chunks are, if there are
more than one, but the total of all the chunks of that DLE)?

With that information we could find where the problem lies and maybe find a 
solution.

Frank

> 
> I don't think there is a simple answer.  What would be your recommendation?
> 
> -- 
> Jon H. LaBadie                  jon AT jgcomp DOT com
>  JG Computing
>  4455 Province Line Road        (609) 252-0159
>  Princeton, NJ  08540-4322      (609) 683-7220 (fax)



--
Frank Smith                                                fsmith AT hoovers 
DOT com
Sr. Systems Administrator                                 Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501