Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 16 down vote accepted

Many, but I will cite a few on 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. Like I want to make available /usr/local and /var only for download and refuse any other rsync client's request for the file downloads. I can use discretion at the hostlevel 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. And everytime 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 io 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. Like not allowing --delete option is possible.

  6. Can have an option to run some commands/scripts before and after the rsync process. Example: Useful to report & store the rsync stats in post transferr mode.

These are some of them, but I am sure the expert users of rsync can throw more light on this.

share|improve this answer
  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

share|improve this answer
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 Dec 6 '11 at 16:09

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.

share|improve this answer

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

share|improve this answer
1  
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 Dec 6 '11 at 16:11
    
@WarrenYoung Elderly machine hosting a public rsync server on a big pipe. –  Gilles Dec 6 '11 at 23:40
1  
@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 Dec 7 '11 at 0:42
    
Parallelizing rsync would be better option with GNU parallel in that case. –  Nikhil Mulley Dec 16 '11 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.