Rsync Module vs SSH?

[Dowd]

I wanted to get a second opinion on this because I want to make sure I understand the pros and cons properly for my use case.

I have two manufacturing locations, each location holds a TrueNAS storage server with 72TB storage. Location A is our main office and will be where the files get changed and modified, they will then be synced up every night to Location B, this is the best solution for us that gives reliability if one NAS dies, we can still restore from the second and also pull from the second (abeit a hit in production) and both locations can access the files (consolidating them at one location wont work for bandwidth reasons).

I am using rsync over ssh to accomplish this, but I am realizing the sync process is extremely slow even with the two servers plugged into a 10Gbps port switch at present (~1.25 Gigabit transfer speeds). In my research I read someplace that Rsync Module would be faster than Rsync over SSH, but I can't really confirm this anywhere. Looking at the rsync module, I have a few other questions.

1. Does the rsync module use any encryption when transferring from one server to another?

2. Does the rsync module have any authentication? I couldn't see anything regarding passwords or authentication in the TrueNAS guide.

3. Since we are transferring files over the WAN would the rsync module still be recommended? I was considering doing a VPN tunnel instead of SSH, however my concern is if the rsync module doesn't do encryption when the traffic leaves the VPN tunnel at Location B it will be unencrypted on its path to the TrueNAS at Location B, while SSH is all the way from server to server.

Thanks in advance!

 

[jgreco]

I read someplace that Rsync Module would be faster than Rsync over SSH, but I can't really confirm this anywhere.

Consider it confirmed. Using SSH involves a second executable on each side (ssh/sshd) and a UNIX pipe, and all of the additional overhead.

1. Does the rsync module use any encryption when transferring from one server to another?

No. A conventional UNIX tool, it does not try to solve every use case under the sun, and instead focuses on its competency. In the typical UNIX design philosophy, you would use a sync tool to handle your file sync needs, and an encryption tool to handle your encryption requirements. Historically, stunnel has been paired with rsyncd where encryption is desired.

2. Does the rsync module have any authentication? I couldn't see anything regarding passwords or authentication in the TrueNAS guide.

Yes, it allows authentication by authorized IP address ("hosts allow =" in rsyncd.conf) and/or authorized users (listed in rsyncd.secrets), along with providing basic permissions for read or write access. It is not terribly sophisticated IMO.

Since we are transferring files over the WAN would the rsync module still be recommended?

This depends entirely on your security. A WAN is much more secure than, for example, going over the public Internet. Whoever is selling you the fiber/wave/MPLS/etc is certainly a point of attack, as is the local network inside your LAN. You've already figured that out, good:

at Location B it will be unencrypted on its path to the TrueNAS at Location B, while SSH is all the way from server to server.

So you really have three potential options. SSH/SSHD are heavyweight options, but are built into the FreeNAS ecosystem and fully supported (i.e. documented, and people here on the forums would be familiar with them). RSYNCD is a super-lightweight option, and is also built-in. RSYNC using stunnel has the components built in to FreeNAS (i.e. stunnel and rsync both exist) but no plumbing for them. That wouldn't and shouldn't stop you from using them with some setup using an init task to start up stunnel, and then configuring rsync/rsyncd on both sides to connect to 127.0.0.1 using the stunnel encrypted path. stunnel will be more performant than SSH, but it isn't clear to me by how much.

 

[rvassar]

I guess my add here is:

1. Have you looked at your bandwidth in the middle? Is it shared? Are there other jobs running at the time that are under your control and can schedule around? Etc...
2. What steps have you taken to reduce the quantity of bits in flight? Is Rsync really the correct solution? Have you looked at zfs send / receive, etc...?