Rsync's architecture fundamentally prevents direct synchronization between two remote servers due to its client-server model. The error message:

The source and destination cannot both be remote. rsync error: syntax or usage error (code 1) at main.c(1156) [Receiver=3.0.7]

stems from rsync's design where one endpoint must always be local to initiate and manage the connection.

The primary technical challenges include:

• Connection handshaking requires a local process
• Delta calculation needs a local reference point
• Bandwidth management becomes complex with dual remotes
• Authentication would require credential forwarding (security risk)

Here are three tested approaches:

1. Local Bridge Method

Use your local machine as intermediary:

rsync -avz user@remote1:/source/ /local/temp/
rsync -avz /local/temp/ user@remote2:/destination/

2. SSH Tunnel Approach

Create a direct tunnel between remotes:

ssh user@remote1 "rsync -avz -e 'ssh -A user@remote2 ssh' /source/ remote2:/destination/"

3. Third-Server Solution

Execute from a third server with access to both:

ssh jumpbox "rsync -avz user@remote1:/source/ user@remote2:/destination/"

For complex scenarios:

• Use rclone with its multi-cloud capabilities
• Implement lftp mirroring between servers
• Set up sshfs mounts and use local rsync

When transferring large datasets:

# Use these flags for better performance
rsync -avz --partial --progress --rsh="ssh -T -c aes128-ctr -o Compression=no -x" source/ dest/

---

Rsync's architecture fundamentally assumes a local-to-remote or remote-to-local transfer model. When attempting commands like:

rsync user@remote1:/source user@remote2:/destination

The protocol throws error code 1 because:

1. Rsync expects one endpoint to be local for buffer management
2. Authentication handshakes aren't designed for dual remote negotiation
3. The delta-transfer algorithm requires local file comparison

The primary obstacles include:

• Connection chaining: Rsync establishes exactly one SSH tunnel per transfer
• Checksum comparison: Requires local access to at least one filesystem for block-level diffs
• Memory buffers: Not implemented for intermediary data storage between remotes

Here are three proven approaches:

1. Local Proxy Method

Use the local machine as transfer mediator:

rsync -avz user@remote1:/source /local/tmp
rsync -avz /local/tmp user@remote2:/destination

2. SSH Tunneling

Create a direct tunnel between remotes:

ssh user@remote1 "rsync -avz /source user@remote2:/destination"

3. Using netcat

For high-speed transfers without encryption:

# On remote2:
nc -l 12345 | tar xv

# On remote1:
tar c /source | nc remote2 12345

For native dual-remote transfers consider:

• rclone with its --transfer flag
• bbcp (point-to-point transfer tool)
• fpart + parallel-rsync for partitioned transfers

Method	Speed	Encryption	Resource Usage
Local Proxy	Medium	Yes	High (2x transfer)
SSH Tunneling	Fast	Yes	Low
Netcat	Fastest	No	Lowest

Remember that disk I/O often becomes the bottleneck when using local proxies - ensure your temp directory has sufficient space and fast storage.