Re: iptables/backups/sound files fixed
About the problem and the solution described below.
What as the error message that Amanda gave in this case?
- disk offline?
- timeout error?
- ...
(Trying add this issue into the docs...)
Paul Bijnens wrote:
Glenn English wrote:
On Sun, 2005-11-20 at 19:36 +0100, Paul Bijnens wrote:
Turns out the problem was the iptables packet filter on the amanda
client. iptables has a timeout for idle TCP connections that was
breaking the connection to the server before the initial estimate of
the
backup size was done (because it took so long to go through the huge
DLE).
The solution is to decrease the time between keepalive packets:
'echo 90 > /proc/sys/net/ipv4/tcp_keepalive_time'
I don't think this will help, because the estimates are exchanged
using UDP traffic.
The setting did it, but my understanding of why is wrong.
As I said to Paul off list, I put the default value back and watched
last night's backup.
The three ~12GB estimates came in, and the timeouts happened during the
data transfers (Connection reset by peer). I don't understand this.
Now I do, see below.
iptables times out and breaks a TCP connection on time, even if 100% of
the bandwidth of that connection is being used?? I doubt it
I set the timeout to 90 and reran a backup by hand. The data transfers
are working.
In other words, increasing iptables' TCP timeout seems to be necessary
for amanda backups of huge DLEs, but I don't understand why.
...
It says in the amanda dox ( http://www.amanda.org/docs/portusage.html )
AMANDA also uses TCP connections for transmitting the backup image,
messages and (optionally) the index list from a client back to the
dumper process on the tape server. A process called sendbackup is
started by amandad on the client. It creates two (or three, if
indexing is enabled) TCP sockets and sends their port numbers back to
dumper in a UDP message. Then dumper creates and binds TCP sockets on
its side and connects to the waiting sendbackup.
This sounds a lot like FTP to me. Maybe it's the messages connection
that's timing out.
Aha, that makes more sense.
Yes indeed, the data is transferred with one TCP connection, and the
stderr output is transferred over another TCP connection (and if you
do indexing, the table of contents is yet another TCP connection.
And yes, if there are not many errors, there is no traffic, except the
at the end, summarizing the number of bytes transferred and speed.
That can time out yes indeed!
And indeed, the above settings helps in this case.
--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens@xplanation.com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
Reply to: