We're running a script on our production box that zips up our database and FTPs it to a backup box every night.

Our production box is running Redhat Enterprise 5. Our backup box is running Windows XP Pro / IIS 5.1. Both machines are on the same VLAN (not sure if this is imporatant). The backup file usually clocks in at around 3GB.

Every now and again (~5% of the time), the backup script fails. The shell script on the "client side" - which looks at return codes - never identifies any problem since ftp always returns 0. On the "server side", IIS writes out a log that looks like this:

#Software: Microsoft Internet Information Services 5.1
#Version: 1.0
#Date: 2009-08-08 07:04:25
#Fields: time c-ip cs-method cs-uri-stem sc-status sc-win32-status 
07:04:25 192.168.111.235 [15]USER backup 331 0
07:04:25 192.168.111.235 [15]PASS - 230 0
07:05:54 192.168.111.235 [15]created backup_20090808.zip 426 10035
07:06:16 192.168.111.235 [15]QUIT - 426 0

Now, I know that 426 means "Connection closed, transfer aborted", which is sort-of a catch-all for "IIS was not happy". The real puzzler is the wincode: 10035 (WSAEWOULDBLOCK -- Resource temporarily unavailable). My understanding is that this code is normal when using non-blocking socket calls - which would almost certainly be used by any FTP Server implementation.

My first guess that it might be a timeout issue doesn't make sense, since we're only talking about a few minutes here and the timeout was left at the default 900 s.

Does anybody have any ideas about what is causing this problem, and how it may be fixed? Thanks!