47

Are there any practical benefits in using rsyncd compared to rsync over ssh? Does it really increase speed, stability, anything?

6 Answers 6

23

I think the big difference is that if you're using rsyncd on the server end, instead of rsync over ssh, the server already knows what it has, so building the file lists to determine what needs to be transferred is much simpler. It won't make a difference if you're just pushing around a few files, but if you're making, for example, CPAN available over rsync, you don't want to have to build the file list on the source side every time.

3
  • hostname::share
    – DustWolf
    Nov 18, 2020 at 20:54
  • 7
    I don’t understand this answer. How does rsynd know what it has? Does it crawl the file system regularly? Apr 19, 2021 at 7:47
  • if you check the rsync log it will tell you "building file list" every time an rsync client tries to pull from the remote (fyi my remote is a db that is always changing). it doesn't seem to do any kind of smart indexing
    – laertis
    Jul 6, 2023 at 13:35
25

This is an old question, but there is another very valid reason for using rsync in daemon mode versus over ssh:

  • Lower CPU overhead.

I have one 10 TB NAS that is backed up to another 10 TB NAS, and the encryption overhead for just the SSH tunnel is the limiting factor for the transfer. Both NASes are fairly low-powered 1.8 Ghz Intel Atoms, and even with easier crypto options for ssh (e.g. ssh -c arcfour passed as the ssh call to rsync), the encryption overhead still results in at best 200-300 Mbps, on a gigabit ethernet network.

Using a rsync daemon on one end removes the crypto overhead, and achieves >800 Mbps transfers for large, contiguous files.

5
  • 1
    Very helpful, thanks. I'm running a similar setup and was able to double the transfer speed I was getting from an ssh -c arcfour connection I'd been using. Feb 26, 2018 at 13:34
  • 1
    Not sure if removing the crypto 'overhead' can be considered an advantage.. It'd be best to use hardware accelerated crypto, which ARC4 is probably not really.
    – Lodewijk
    Oct 19, 2018 at 14:40
  • @Lodewijk - First, I'm on a private network at my house, so encryption isn't critical (and it's not super private data anyways). Additionally, either the rsync version in my distribution doesn't use hardware crypto, or the intel atom I'm using doesn't have hardware accelerators. I tried most of the crypto options for the SSH transport, and all of them were pretty much horribly slow.
    – Fake Name
    Oct 20, 2018 at 1:33
  • If there was a crypto option that didn't massively affect the performance, I'd use it, but I tried those options first with no luck.
    – Fake Name
    Oct 20, 2018 at 1:36
  • 2
    If you're connecting over ssh, you're not using the remote rsyncd. Looking at the [man pages], rsync [OPTION...] SRC... [USER@]HOST:DEST uses ssh, while rsync [OPTION...] SRC... [USER@]HOST::DEST uses the remote daemon. Note the extra colon: HOST:SRC vs HOST::SRC. You can also explicitly call out the transport: SRC... rsync://[USER@]HOST[:PORT]/DEST
    – Fake Name
    May 21, 2019 at 5:15
17

rsyncd (rsyncd with daemon) uses by default port 873.

This will use the native rsync protocol, but does not encrypt anything. It is meant only for local or trusted networks.

If you want security, always you have to use rsync or rsyncd over SSH, all your data transfers will be entrypted by the ssh protocol.

1
  • 10
    This. Should be the accepted answer! Rsyncd is totally insecure, I can't believe no one had mentionned it. May 2, 2019 at 2:41
11

I don't think comparing running rsyncd to rsync over SSH makes much sense. They are generally used for completely different things.

rsync over ssh is usually used for backups, or syncing servers over the internet. rsyncd is usually used for things like software mirrors, so it makes more sense to compare rsyncd to a plain HTTP or FTP mirror or even bittorrent.

There is also software like zsync, which allows you to get many of the benefits of rsync while still using a standard HTTP server

5

The function of rsyncd is to run on a server and respond to (remote) rsync requests.

(when we say rsyncd we mean rsync running as a daemon, and when we say 'remote', we mean remote from the point of view of the machine running rsyncd)

Both would use ssh in order to talk to each other securely.

It's not really a question of using one or the other, although if rsync is used to copy files and directories on the same machine, I don't think it needs to run as a daemon.

I think the rsync man page clarifies this.

-1
  1. if no other remote tools are available on local host, but rsync then using rsync in conjunction with rsync-daemon on the remote location is useful.

afaik, a distro might come with only scp and rsync and no other remote tools to transfer files...

  1. if the user is not familiar with using scp...

  2. if there are reasons to prefer unencrypted file tranfers .

1
  • i think you did not understand the question
    – djdomi
    Jul 20, 2021 at 14:22

You must log in to answer this question.

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