While both methods achieve file synchronization, their architectures differ fundamentally:

# SSH method (encrypted tunnel)
rsync -avz -e ssh /local/path/ user@remote:/remote/path/

# Daemon mode (direct TCP connection)
rsync -avz /local/path/ rsync://remote/module/path

In our load tests transferring 50GB of mixed files (10,000 files ranging 1KB-2GB):

A production-grade rsyncd.conf example:

[backup]
path = /mnt/array1
comment = Primary backup storage
uid = backup
gid = backup
read only = false
hosts allow = 192.168.1.0/24
max connections = 25
lock file = /var/run/rsync.lock
log file = /var/log/rsyncd.log
timeout = 300
[data_export]
path = /srv/export
list = false
auth users = syncuser
secrets file = /etc/rsyncd.secrets

SSH remains superior for:

• Ad-hoc transfers between untrusted networks
• Environments where only SSH access is available
• Small transfers where encryption overhead is negligible

For maximum throughput with rsyncd:

# Network tuning
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

# Rsync flags for large transfers
rsync --bwlimit=100000 --whole-file --numeric-ids \
      --no-compress --size-only --progress \
      /massive_data/ rsync://target/module/

Essential hardening practices:

# IPTables rules for rsyncd
iptables -A INPUT -p tcp --dport 873 -s trusted_ip -j ACCEPT
iptables -A INPUT -p tcp --dport 873 -j DROP

# Chroot example in rsyncd.conf
[secure_zone]
path = /chroot/backup
use chroot = yes

When comparing rsyncd to SSH-based transfers, we're essentially comparing a dedicated daemon protocol versus tunneling through encryption. The rsync daemon operates on TCP port 873 by default and uses its own optimized protocol, while SSH-rsync wraps the transfer in SSH encryption (typically port 22).

# SSH-based rsync example
rsync -avz -e ssh /local/path user@remote:/remote/path

# Rsync daemon example
rsync -avz /local/path rsync://remote/module/path

In controlled tests transferring 50GB of mixed files (10,000 files ranging from 1KB to 2GB):

Key findings show rsyncd is 30-40% faster for large transfers, with significantly lower resource consumption. The gap widens with more small files.

The rsync daemon particularly excels in:

• Internal networks where encryption overhead isn't critical
• Automated backup systems running frequent transfers
• High-volume mirroring operations (like package repositories)
• Systems with limited CPU resources (embedded devices, older servers)

A production-grade rsyncd configuration might look like:

# /etc/rsyncd.conf
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log

[backup]
    path = /mnt/backups
    comment = Primary backup target
    uid = backup
    gid = backup
    read only = false
    list = yes
    hosts allow = 192.168.1.0/24
    max connections = 10
    timeout = 300

While rsyncd supports authentication via secrets file, it lacks SSH's cryptographic guarantees:

# Generate credentials file
echo "backupuser:password123" > /etc/rsyncd.secrets
chmod 600 /etc/rsyncd.secrets

# Corresponding config addition
auth users = backupuser
secrets file = /etc/rsyncd.secrets

For sensitive data, consider combining both - use rsyncd for initial bulk transfer within VPN, then SSH-rsync for final sync with encryption.

Frequent issues and their solutions:

1. Connection refused: Verify rsync --daemon is running and firewall allows port 873
2. Permission denied: Check module path permissions and uid/gid settings
3. Slow transfers: Try --compress-level=1 or disable with --no-compress for fast networks

Choose rsyncd when:

• Transfer speed is critical
• You control the network environment
• Dealing with large datasets

Stick with SSH when:

• Transferring over untrusted networks
• Security requirements mandate strong encryption
• You need centralized authentication (SSH keys)