I don't understand the need for an rsync server in daemon mode. What are the benefits from it if I can use rsync with SSH or telnet?
Many, but I will cite a few off the top of my head.
What if ssh/rsh are not available on the remote server or if they are broken in terms of configuration or stricter network rules? Using rsh/ssh still would require the client (depends on the sender or receiver role), the remote side would have to however fork the rsync binary locally and establish the connection with the rsync process running at the local side. rsh/ssh would merely provide a connection tunnel; as far as rsync is concerned, rsync is communicating with the other rsync process over the pipe(s).
Having a daemon mode rsync process would make the server a true ftp look-alike server where some of the filesystems can be made available through rsync modules. Everything else can be avoided. Say I want to make available only /usr/local and /var for download and refuse any rsync client's request for other downloads. I can use discretion at the host level or at the filesystem (modules) level to allow either upload or download (read only).
Can control host/user level access, authentication, authorization, logging and filesystem (structure) modules for download/upload specifically through a configuration file. Every time a change is made to the configuration file,
rsyncd --daemonneed not be restarted or
HUPped. Can also put control on how many clients can connect to the rsync server process at a time. This is good, since I do not want my rsyncd server process to hog down the host completely over CPU or disk based I/O operations.
chroot functionality can be made available through the configuration for rsyncd in daemon mode. I can use this as a pretty neat security feature if I want to avoid clients connecting to my rsyncd for any of the files/filesystems that must be secured on the host and should not have outside access.
I can outright deny some of the options used by rsync client and not entertain at the server end, such as not allowing the
Can have an option to run some commands/scripts before and after the rsync process. An example would be reporting and storing the rsync stats in post-transfer mode.
These are some of them, but I am sure the expert users of rsync can throw more light on this.
I experienced an issue trying to sync a large folder between a linux machine and a windows machine using cygwin. After dropping the SSH tunnel in favor of using the rsync daemon, my problems went away.
Client doesn't need to know the filesystem layout, etc. of the server he/she is pushing/pulling to/from
1+1 for #2. Situations like mirror networks create uncertainty due to their highly distributed nature, so it's nice to be able to decouple irrelevant local decisions from the operation of the network. Dec 6, 2011 at 16:09
@tim what was the issue you experienced with Cygwin and
rsyncusing SSH? Apr 29, 2019 at 4:33
A common usage for rsync is to mirror public archives of files. The operator of the primary copy doesn't want to permit remote shell access to the archive, but wants the volunteers running the remote mirrors to be able to efficiently get a complete copy of the archives. Rsync works extremely well for creating a mirror since it will only download changed bits, and if there is a slight interruption in the network, it will not re-download an entire large file (cd/dvd images).
The bit torrent protocol actually may be a better choice for this now, but rsync was released many years earlier.
Even now many major archives still use rsync for mirrors.
The mirroring protocol which we recommend is rsync.
SSH gives overhead due to e.g. the encryption usage. So in theory you should get higher throughput with an rsync server daemon.
2I won't downvote you for this, because yes, there does exist a theoretical network where encryption overhead matters. I think you'll find if you measure it, though, is that it's insignificant on real networks, except perhaps for the initial key negotiation phase. Once packets are flowing, encryption time is swallowed by network latency. Dec 6, 2011 at 16:11
1@WarrenYoung Elderly machine hosting a public rsync server on a big pipe. Dec 6, 2011 at 23:40
2@Gilles - A machine slow enough that it can't encrypt fast enough to keep the pipe full probably runs into disk bandwidth problems first. Bottom line, I'd like the see the measurements. And before someone posts measurements, be sure to try doubling the transfer size and making sure any effect you've measured also doubles. If not, you're counting key negotiation, which I'll grant up front takes measurable time. Dec 7, 2011 at 0:42
Parallelizing rsync would be better option with GNU parallel in that case. Dec 16, 2011 at 11:30
You can provide rsync-services to an extranet and allow syncs that way without having to expose ssh.
In daemon mode rsync will propably calculate local checksums faster and is thus better suite if you expect multiple parallel clients. With the standalone command checksums need to be recalculated for every session.