On three of my remote systems running Amanda 2.4.2p2 i am always getting a
"mesg read: Connection reset by peer" error back from the email report. And
the filesystems are not being backed up.
ss3.airsse /home lev 0 FAILED [mesg read: Connection reset by peer]
mc4.airsce /home lev 0 FAILED [mesg read: Connection reset by peer]
ss2.airsse /home lev 0 FAILED [mesg read: Connection reset by peer]
The three systems are only failing on the /home filesystem that is being
backed up, the other filesystems backup correctly. I believe this is due to
the size of them. I am backing up /var which works correctly which is only
about 50M, but /home is about 500M and doesn't backup.
If i run amdump by hand and then run amstatus to see the progress of the
backup, it is getting the data from /home. And it seems to get it all, and
then times out at the end.
Here's the sendbackup.debug on one of the failed systems, ss2:
-----
sendbackup: debug 1 pid 30089 ruid 11 euid 11 start time Tue Jul 17 01:51:31
2001
/usr/local/amanda/libexec/sendbackup: version 2.4.2p2
sendbackup: got input request: GNUTAR /home 0 1970:1:1:0:0:0 OPTIONS
|;bsd-auth;compress-best;index;exclude-list=exclude.gtar;
parsed request as: program `GNUTAR'
disk `/home'
lev 0
since 1970:1:1:0:0:0
opt
`|;bsd-auth;compress-best;index;exclude-list=exclude.gtar;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: stream_server: waiting for connection: 0.0.0.0.1557
sendbackup: stream_server: waiting for connection: 0.0.0.0.1558
sendbackup: stream_server: waiting for connection: 0.0.0.0.1559
waiting for connect on 1557, then 1558, then 1559
sendbackup: stream_accept: connection from 64.30.32.91.2293
sendbackup: stream_accept: connection from 64.30.32.91.2294
sendbackup: stream_accept: connection from 64.30.32.91.2295
got all connections
sendbackup: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --best
sendbackup-gnutar: pid 30090: /usr/bin/gzip --best
sendbackup-gnutar: doing level 0 dump as listed-incremental to
/usr/local/amanda/var/amanda/gnutar-lists/ss2.airsse_home_0.new
sendbackup-gnutar: doing level 0 dump from date: 1970-01-01 0:00:00
GMTsendbackup: spawning /usr/local/amanda/libexec/runtar in pipeline
sendbackup: argument list: gtar --create --file - --directory /home
--one-file-system --listed-incremental
/usr/local/amanda/var/amanda/gnutar-lists/ss2.airsse_home_0.new
--sparse --ignore-failed-read --totals --exclude-from /home/exclude.gtar .
sendbackup-gnutar: /usr/local/amanda/libexec/runtar: pid 30092
sendbackup: started index creator: "/bin/gtar -tf - 2>/dev/null | sed -e
's/^\.//'"
sendbackup: index pipe returned 36096
sendbackup: pid 30089 finish time Tue Jul 17 03:00:58 2001
------
excerpt of sendbackup.debug on mc4:
------------------
sendbackup: debug 1 pid 5637 ruid 11 euid 11
start time Tue Jul 17 00:16:04 2001
index tee cannot write [Broken pipe]
sendbackup: pid 5639 finish time Tue Jul 17 02:16:59 2001
------------------
It appears to take a little over an hour to send the backup on ss2...but on
mc4 which also fails on backup of /home, it takes 2 hours to send the backup.
So that confuses me if it is some sort of timeout....
Also, I've read other messages in the archive with this problem and it seems
to relate to firewall settings. The remote system is not behind any type of
firewall, but the amanda backup server dis behin a firewall on the local
network. What kind of timeout setting would i have to set on the
firewall...if it was related to a timeout?
Thanks,
Nathanael
