Learn Rsync - Core Concepts & Main Architecture

#Introduction

After understanding the history and why rsync exists in episode 1, now we dissect how it works. Episode 2 is the architectural foundation: transfer modes, the components involved, and the delta algorithm behind the scenes. You'll refer back to this mental map often in the coming episodes.

Why does architecture matter? Because many configuration mistakes — like choosing SSH when you wanted the daemon, or exposing port 873 without realizing it — stem from not understanding the two layers we'll cover: transport and operating mode.

#Two Main Modes: Local vs Remote

Rsync has two broad modes:

• Local mode — both sides (source and destination) are on the same machine. Rsync needs only a single process; it reads the source files and writes directly to the destination via the filesystem.
• Remote mode — one or both sides are on another machine. This is where transport is needed: rsync runs as a client process on one side and a server process on the other, exchanging data over the network.

An analogy: local mode is like moving boxes between shelves in one warehouse; remote mode is like moving boxes from one warehouse to another using a truck.

rsync -avh /src/ /dest/                    # local: one machine
rsync -avh /src/ user@host:/dest/          # remote: SSH shell
rsync -avh rsync://host/module/ /dest/     # remote: daemon

#Remote Mode: SSH vs Daemon

Remote mode has two fundamentally different transports:

The SSH transport is the default and safest choice because it's automatically encrypted. The daemon transport is used when you want to share a "module" with many clients — like a public mirror — or when you don't want to give users shell access.

#The rsyncd Daemon and Port 873

Daemon mode runs as the rsyncd service listening on port 873/tcp. Clients connect using the rsync://host/module-name syntax. In this model, one server can expose many modules, each with its own path and permissions.

rsync -avh rsync://mirror.host/ubuntu/ /srv/mirror/

The example above is the typical public mirror pattern: a daemon exposes the ubuntu module to be pulled by thousands of unauthenticated clients. This module configuration is managed in /etc/rsyncd.conf — we'll build a complete example in episode 4.

#Main Components

Rsync's architecture consists of four core components:

• The rsync binary — a single program with a dual role: client on the source machine and server on the destination machine. When invoked with --server, it works as an internal server speaking the rsync protocol.
• The rsyncd daemon — a standalone service (usually via inetd or systemd) that serves module-based remote requests on port 873.
• /etc/rsyncd.conf — the daemon configuration file: a global section and [module] blocks that define paths, permissions, and authentication.
• The delta algorithm — the transfer core: splits files into blocks, computes checksums, and only sends the blocks that changed.

#Rolling Checksum and Hash Behind the Scenes

The most interesting part is the delta-transfer algorithm, which works in three stages:

1. Block splitting — the receiver splits the destination file into fixed-size blocks (from 700 bytes for small files up to tens of KB for large files). Block size is dynamic so checksum overhead stays balanced.
2. Rolling checksum (weak checksum) — for each block, a low-cost checksum is computed that is rolling: it can be advanced one byte at a time without recomputing the entire block. This lets the sender "slide" a window across all its data cheaply to look for matches.
3. Hash (strong checksum) — every block candidate that matches on the weak checksum is confirmed with a strong checksum (historically MD5, and the much faster xxHash64 in modern rsync). This double confirmation prevents checksum collisions.

The result is an efficient negotiation: the sender knows exactly which bytes already exist at the receiver and only sends the truly new bytes. That's why rsync can sync a 10 GB file with just a few MB of transfer.

#A Simple Transfer Flow

To tie it all together, here's the flow when you run rsync -avh src/ dest/:

1. Rsync compares each file's metadata (size, mtime) to filter out files that are already identical.
2. For files that differ, both sides build a block-and-checksum negotiation.
3. The data that actually changed is sent and written to a temporary file.
4. The temporary file is renamed to its final name only if the transfer succeeds — that's what makes rsync atomic per file and safe against interrupted connections.

This sequence is what preserves consistency: you'll never see a half-written file under its real name at the destination.

#Closing

In this episode you've mapped rsync's architecture: two modes (local/remote), two remote transports (SSH/daemon), four core components, and the delta algorithm with rolling checksum + hash.

Key takeaways:

• Local mode is one machine; remote mode goes over SSH (port 22) or the daemon (port 873).
• rsyncd exposes modules via /etc/rsyncd.conf; port 873 is not encrypted.
• Components: the rsync binary, the rsyncd daemon, the /etc/rsyncd.conf config, and the delta algorithm.
• Delta-transfer = blocks + rolling checksum + strong hash; only changed blocks are sent.
• Files are written to a temp file and then renamed — each per-file transfer is atomic.

In episode 3 we start real practice: basic syntax and local mode — rsync [OPTIONS] SRC DEST, the example rsync -avh /data/ /backup/, and the crucial difference between a trailing slash in src/ vs src. See you in episode 3!