Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got two FreeBSD machines set up; one serves video data and the other is the backup for the first. At this point I've got around 4TB of data. I add files to the video server a few at a time, and was planning to use rsync over ssh to keep the backup machine up to date.

I did the initial, large backup with both machines hooked up to the same subnet at the lab with no problems using rsync. Then, when I moved the backup machine off-site (but still on the university network), I attempted a sync without changing anything other than the IP (as the machine is now on a different subnet) and got the following error:

2010/03/22 15:55:21 [1260] rsync: connection unexpectedly closed (6340840244 bytes received so far) [receiver]
2010/03/22 15:55:21 [1260] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [receiver=3.0.7]
2010/03/22 15:55:21 [1258] rsync: connection unexpectedly closed (60 bytes received so far) [generator]
2010/03/22 15:55:21 [1258] rsync error: unexplained error (code 255) at io.c(601) [generator=3.0.7]

The script that handles the backup hasn't been changed, nor has the crontab that invokes it. Does anyone have any ideas about what might be causing the hiccup? I was under the impression that it might have something to do with the ssh connection timing out or something along those lines, but am not entirely clear on how to diagnose the cause of the problem.

share|improve this question
check out this question:… – Aleksandar Ivanisevic Mar 25 '10 at 20:53
Maybe you can get more helpful output by increasing verbosity with up to -vvv. – MacLemon Mar 25 '10 at 22:02

It appears like your connection has been established and data has been transmitted so it doesn't seem like the issue is related to your known_hosts or establishing your connection.

If there was a NAT between the 2 computers and rsync needed to calculate the checksum for a large file then it seems like it would be possible that the time it takes to calculate the checksum would exceed the length of time that the translation for your connection is saved in the state table. I would be tempted to add an option like this ServerAliveInterval 60 on the machine acting as the ssh client to force keep alives to be sent.

share|improve this answer
I had missed that. Good catch. – Dan Andreatta Mar 25 '10 at 21:21
Ok, I'll give that a try. I haven't really done much in the way of ssh config tweaking, but figured there was an issue with flow control or timing across the network. – user38818 Mar 25 '10 at 21:27

Have you tried, as the user running rsync, sshing to the server in it's new location from the backup server?

share|improve this answer
Yes, and that works just fine – user38818 Mar 25 '10 at 21:21

Since you have moved server, now SSH will complain that the server identity has changed or will ask to confirm a new server identity. So as Cry Havok said, you have to ssh as the rsync user and confirm the change (you may have to edit the .ssh/known_hosts file and delete the offending key).

If you can, you should try rsync w/o ssh, i.e. run the rsync daemon and try with that, so you can exclude one variable at the time.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.