/usr/bin/rsync -aze /usr/local/ssh/bin/ssh --hard-links --force --ignore-errors --numeric-ids --delete --exclude=/sys --exclude=/proc --exclude=/var/named/chroot/proc --exclude=/home4 --exclude=/home5 --exclude=/backup --exclude=/var/log --exclude=/home/logs --exclude=/home2/logs/ $server:/ /home/backup/$short
The error happens at the same spot during the rsync copy:
Read from remote host $server: Connection reset by peer
rsync: connection unexpectedly closed (16892096 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(632) [receiver=3.0.4]
rsync: connection unexpectedly closed (408 bytes received so far) [generator]
rsync error: unexplained error (code 255) at io.c(632) [generator=3.0.4]
Created attachment 3875 [details]
rsync-debug output (last 200 lines)
This is the last 200 lines from the 10 MB rsync-debug output file. I was not able to get a core dump. If you need anything else, please let me know. The rsync fails on the same file/location every time.
It looks like neither rsync process intentionally closed the connection, so it must have been dropped by the network. This is not a bug in rsync.
ok, just seems strange that the rsync fails every time on the same dovecot.patched.tar.gz file. Any pointers on how to t/s would be appreciated.
That is strange, but the output does seem to indicate pretty clearly that rsync is not the thing closing the connection. It's possible that the file is triggering a data-dependent bug in ssh or even the network (but that seems unlikely because ssh would be encrypting with a different random key each time). In any case, you could see whether rsync fails in the same way when you do any of the following:
- Remove the -z option.
- Transfer using an rsync daemon instead of ssh (unless the file is secret).
- Transfer the file between a different pair of hosts.
- Make a copy of the file, modify it slightly (e.g., modify a few bytes or slightly lengthen or shorten it), and transfer that.