Hi!
First of all let me tell you this post should go on amanda-users mailing-list, 
not the hackers one: your question si about using and not implementing Amanda ;)

Well... Your issue makes me think of the "*timeout" parameters in the config 
file. Your compress step may take too long for Amanda and she may close the 
socket before data compression is finished. In your case, try to increase your 
dtimeout ("data timeout") value. You have 2,3 Gb to backup. It may take a bit 
long to tar and gzip all this data, especially if you have many many files. To 
give you a value to compare with, my dtimeout is set to 7200s (yes, 2h) (and 
yes I have a quite huge platform with more than 300 clients).
I don't think this is a Cygwin problem but just a server-side one.


-----------------------------------------------------------------------
Jean-Christian SIMONETTI    email: jean-christian.simonetti AT wanadoo DOT com
SysAdmin Wanadoo Portails   phone: (+33)493004911
Sophia Antipolis, France
-----------------------------------------------------------------------


On Mon, 06 Oct 2003 15:10:19 +0200
Franz Skale <franz.skale AT cubit DOT at> wrote:

> Hi all again!
> The problem on the XP running cygwin and Amanda Client 2.4.4p1, lies on the 
> gzip command.
> I enabled "client fast"  in the amanda.conf on the server. If client compress 
> is enabled then the backup fails with: "gzip: stdin: Connection reset by 
> peer".
> So i turned of client compression. Fazit, the backup works, but the netload 
> is enourmous.
> The magic thing is, that amanda nevertheless shows the same error, but the 
> dump went on the holding disk.
> See the output at the end of the mail.
> Now my question.
> Is gzip buggy on cygwin, or is it another problem which let gzip fail on 
> stdin compression ?
> Server Side compression is not working, and the error is still the same. 
> ("gzip: stdin: Connection reset by peer").
> Is there a fix or a workaround with some gzip parameters ?
> 
> Thanks in advance
> 
> 
> Franz
> 
> 
> 
> Amanda Output of XP Backup:
> Some dumps may have been left in the holding disk.
> Run amflush to flush them to tape.
> The next tape Amanda expects to use is: a new tape.
> 
> 
> STATISTICS:
>                           Total       Full      Daily
>                         --------   --------   --------
> Estimate Time (hrs:min)    0:04
> Run Time (hrs:min)         0:30
> Dump Time (hrs:min)        0:26       0:26       0:00
> Output Size (meg)        2176.5     2176.5        0.0
> Original Size (meg)      2301.8     2301.8        0.0
> Avg Compressed Size (%)    94.6       94.6        -- 
> Filesystems Dumped            1          1          0
> Avg Dump Rate (k/s)      1427.7     1427.7        -- 
> 
> Tape Time (hrs:min)        0:00       0:00       0:00
> Tape Size (meg)             0.0        0.0        0.0
> Tape Used (%)               0.0        0.0        0.0
> Filesystems Taped             0          0          0
> Avg Tp Write Rate (k/s)     --         --         -- 
> 
> 
> DUMP SUMMARY:
>                                      DUMPER STATS            TAPER STATS
> HOSTNAME     DISK        L ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS 
> KB/s
> -------------------------- ---------------------------------
> ------------
> dyn43 -/Testbackup 0 23570202228722  94.6  26:011427.7   N/A   N/A 
> (brought to you by Amanda version 2.4.4p1)
> 
> 
> 
> 
> -- 
> kind regards,         +43-664-8279163
> Franz Skale           +43-1-7189880-0
> Systems Engineer      www.cubit.at
> PGP KeyID             0xB294D39A
> Key Fingerprint               B508 8896 B83C B374 770D 80EF 3AD9 4A66 B294 
> D39A
>