NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
RSYNC failure between two ReadyNAS (?)
I've added a 524x to my system for backup (was using an EDA500 off my 716) and am using rsync to do it per the instructions in the backup FAQ. Most of my jobs set up with the backup manager work ...
OK, the issue almost for sure is not using the actual IP address of the destination.
The backup manager will allow one to search for the destination NAS and will show its name (not IP address). This can be used to complete the parameters for the backup.
BUT as we've seen this apparently forces the NAS to periodically resolve the name and this can fail at any point in the backup.
Too bad, because if one is using dynamic addressing on one's local network the device addresses can change if one needs to reboot the local router. And this means going through all the backup jobs and changing the address (ugh!).
It would be simpler to resolve the name once and then store the value for the duration of the backup . . .
Thanks StephanB
Yes, rsync (read and write) is enabled.
Curious thing is that I can restart the backup job and it completes. And if I start the job again - as in incremental job - it will complete again with no additional files copied.
I have not done a full compare of the two shares to make sure everything was copied completely and correctly . . . but am assuming that running the backup job a second time (as in incremental) checks this.
??
hmuessig wrote:
I have not done a full compare of the two shares to make sure everything was copied completely and correctly . . . but am assuming that running the backup job a second time (as in incremental) checks this.
Yes.
hmuessig wrote:
Curious thing is that I can restart the backup job and it completes. And if I start the job again - as in incremental job - it will complete again with no additional files copied.
It might be some other resource constraint. I've occasionally seen a failed (or stalled) rsync backup. Re-starting it always seems to fix it.
Backup Job Name: BackupHMiTunes
Backup Job Type: Full
Protocol: rsync
Backup Source: [BackupHMiTunes]//
Backup Destination: [remote:rsync]/BU1611.local::BackupHMiTunes
Backup Start Time: Wed Jun 12 2019 1:58:25 PM
Backup Finish Time: Wed Jun 12 2019 1:59:30 PM
Backup Status: Fail: Failure during copy.Failed to run rsync, return rc 10
rsync: failed to connect to BU1611.local (192.168.1.29): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(127) [sender=3.1.3]Happened again . . . just created another share on the backup server, created the job on the main server, and ran it with the result above. Reran it with the same error.
FYI the share is 149GB
Note that I've used the nas name rather than its ip address in the destination "host" field. Changed that to the ip address and ran it again . . . and it worked.
My network is gig ethernet with Netgear switches. And the NAS reports that the transfer speeds are anywhere between 80 and 110MBps between the main nas and the backup. Buffer overrun?
Or is something happening with the DNS/name resolution during the transfer when I use the nas name rather than it's ip address??
TIA
I think the NAS just isn't always resolving the name correctly FWIW, I use IP addresses in all my backup jobs.
hmuessig wrote:
My network is gig ethernet with Netgear switches. And the NAS reports that the transfer speeds are anywhere between 80 and 110MBps between the main nas and the backup. Buffer overrun?
Buffer overrun wouldn't be selective - and the rsync packets are routed based on IP and MAC addresses anyway.
Rsync has to figure out what it needs to transmit - which requires some back-and-forth between the client and the server. Then the real transfer begins. I think the "figuring out" bit is the main reason the network speeds will vary. The IOPS of the two RAID arrays also can limit the throughput (especially if you are dealing with a lot of small files).
OK, the issue almost for sure is not using the actual IP address of the destination.
The backup manager will allow one to search for the destination NAS and will show its name (not IP address). This can be used to complete the parameters for the backup.
BUT as we've seen this apparently forces the NAS to periodically resolve the name and this can fail at any point in the backup.
Too bad, because if one is using dynamic addressing on one's local network the device addresses can change if one needs to reboot the local router. And this means going through all the backup jobs and changing the address (ugh!).
It would be simpler to resolve the name once and then store the value for the duration of the backup . . .
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
