Skip to content

rsync — Trivia & Interesting Facts

Surprising, historical, and little-known facts about rsync.


rsync was created as a PhD thesis project in 1996

Andrew Tridgell (also the creator of Samba) developed the rsync algorithm as part of his PhD research at the Australian National University. His 1999 thesis, "Efficient Algorithms for Sorting and Synchronization," formally described the rolling checksum algorithm that makes rsync fast. The algorithm was so effective it became the standard for file synchronization across the industry.


The rsync algorithm only transfers the differences between files

rsync splits the destination file into fixed-size blocks, computes checksums for each block, and sends these checksums to the source. The source then scans its version using a rolling checksum (Adler-32 variant) to find matching blocks. Only the non-matching data is transmitted. For a 1 GB file with a 1 MB change, rsync transfers roughly 1 MB instead of 1 GB.


The trailing slash on the source path changes everything

rsync -a /src/ /dest/ copies the contents of /src into /dest. rsync -a /src /dest/ copies the directory /src itself into /dest, creating /dest/src/. This single-character difference has caused countless accidental file placements and is arguably rsync's most notorious footgun. No amount of documentation seems to prevent this mistake.


rsync --dry-run has prevented thousands of disasters

The -n (or --dry-run) flag shows what rsync would do without actually making changes. Combined with -v (verbose) or --itemize-changes, it provides a complete preview of every file that would be transferred, deleted, or modified. Experienced sysadmins never run rsync with --delete without a dry run first.


rsync over SSH became the default in 2004

Early rsync used its own daemon protocol (rsyncd) on port 873, which transmitted data unencrypted. rsync 2.6.0 (2004) made SSH the default transport, providing encryption and authentication without any additional configuration. The old daemon mode still exists for high-performance scenarios where encryption overhead is unacceptable, like local network backups.


The --delete flag is both essential and dangerous

Without --delete, rsync only adds and updates files — it never removes files from the destination that no longer exist in the source. With --delete, the destination becomes an exact mirror. This flag has caused data loss when users accidentally swap source and destination arguments, effectively "syncing" an empty directory and deleting everything.


rsync can resume interrupted transfers with --partial

The --partial flag tells rsync to keep partially transferred files rather than deleting them. On the next run, rsync resumes where it left off. The --partial-dir variant stashes partial files in a hidden directory to avoid exposing incomplete files. The -P shortcut combines --partial with --progress and is the most commonly used rsync convenience flag.


By default, rsync does not preserve hard links — each hard link is transferred as an independent file, potentially doubling storage usage. The -H flag enables hard link preservation, but it requires rsync to keep a map of all inodes in memory, which can consume significant RAM on filesystems with millions of hard links.


Time Machine on macOS was inspired by rsync-like incremental backups

Apple's Time Machine uses hard-link-based incremental backups similar to rsync's --link-dest approach. The --link-dest flag tells rsync to hard-link unchanged files to a previous backup directory instead of copying them, creating space-efficient snapshots. A backup of 100 GB with 1 GB of changes uses only 1 GB of additional disk space.


rsync's --checksum mode is slower but catches rare bit-rot errors

By default, rsync uses file size and modification time to decide whether to transfer a file. The --checksum flag forces rsync to compute and compare checksums for every file, catching cases where file contents changed but the timestamp and size did not (bit-rot, silent data corruption). This mode is significantly slower because it must read every file completely on both sides.