Finally got some answers out of tech support once they had consulted the Time Backup dev team.
Here's their response with answers to my original questions...
<start>
We have obtain feedback from developer.
Time Backup uses SSH tunneling, iSCSI device, and rsync to perform snapshot and version backup.
Hence the underlying mechanism is quite different from the normal network backup, so the performance could not be compared.
Why are transfer speeds using Time Backup SO much slower than manual data transfers?
Time Backup uses encrypted tunnel, that is, all data will be transferred through the tunnel with encryption and will be much slower. So if you wish to compare the performance, compare with encrypted network backup instead. This is why sshd consumes a lot of CPU.
What is sshd and why is it taking up so much CPU?
Time Backup uses iSCSI device to do volume level snapshot. The snapshot layer will introduce overhead to the volume read/write, and hence the backup (which is volume read) speed will drop comparing to the normal network backup.
But note that if the backup data set were modified during the backup period, normal backup will fail but Time Backup won't (thanks to the snapshot).
Where is the bottleneck when using Time Backup? Can we make Time Backup perform any faster?
For this case, I believe the bottleneck of the performance would be the CPU of the destination server (i.e. 411j).
The reason is that both SSH tunneling and iSCSI device consumes a lot of CPU resources and the performance of 411j is much lower than 412+, and due to high use of CPU on entry model like DS411J with less powerful CPU and RMA, this will reduce greatly the performance of backup also.
So there you have it. Disappointing to say the least.
Remote backups using Time Backup in particular was the main reason we shelled out over $1000 buying two DiskStations to make the whole thing as easy as possible. Synology can argue that Time Backup DOES work on the DS411j, but at such slow speeds as to make it completely impractical. Yet the DS411j (along with many older, less powerful models) is listed as Time Backup compatible on the slick webpage
http://www.synology.com/dsm/home_backup ... backup.php. NO mention of significant performance issues for less powerful models.
Please tell us which method of Network Backup will produce the fastest transfer speeds between these two DS over a local gigabit network.
It's hard to say which backup method is the fastest. For normal network backup, it simply copies the entire data set to the destination. Although you can increase the data transfer speed by disabling encryption, the larger the data set is, the more time it takes to complete the backup. In addition, each backup yields a backup of the entire data set. If there's only a little change to the data set, duplicated copies were made.
Not sure if this is entirely accurate since Network Backup is supposed to perform incremental backups as you can see at the bottom of this page
http://forum.synology.com/wiki/index.ph ... rver#Notes. Either way, once the initial backup has been done you're going to be limited by the bandwidth and congestion of your internet connection which for us will top out at about 1MB/s. So really, the main issue is completing the initial backup in an acceptable timeframe.
In contrast, for Time Backup, although the data transfer is slow, but Time Backup preserves "versions."
That is, if a file is not modified between two backups, Time Backup will be copy the file but instead build a had link.
In this way, if there's only a little change to the data set, only the modified part is transferred.
<end>
So it seems that either way Time Machine is going to be very SLOW performing the initial backup, even over a gigabit LAN, because of the built in encryption (unless BOTH of your DiskStations have a powerful CPU).
My Proposed Solution
1. Forget Time Backup (unless you're prepared to wait days/weeks backing up TB's of data at 3MB/s). It seems our DS411j simply isn't powerful enough to run it, which is very disappointing considering it's a 2011 model!
2. We'll try seeding the initial backup using Network Backup directly over our LAN with NO encryption (to keep the CPU down and speed high).
3. Move the backup unit to the remote location.
4. Forward the recommended ports 873 and 22 for encrypted backups
http://forum.synology.com/wiki/index.ph ... ync_Server
5. Reconnect the backup set to the remote DiskStation's new IP address.
6. To get Network Backup to perform similarly to Time Backup, edit the backup set and check the following options
"Enable Transfer Encryption"
"Enable Block-level Backup"
"Reserve the Backed up files at the destination"
7. Schedule backups for times when we won't be changing the data. Network backups main disadvantage vs Time Backup appears to be that it cannot handle changes to the data WHILE a backup is in progress. Scheduling backups during down times should negate this issue.
-----------------------------------
So we'll give this a go. The saga of network backups continues...
I hope this will help some of you with similar issues.
But still pretty disappointing that a "Synology approved" app will only run effectively on a handful of the more powerful DiskStations. I really feel this should be mentioned in the documentation.
