This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
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 . . .
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.
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.
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??
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 . . .
