Re: Data Timeout

In response to my own message, I was reading around a bit more and the broken pipe could be many things but usually means that the data isn't being dumped fast enough and the server gives up on the client (in my case the same machine). So I was thinking, I am trying to backup 281GB; therefore reading the data, compressing it and then dumping it back to disk all on the same controller... maybe its just taking a long time? Here are the lines in amanda.conf that pertain to this backup, maybe this will give some clues:
define tapetype HARD-DISK {
        comment "Hard disk instead of tape"
        length 690000 mbytes #Simulates end of tape - using dump
define dumptype hard-disk-tar {
        compress client best
        index yes
        comment "Back up to hard disk instead of tape - using tar"
        program "GNUTAR"
}

On Mon, 2004-05-24 at 10:27, Kris Vassallo wrote:

Ok, so I thought this might be a RAM issue so I upgraded the RAM to 4GB, didn't help. amcheck runs fine with no errors. I don't believe that this is a network issue because this machine is really just backing itself up; backing up 1 set of disks to another set of disks.
Inside one of the sendbackup logs (2 of them per night) I am seeing this...

index tee cannot write [Broken pipe]
sendbackup: time 3232.427: pid 12265 finish time Mon May 24 06:56:05 2004
sendbackup: time 3232.427: 126: strange(?): sendbackup: index tee cannot write [Broken pipe]

Could this be causing my problems? What is this? and why are my pipes broken? I am attaching the full log below if anyone wants to see it.

sendbackup: debug 1 pid 12260 ruid 33 euid 33: start at Mon May 24 06:02:12 2004
/usr/lib/amanda/sendbackup: version 2.4.3
parsed request as: program `GNUTAR'
                     disk `/home'
                     device `/home'
                     level 1
                     since 2004:5:14:10:24:53
                     options `|;auth=bsd;compress-best;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.32851
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.32852
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.32853
sendbackup: time 0.000: waiting for connect on 32851, then 32852, then 32853
sendbackup: time 0.001: stream_accept: connection from 192.168.1.6.32854
sendbackup: time 0.001: stream_accept: connection from 192.168.1.6.32855
sendbackup: time 0.001: stream_accept: connection from 192.168.1.6.32856
sendbackup: time 0.001: got all connections
sendbackup: time 0.001: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --best
sendbackup-gnutar: time 0.003: pid 12263: /usr/bin/gzip --best
sendbackup-gnutar: time 0.586: doing level 1 dump as listed-incremental from /var/lib/amanda/gnutar-lists/venus.berkeley-da.
com_home_0 to /var/lib/amanda/gnutar-lists/venus.berkeley-da.com_home_1.new
sendbackup-gnutar: time 0.593: doing level 1 dump from date: 2004-05-14 10:24:54 GMT
sendbackup: time 0.604: spawning /usr/lib/amanda/runtar in pipeline
sendbackup: argument list: gtar --create --file - --directory /home --one-file-system --listed-incremental /var/lib/amanda/g
nutar-lists/venus.berkeley-da.com_home_1.new --sparse --ignore-failed-read --totals .
sendbackup-gnutar: time 0.620: /usr/lib/amanda/runtar: pid 12269
sendbackup: time 0.620: started index creator: "/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'"
sendbackup: time 3232.427: index tee cannot write [Broken pipe]
sendbackup: time 3232.427: pid 12265 finish time Mon May 24 06:56:05 2004
sendbackup: time 3232.427: 126: strange(?): sendbackup: index tee cannot write [Broken pipe]

On Thu, 2004-05-20 at 05:21, Gene Heskett wrote:
On Wednesday 19 May 2004 17:48, Kris Vassallo wrote:
>AMANDA is starting to drive me nucking futs.. seems as if every week
>something new breaks and I can't find the answer to why.
>Here's whats going on... AMANDA sends me an email with the following
>information:
>
>These dumps were to tape DailySet118.
>The next tape Amanda expects to use is: a new tape.
>
>FAILURE AND STRANGE DUMP SUMMARY:
>  bda2.berke //illustrator/BDA_Manual lev 1 STRANGE
>  venus.berk /home lev 1 FAILED [data timeout]
>*SNIP*
>/-- venus.berk /home lev 1 FAILED [data timeout]

Please note it says "data timeout" here.

>sendbackup: start [venus.berkeley-da.com:/home level 1]
>sendbackup: info BACKUP=/bin/tar
>sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
>sendbackup: info COMPRESS_SUFFIX=.gz
>sendbackup: info end
>
>Previously something else was broken and I set the etimeout a bit
>higher. I have now raised the etimeout to 10000 and it didn't fix
>anything. This backup was working last week and now all of a sudden
> it doesn't. It is trying to backup a 266GB file system and the disk
> that AMANDA is dumping to has 420GB available.  Any idea on what
> would be causing this?

You need to raise dtimeout in this case.  However, I'd investigate to 
see if a reason for the slowness of this client can be found.  My one 
client usually beats the server in the amount of time it takes. 

A bad NIC, hub/switch or cable maybe?  Something else hogging the 
bandwidth at that time of the night?