Re: sendbackup: stream_accept: timeout after 30 seconds
On Thu, Aug 28, 2003 at 10:59:28AM +0200, Christian Arnold wrote: > Hello amand users, > > i use amanda version 1:2.4.2p2-4 on a Debian-Woody system. > The amanda version on the clients and server is equal. > The backup from each clients woks fine at the last days. > But now makes on client problems. > > The following logfile from these client: > sendbackup.20030828024016.debug ### > > sendbackup: debug 1 pid 28358 ruid 34 euid 34 start time Thu Aug 28 02:40:16 2003 > /usr/lib/amanda/sendbackup: version 2.4.2p2 > sendbackup: got input request: DUMP md1 0 1970:1:1:0:0:0 OPTIONS > |;bsd-auth;compress-fast;index; > parsed request as: program `DUMP' > disk `md1' > lev 0 > since 1970:1:1:0:0:0 > opt `|;bsd-auth;compress-fast;index;' > sendbackup: try_socksize: send buffer size is 65536 > sendbackup: stream_server: waiting for connection: 0.0.0.0.33829 > sendbackup: stream_server: waiting for connection: 0.0.0.0.33830 > sendbackup: stream_server: waiting for connection: 0.0.0.0.33831 > waiting for connect on 33829, then 33830, then 33831 > sendbackup: stream_accept: timeout after 30 seconds > sendbackup: timeout on data port 33829 > sendbackup: stream_accept: timeout after 30 seconds > sendbackup: timeout on mesg port 33830 > sendbackup: stream_accept: timeout after 30 seconds > sendbackup: timeout on index port 33831 If, as you indicate, backups were working fine for a while, then I would guess a change has been made to your network configuration on client or server. Perhaps the indicated ports (33829 ...) are not allowed. For more info about amanda's usage of network ports see the document /docs/PORT.USAGE. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: to compress or not to compress ???
On Thu, Jul 03, 2003 at 02:18:26PM -0400, Eric Siegerman wrote: > > - Better compression, probably. Hardware compression is > typically some variant of LZ, isn't it? I don't know how > gzip -1 (the default "compress-fast") compares with that, but > gzip -9 (the default "compress-best") does a lot better. > > Ok, here's one quickie far-from-representative test. Sorted in > order of decreasing size, a largish, mostly-text file, and its > compression by compress, and by the several grades of gzip. > SizeCPU File > --- > 5560320 0 amanda-2.4.4.tar > 2096458 0.88 amanda-2.4.4.tar.Z > 1496904 0.68 amanda-2.4.4.tar.gz1 > 1227454 1.28 amanda-2.4.4.tar.gz6 > 1220934 2.01 amanda-2.4.4.tar.gz9 My tests have always shown similar results. I wish we could do comprss-default (no -level option), which is the same as -6, and get nearly the same compression as -9 but with far less cpu. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
