33

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?

Improve this question

5 Answers 5

Reset to default
24

Many, but I will cite a few off the top of my head.

  1. 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).

  2. 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).

  3. 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 --daemon need 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.

  4. 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.

  5. I can outright deny some of the options used by rsync client and not entertain at the server end, such as not allowing the --delete option.

  6. 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.

Improve this answer
8

  1. 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.

  2. Client doesn't need to know the filesystem layout, etc. of the server he/she is pushing/pulling to/from

Improve this answer
2
  • 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.
    – Warren Young
    Commented Dec 6, 2011 at 16:09
  • @tim what was the issue you experienced with Cygwin and rsync using SSH?
    – Daniel Sokolowski
    Commented Apr 29, 2019 at 4:33
3

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.

See: http://www.debian.org/mirror/ftpmirror

The mirroring protocol which we recommend is rsync.

Improve this answer
1
  • See also zsync for this kind of application - it's like rsync but does all the hard work on the client, not the server. The server just needs a pre-calculated list of hashes.
    – rjmunro
    Commented Nov 3, 2015 at 14:51
1

SSH gives overhead due to e.g. the encryption usage. So in theory you should get higher throughput with an rsync server daemon.

Improve this answer
4
  • 2
    I 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.
    – Warren Young
    Commented Dec 6, 2011 at 16:11
  • 1
    @WarrenYoung Elderly machine hosting a public rsync server on a big pipe.
    – Gilles 'SO- stop being evil'
    Commented 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.
    – Warren Young
    Commented Dec 7, 2011 at 0:42
  • Parallelizing rsync would be better option with GNU parallel in that case.
    – Nikhil Mulley
    Commented Dec 16, 2011 at 11:30
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .