rsync direct to NFS share? (non-mounted)

[one33_bpm]

Hello All,

I am trying to rsync data from my FreeNAS to a Synology box on my local network. Previously, i have done this through a CIFS mount, SSH, and rsyncd. These work well, and all that, but I was interested to see what the performance would be like over NFS.

Of course I have tried rsync over a mounted an NFS share, however, I happened to come across a thread on samba.org that suggested that i could rsync directly to the share, without having mounted it. (linky)

When I tried executing this command on my FreeNAS box, I get the following...

Code:

[root@furnace] /mnt# rsync -avP --no-o --no-g /mnt/zDisk/software thermostat:/volume1/tresor
Could not create directory '/root/.ssh'.
The authenticity of host 'thermostat.powdahaus.lan (192.168.14.3)' can't be established.
ECDSA key fingerprint is 0b:88:ae:be:46:34:a1:d7:ff:c2:98:67:d8:7c:77:33.
Are you sure you want to continue connecting (yes/no)?

It appears that it is trying to initiate rsync over SSH instead of through NFS. When I let this command run through, it appears to run through SSH. Throughput & CPU usage reflect this on both sides of the rsync.

Why is this the case? Have I missed some configuration somewhere? Is what I am trying to do even possible?

 

[cyberjock]

]You do not understand how rsync works. Rsync establishes a connection over SSH and each side does some rsync work, then both sides figure out what needs updated.

I don't even know what the hell you are trying to do by "initiating rsync through NFS". That whole thing smells of someone that has no clue how this stuff works.

 

[one33_bpm]

]You do not understand how rsync works. Rsync establishes a connection over SSH and each side does some rsync work, then both sides figure out what needs updated.

I don't even know what the hell you are trying to do by "initiating rsync through NFS". That whole thing smells of someone that has no clue how this stuff works.

Cyberjock,
Lets try to avoid a flame war, please.

Rsync functions in multiple ways. You have covered the most common case, that which I called "initiating rsync over SSH." Another case where "each side does some rsync work, then both sides figure out what needs updated" is using rsyncd on the server side (without encryption).

You omitted the other use-cases where rsync is simply used to copy data between two directories. This is useful if you wish to do things like preserve permissions, ownership, and links. An extension of these is when src/dest directories happen to be mounted CIFS or NFS shares. In these cases, the rsync process is only started on the initiating side of the link, while the CIFS or NFS client does double duty (read+write) to transfer the relevant data to/from the running rsync process. While this does double the network traffic, it does eliminate the need to perform encryption/decryption, or the need to run rsyncd on the server. This is what I meant by "initiating rsync through NFS/CIFS".

So I came across the aforementioned thread on samba.org (which seems like a reputable source) describing the rsync CLI syntax used to transfer data directly to the NFS share, without having to mount that share, that I had never seen or used before. (The destination syntax adheres to a typical NFS URI, which admitedly looks just like SSH syntax, but without the preceeding '-e ssh') It seemed like it might remove the need to run rsyncd or SSH on the weak Synology processor, or mount the Synology share on the FreeNAS, which i have other concerns over. As I stated earlier, I was unable to produce the expected results on my Debian & FreeNAS VMs.

Now, I haven't looked over the rsync source code, and I can accept that the thread on samba.org may be incorrect, though a good bit of google-ing has shown a couple of threads elsewhere with similar implications. But I did not disregard the possibility of it being true, or that there might be others here that have far more experience than I in using it, who could offer a clean response to one of the questions I posed. That is why I asked the question.

Anyway, I will leave this thread open until I find/receive a more definitive answer on the matter.

 

[fracai]

Can you post the link to that thread on samba.org? I'm interested in what is being described there.

 

[Dusan]

You can use rsync in three modes:

1. Local: both source and destination are local directories (which may be CIFS or NFS mounts, but rsync does not care)
2. Rsync deamon: source or destination is <system>::<module/path> (you need to have rsync --daemon running on the remote)
3. Remote shell: source or destination is <system>:<path>, in this case rsync will use a remote shell to launch rsync on remote and use it to "speed up" the transfer (calculate checksums, ...)

The destination syntax adheres to a typical NFS URI, which admitedly looks just like SSH syntax, but without the preceeding '-e ssh'

Older versions of rsync defaulted to rsh (no encryption) for the remote shell, newer builds default to ssh. You can override the default by setting the RSYNC_RSH environment variable or by the -e (--rsh) option. The remote shell mode is not "switched on" by the -e option. Remote shell mode is initiated by specifying a <system>:<path> source or destination. The -e option only allows you to change the remote shell application.
Also, if you check the next message in the thread you linked you'll see that they discuss rsync running on the remote (they call it incorrectly rsync deamon, but in this case it is not running in the --deamon mode, it's in the remote shell mode).

 

[one33_bpm]

Older versions of rsync defaulted to rsh (no encryption) for the remote shell, newer builds default to ssh. You can override the default by setting the RSYNC_RSH environment variable or by the -e (--rsh) option. The remote shell mode is not "switched on" by the -e option. Remote shell mode is initiated by specifying a <system>:<path> source or destination. The -e option only allows you to change the remote shell application.
Also, if you check the next message in the thread you linked you'll see that they discuss rsync running on the remote (they call it incorrectly rsync deamon, but in this case it is not running in the --deamon mode, it's in the remote shell mode).

Dusan, thank you for being helpful and pointing out what I have missed.