I currently have a server that nightly backs up its data to a NETGEAR ReadyNAS device using Rsync. This has been working fine for the past few months. However recently, I started to get the following error:

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Connection reset by peer (104)
inflate (token) returned -5
rsync error: error in rsync protocol data stream (code 12) at token.c(604) [receiver=3.0.6]
rsync: connection unexpectedly closed (229743 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]

I've managed to track it down to one particular file that is causing the problem (by using Rsync to copy just that file). The file itself is quite large - about 975Mb. However, there are also other files in the same directory, some as large as 3Gb, and these backup fine.

I'm using the following Rsync command:

 rsync -avz --password-file=/root/rsync.secret <sourcedir> username@readynas::backup

Rsyncing to an Ubuntu Linux host seems to work, so it doesn't look like there's a problem with the rsync client on the server.

I've Googled around but found nothing. A lot of people seem to be saying that adjusting the timeout at the Rsync server end solved similar problems, but if this were my problem I can't understand why it works with the larger files.

Does anyone have any suggestions how to solve this?

  • What operating system is your server using? Did you try rsyncing to a Linux host? – Cosmin Prund Nov 2 '11 at 10:25
  • The OS is Debian 6.0 (Squeeze). Rsyncing to a Linux host works OK - I've edited the original question to reflect this. – FixMaker Nov 2 '11 at 10:56

I have seen this happen (rarely) before when doing compressed rsync between machines. In all cases where I have seen it the data itself was already compressed to begin with (e.g. video-files or zip's). Most files come through OK. Once in w while a specific file has this problem.

Try it without compression. (no -z flag on rsync.) There could be something about the transferred compressed data that, in rare cases, causes the other end to barf.

Besides: Without compression might actually be faster depening on the the speed of the network and the CPU/RAM capacity available on source and destination. Most (low/mid-end) NAS boxes don't really have the power for it.

  • Trying to rsync the single file without compression worked! Looks like you may be right. I'll try running the full backup without compression tonight and see if that fixes the problem. Thanks. – FixMaker Nov 2 '11 at 12:10
  • The full backup (without compression) seemed to work fine, and didn't take noticeably longer than with compression. Problem solved, it appears. – FixMaker Nov 3 '11 at 10:43
  • @Lorax: Glad to be of assistance. I remember vividly what sort of trouble I had to go through to figure out what was going on when it happened to my systems. The rsync people at samba.org are very silent about this issue, but it's a long standing problem that they can't (or won't) fix. – Tonny Nov 3 '11 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.