rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(760) [receiver=3.0.7] rsync: connection unexpectedly closed (183 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7]
Backup failed. Sat Jul 10 01:22:20 MDT 2010.
Reason for failure: Error encountered copying data from remote source path TIBMain::ARCHIVE ==> /ARCHIVE/ due to unknown reason. Please see log.
There are no network errors seen by either NAS unit - and their shouldn't be - my network is in top condition with an HP Procurve switch at the core.
After doing some searching (Google/etc) on rsync, I've come to one simple conclusion, buoyed up by 30+ years experience in the IT field where I've worked with/on various flavors of Unix professionally as well as every Windows version since 3.1 and DOS before that.
rsync is simply NOT a flawless or mature protocol in it's linux implementation.
It is NOT ready for prime-time - aka use in a PRODUCTION environment.
It fails - for many people - without any definable cause or permanent solution/fix.
(Well, no one has defined the cause of these current failures to MY satisfaction!)
It IS a perfect example of a "horse made by committee" and Netgear needs to get IN GEAR to provide its BUSINESS users with a protocol that "just WORKS" for synchronizing one NAS unit with another NAS unit - both of their manufacture.
I can consistently make rsync fail, yet a CIFS backup (sorry, mdgm - it just WORKS!) works and completes - even if dreadfully slow.
For those that doubt rsync's "cruftiness" - please just google:
error in rsync protocol data stream (code 12) at io.c(760) [receiver=3.0.7]
or
error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7]
You will find currently 300+ hits on the first, and 600+ on the second.
We don't ALL have "network errors"
I know I don't.
Neither NAS logs any errors, nor does my HP Procurve 2824 switch.
The cables connecting the NAS units to the Procurve are 5ft Cat6 cables that have each individually been CERTIFIED by ME using a FLUKE analyzer to well beyond 350MHz.
(Yes, I have the toys that most don't have to find network errors - it was cheaper to buy all the tools/toys than to bring in a commercial electrician to wire up all the networking (over 50 runs of cat6E) in my new house - Analyzers, Sniffers, TDR's)
So how about it, Netgear?
Can we have a RELIABLE NAS-to-NAS backup?
Or do I keep using CIFS - as I did for 4 years on my Infrant RN600's?
It's an open source horse-by-committee and it only takes a few minutes with Google to see that it doesn't work for "everyone".
Hell, other users/customers on this very board are having the same (or similar) problems with rsync as I am having - as well as many hundreds of people on the internet - all on 3.0.7 - the latest rsync available.
(There are whispers of a kernel issue - other whispers of an out-of-memory condition - and yet others of an interaction between certain NIC hardware and rsync - but nothing proven - and nothing "fixed")
Even other linux-based NAS manufacturers (like QNAP) have the SAME problem with rsync for SOME users.
Now, if I wanted to debug a linux kernel - I wouldn't have bought a pre-made business-class NAS.
When you release a product for BUSINESS - it should "just work" for EVERYONE - and this part of Linux, well, just doesn't work (for everyone).
So I've had to use CIFS/Timestamp backups for now.
(There are whispers of a kernel issue - other whispers of an out-of-memory condition - and yet others of an interaction between certain NIC hardware and rsync - but nothing proven - and nothing "fixed")
Memory should not be an issue with the Pro. The stock 1GB should be fine.
Hopefully NetGear can help with your issue.
lndshrk wrote:
Trust me, I wish rsync "just worked". It doesn't.
Well I guess our experiences differ.
I hope NetGear can help you with your issue.
Btw have you tried creating a snapshot and backing up a snapshot of your data. Do you still get the issue then?
If you take a snapshot under Volumes > Snapshot and then backup sharename-snap you can use this to rule out files changing on the source ReadyNAS during the backup job as the issue. You still use Rsync to backup the share, you just backup sharename-snap instead of sharename.
I can already "rule out" filenames changing on the source NAS....
I was the only one who could access it - and I wasn't accessing it.
The whole point of this exercise was moving data from the old NAS to to "primary" new NAS (worked via CIFS) - then to move a copy of that data from the "primary" NAS to the "backup" NAS while setting up all of the needed daily/weekly backup jobs to keep both NAS's synchronized.
(failed via rsync, worked via CIFS)
No one had access to either of the "new" NAS units before this was finished - so filenames didn't change.
I've been to the rodeo before, and rsync is just broken!
Sorry - I should have been more clear. My production box is at 4.2.12 and my backup box is at 4.2.13. I'm not sure if I am willing to try upgrading my production box yet - only because my backup box has fallen off the network twice in the last week since I moved up to 4.2.13.
I would consider updating your production box to 4.2.13 as this may solve the problem.
However if you like, you should try to troubleshoot the problem with the backup box first to determine the cause. There could e.g. be a faulty ethernet cable, faulty port on the router/switch or some other issue.
I know this is long after the original post, but having just had an rsync NAS-->NAS stop working that had been working for months, I finally got it working.
I had an NV+ with 4.1.8 rsync from an Ultra 2 Plus. The connection started and I then got
Mar 8 07:13:30 xxxxxx rsyncd[3864]: rsync: read error: Connection timed out (110) Mar 8 07:13:30 xxxxxx rsyncd[3864]: rsync error: error in rsync protocol data stream (code 12) at io.c(760) [sender=3.0.8]
I read that rsync might have been an issue so I disabled JF on both NAS and tried the backup again and it started working. I then re-enabled them on the U2+ and it still worked then re-enabled on the NV+ and it still worked...
