On Wednesday 28 August 2002 10:49, Amy Tanner wrote:
>I'm getting data timeout errors on filesystems of just 2 of the
> machines our amanda server backs up.  The
> /tmp/amanda/sendbackup*debug file does not report errors but also
> does not list a finish time.  For example:
>
>sendbackup: debug 1 pid 27285 ruid 95 euid 95 start time Wed Aug
> 28 02:29:21 2002
>/usr/local/libexec/sendbackup: got input request: DUMP /u02 0
> 1970:1:1:0:0:0 OPTIONS |;bsd-auth; parsed request as: program
> `DUMP' disk `/u02' lev 0 since 1970:1:1:0:0:0 opt `|;bsd-auth;'
> waiting for connect on 2718, then 2719
>  got all connections
>sendbackup: spawning "/sbin/dump" in pipeline
>sendbackup: argument list: "dump" "0usf" "1048576" "-"
> "/dev/ida/c0d3p1"
>
>There are several dump and sendbackup processes still running. 
> I've tried killing all the dump & sendbackup processes, and
> waiting for the nightly dump, but the next day I still see
> failures on one ore more filesystems on the same 2 machines.  
> But it's not always the same filesystems where it fails.

It rather sounds like you need to allow more time for the process to 
run.  Thats configurable with a couple of variables in your 
amanda.conf file, along with some explanatory test describing them.

>I'm using dump with hardware compression (no software compression)
> on all machines & file systems.

The use of hardware compression as opposed to software compression 
can also be a course of 'gotchas'.  When hardware compression is 
used, amanda doesn't have a very good idea how much data a tape can 
hold, so you have to set the tape capacities conservatively, which 
on big tapes can result in gigabytes of under utilization.

With the hardware compression turned off, a run of the tapetype 
program can determine the tapes capacity very accurately.  Amanda 
then counts the bytes *after* the software compressors have had 
their way with the data.  We highly recommend turning off the 
hardware, and then running the compressor on whichever machine has 
the horsepower to do it best, server or client.  Obviously when 
doing a large network, even a fast server will need to offload that 
duty to the clients as much as possible even if they are slower 
because 20 clients all doing their thing simultainiously are still 
going to finish faster than one server trying to do 20 clients 
worth of compression serially.

I use tar, and have 37 entries in my disklist.  7 of those entries 
regularly compress to less than 20% of their source size.  I run 
compression for about half as I've turned it off for those 
partitions containing already compressed stuff, which will expand 
when attempting to re-compress.  This effect is also true of the 
hardware compressors.  The emails you get from amanda will tell you 
by the compression ratios is shows, those that need to be run raw.

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