On Fri, Dec 27, 2002 at 11:33:09PM -0500, rgrant AT blpltd DOT com wrote:
> Hi,
> I have been running amanda for the past 3 weeks and it has been
> working very well. I usually insert a new tape every day, but
> yesterday I did not change the tape, today I did an "amflush" to
> write the holding disk content to tape and I noticed that amflush
> never finishes. If I list the processes I see amflush taking 98% cpu
> usage, and there is no disk activity, this went on for 4 hours, the
> amflush log follows:
>
[ snip ]
>
> The only way to stop this is to kill the process and run amcleanup
> which returns this e-mail:
>
>
> *** THE DUMPS DID NOT FINISH PROPERLY!
>
> The dumps were flushed to tape tape-11.
> The next tape Amanda expects to use is: tape-12.
>
>
> STATISTICS:
> Total Full Daily
> -------- -------- --------
> Estimate Time (hrs:min) 0:00
> Run Time (hrs:min) 0:00
> Dump Time (hrs:min) 0:00 0:00 0:00
> Output Size (meg) 0.0 0.0 0.0
> Original Size (meg) 0.0 0.0 0.0
> Avg Compressed Size (%) -- -- --
> Filesystems Dumped 0 0 0
> Avg Dump Rate (k/s) -- -- --
>
> Tape Time (hrs:min) 0:00 0:00 0:00
> Tape Size (meg) 0.0 0.0 0.0
> Tape Used (%) 0.0 0.0 0.0
> Filesystems Taped 0 0 0
> Avg Tp Write Rate (k/s) -- -- --
>
>
> DUMP SUMMARY:
> DUMPER STATS TAPER
> STATS
> HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
> KB/s
> -------------------------- --------------------------------- ---------
> ---
> blp / NO FILE TO FLUSH --------------------------
> ---
> blp /home NO FILE TO FLUSH --------------------------
> ---
[ snip ]
> mail /home NO FILE TO FLUSH --------------------------
> ---
>
> (brought to you by Amanda version 2.4.3)
>
>
> I use amanda 2.4.3 on Redhat 8.0 (kernel 2.4.18-14) with a Onstream
> 50 Gig tape.
Others may have specific recommendations based on their experience.
I can only offer comments that may (or may not) affect future runs.
When I see results like these I consider the possibility of unusual
conditions, perhaps beyond what the amanda developers foresaw or
could account for.
Some things to consider.
Is there any data in the holding disk dump directories. Do you know
if there was any data there before running amflush. I mean other than
empty directories, actual data files. The "NO FILE TO FLUSH" messages
suggest this was not the case. Perhaps the problems began during the
dump, before the flush.
Is there sufficient space on the holding disk? More importantly, was
there space available during the dump? I see you backup to a large
tape, I'm guessing your data is similarly large.
What is the setting of your "reserve" parameter? By default it is 100%,
meaning reserve all of the holding disk for incrementals, leaving none
for level 0 dumps. After removing the reserved portion, is your holding
disk space still sufficiently large? Perhaps your level 0 dumps have
been going directly to tape all this time without your realizing it, thus
"no file on holding disk to flush".
Lastly (from me), what is your "chunksize" parameter set to? If your
system has the common 2GB single file size limit and amanda has tried to
create holding disk files larger than this limit, the strangest things
can happen. I am unaware of any reason to not set chunksize below 2GB
even if you have large file capability. Common values are 1 gig, 1024 meg,
2000 meg, but not 2gig or 2048meg :)
HTH (for the future).
--
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)
|
