Amanda-Users

Re: Is this OK? "Ignoring cruft file"

2002-08-15 11:58:23
Subject: Re: Is this OK? "Ignoring cruft file"
From: Gene Heskett <gene_heskett AT iolinc DOT net>
To: Frank Smith <fsmith AT hoovers DOT com>, "eahakkennes AT xic DOT nl" <eahakkennes AT xic DOT nl>, "'amanda-users AT amanda DOT org'" <amanda-users AT amanda DOT org>
Date: Thu, 15 Aug 2002 11:45:52 -0400
On Thursday 15 August 2002 11:01, Frank Smith wrote:
>--On Thursday, August 15, 2002 11:47:24 +0200 Edwin Hakkennes 
<eahakkennes AT xic DOT nl> wrote:
>> Hi all,
>>
>> I added a 'big' disk to my disklist yesterday. About 8G.
>> Flushing the files from the holding disk results in
>>
>> NOTES:
>>   amflush: beosrv-1._redhat.0.2: ignoring cruft file.
>>   amflush: beosrv-1._redhat.0.3: ignoring cruft file.
>>   taper: tape xic03 kb 13511296 fm 58 [OK]
>>
>> Should I worry about this? Did only 2G of the backup actually
>> make it to the tape?
>
>It wrote 13.5G to tape, and according to your output below, 7.6G
> of that was from your "beosrv-1 /redhat" disklist entry.  I think
> the cruft file messages are just a result of the somewhat
> asynchronous nature of amanda. The chunk files are removed after
> each set is written to tape but may not be all gone yet when
> Amanda scans for other chunk sets to flush to tape.  Anything
> that it doesn't know what to do with is reported as 'cruft',
> whether it is some odd file put in the holding disk or a chunk
> that isn't part of a complete set (the chunk files are named as
> host.filesystem.level.chunknumber).
>  'Notes' are just informative, 'strange' needs to be examined, it
> may or may not be a problem, and 'warning' you better pay
> attention to.
>
>Frank

Hummm, this brings up an interesting thought, Frank.

If amanda removed the chunk files as they were written, then how 
would amanda go about the case of hitting EOT in the middle of the 
last chunk file, finding that it has perms (via runtapes>=2 for 
instance) to use the next tape in the magazine, at which point 
amanda supposedly restarts that disklist entries dump from the top.  

If there were 4 chunk files, 3 of which had been written and deleted 
when this occured, it seems to me that amanda would find herself 
between a rock and a hard place to be able to restart that 
particular disklist entries dump.  It certainly wouldn't be very 
time efficient to redo the whole entry although that does seem to 
be the only way to recover.

So how is this scenario resolved by amanda?

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

<Prev in Thread] Current Thread [Next in Thread>