Martin Angove
Cadet
- Joined
- Jan 13, 2013
- Messages
- 3
I am trying to use Rsync to replicate one share on a Qnap TurboNAS 859 (4x2TB in RAID6) to a FreeNAS server elsewhere in the same building (on the same network) purely for backup purposes.
The Qnap is acting as the Time Machine target for a single OSX machine and it is this (hidden!) directory, currently containing about 1.5TB of data (the machine is used mainly for video editing), that I'm trying to sync. I have successfully set up an Rsync module on the FreeNAS machine and an Rsync job on the Qnap and things progress well (if slowly - I'm getting about 300Mbit/s only across what should be a gigabit link) until the transfer gets to something like 95% complete whereupon I get the following from the FreeNAS box:
about an hour later I get an email from the Qnap that says (slightly obfuscated):
At this point transfers re-start, but it seems as though the Qnap starts from scratch rather than just completing the previously almost-complete transfer. After three retries the Qnap fails the sync:
(obviously this was from a previous attempt - the current attempt hasn't finally failed yet, but this is the fourth time I've tried)
The Qnap has an option to use "RTRR" (so-called Real Time Remote Replication) to another server and I could use this instead of Rsync, except that while I can manually enter the path for the Time Machine directory in the Rsync setup, I can't enter it in RTRR (which uses a file browser which can't see the Time Machine directory).
The FreeNAS box is one I have built fairly recently and some initial problems turned out to be a dodgy CPU which booted fine but crashed under load (errors in the L1 cache IIRC). It has been replaced temporarily with a spare processor until I get around to swapping the original. Current spec. for the FreeNAS box is then:
The intervening network is 3x managed gigabit switches with gigabit fibre switch-switch links. This sector of the network was upgraded specifically to allow the NAS boxes (and the Mac) to talk at gigabit speeds.
Any thoughts gladly received. Backing up the Time Machine archive is the first thing, then there is a second QNAP with more general files that I wish to backup. This is a work setup, but I'm also considering how I can backup my home FreeNAS box, probably to another unit offsite. If I can get Rsync working on an internal network I'm hoping it's not too much extra work to get it going across t'internet
Thanks.
Martin.
The Qnap is acting as the Time Machine target for a single OSX machine and it is this (hidden!) directory, currently containing about 1.5TB of data (the machine is used mainly for video editing), that I'm trying to sync. I have successfully set up an Rsync module on the FreeNAS machine and an Rsync job on the Qnap and things progress well (if slowly - I'm getting about 300Mbit/s only across what should be a gigabit link) until the transfer gets to something like 95% complete whereupon I get the following from the FreeNAS box:
Code:
Jan 13 04:47:49 backupnas rsyncd[90856]: rsync error: timeout in data send/receive (code 30) at io.c(137) [receiver=3.0.9] Jan 13 04:47:49 backupnas rsyncd[90856]: rsync: connection unexpectedly closed (280 bytes received so far) [generator] Jan 13 04:47:49 backupnas rsyncd[90856]: rsync error: error in rsync protocol data stream (code 12) at io.c(605) [generator=3.0.9]
about an hour later I get an email from the Qnap that says (slightly obfuscated):
Server Name: MacNAS
IP Address: 172.22.x.x
Date/Time: 2013/01/13 05:48:36
Level: Error
[Remote Replication] MacNASBackup failed: rsync error: timeout in data send/receive (code 30) at io.c(137) [receiver=3.0.9]. Begin 3rd retry.
At this point transfers re-start, but it seems as though the Qnap starts from scratch rather than just completing the previously almost-complete transfer. After three retries the Qnap fails the sync:
Server Name: MacNAS
IP Address: 172.22.x.x
Date/Time: 2012/12/09 13:43:21
Level: Error
[Remote Replication] MacNASBackup failed: rsync error: timeout in data send/receive (code 30) at io.c(137) [receiver=3.0.9].
(obviously this was from a previous attempt - the current attempt hasn't finally failed yet, but this is the fourth time I've tried)
The Qnap has an option to use "RTRR" (so-called Real Time Remote Replication) to another server and I could use this instead of Rsync, except that while I can manually enter the path for the Time Machine directory in the Rsync setup, I can't enter it in RTRR (which uses a file browser which can't see the Time Machine directory).
The FreeNAS box is one I have built fairly recently and some initial problems turned out to be a dodgy CPU which booted fine but crashed under load (errors in the L1 cache IIRC). It has been replaced temporarily with a spare processor until I get around to swapping the original. Current spec. for the FreeNAS box is then:
- AMD A8-3870 APU (was originally, and will be, an A4-3400)
- Motherboard: Asus F1A75V-Evo
- RAM: 16GB as 2x8GB DDR3-1600
- Discs: 8x750G Seagate ST9750420AS 2.5" in caddies (4 to a 5.25" bay - thoroughly recommend this as a solution to more drives in less space) with empty bays for 8 more drives
- Storage configured as one RAIDZ2 dev giving about 4.5TB(decimal) online
- SATA: 6+1 onboard SATA3 ports (4 in use) and 3x 4-port SATA3 cards (cheap Startech ones) in PCIe x4 slots (4 ports on one card in use at the moment)
- Network: Onboard Realtek 8111 because the nice Intel NIC missed the order and is coming in the next batch of stuff
- FreeNAS: 8.3.0 (x64)
The intervening network is 3x managed gigabit switches with gigabit fibre switch-switch links. This sector of the network was upgraded specifically to allow the NAS boxes (and the Mac) to talk at gigabit speeds.
Any thoughts gladly received. Backing up the Time Machine archive is the first thing, then there is a second QNAP with more general files that I wish to backup. This is a work setup, but I'm also considering how I can backup my home FreeNAS box, probably to another unit offsite. If I can get Rsync working on an internal network I'm hoping it's not too much extra work to get it going across t'internet
Thanks.
Martin.