How to Use rsync: The Beginner's Guide (First Sync, the Trailing-Slash Rule, Backups, and the Never-Lose-Data Rule)

CodexFuse Team · 2026-10-31T03:57:27.257Z · 14 min read

Learn how to use rsync: run your first local sync, master the trailing-slash rule, sync files to a server over SSH, and build nightly cron backups that never lose data.

How to Use rsync: The Beginner's Guide (First Sync, the Trailing-Slash Rule, Backups, and the Never-Lose-Data Rule)

Learning how to use rsync is the moment file copying stops being a gamble. rsync is the standard Unix tool for syncing files and directories — locally or to a remote server over SSH — and its superpower is the delta-transfer algorithm: instead of recopying everything, it compares source and destination and sends only what changed. This rsync tutorial runs the whole beginner ladder in one sitting: check that rsync is installed, run your first local sync, master the trailing-slash rule that trips up every beginner, push files to a server over SSH, skip the files you never want synced, mirror safely with --delete, and finish with nightly cron backups that never lose data. One rule governs the entire guide: every destructive command gets a dry run first — the never-lose-data rule.

You will build in this order: verify your rsync version, sync a folder locally, learn the trailing-slash rule before touching a server, set up SSH keys, run your first remote sync, add excludes, preview a mirror with --dry-run, and schedule the whole thing with cron. Remote syncs ride over SSH, so if you still log in with a password, generate your keys with a free SSH key generator first — keys before rsync-over-SSH, in that order, and you will never be asked for a password mid-transfer again.

How do you use rsync? (The 30-second version)

Here is the complete beginner arc — six steps, from zero to safe nightly backups:

1. Check it is installed: run rsync --version. Most Linux systems ship it; macOS and Windows need a quick install (details below).
2. First local sync: rsync -av ~/photos/ /backup/photos/ — copies a folder and everything in it, preserving permissions and timestamps.
3. Learn the trailing-slash rule: photos/ copies the contents; photos copies the folder itself. Get this wrong once and you will never forget it.
4. First remote sync: rsync -avz ~/site/ deploy@server:/var/www/site/ — the same command, pointed at a server over SSH.
5. Dry-run before destruction: add --dry-run to any command with --delete and read what it would do.
6. Automate: put the tested command in cron and you have nightly backups. The rest of this guide fills in each step.

What is rsync, and why is it better than scp or FTP?

rsync is a file-synchronization tool, not a file copier — and that one-word difference is everything. Where cp and scp blindly copy every byte every time, rsync compares the source and destination first (file size and modification time, by default) and transfers only the differences, using its famous delta-transfer algorithm for files that exist on both sides. Sync a 10 GB project folder after changing one file, and rsync moves that one file — scp resends all 10 GB.

The second reason rsync wins in 2026: the legacy SCP protocol is deprecated. OpenSSH 9.0 (released April 2022) switched the scp command to use the SFTP protocol internally, and the old scp/rcp protocol is no longer maintained — the tool survives for one-off copies, but its future is maintenance mode. The OpenSSH team and every modern guide point the same direction: for anything repeated, use rsync. FTP is worse still — it sends credentials and files in clear text.

How the common tools compare:

Rule of thumb from the guides ranking for this topic: copy once, use scp; copy the same files repeatedly, use rsync; copy within one machine, use cp. Everything in this guide assumes the repeated case — which is almost every real workflow.

Is rsync already installed? How do you check?

Run rsync --version — if it prints a version, you are ready. Most Linux distributions ship rsync out of the box; if yours does not, sudo apt install rsync (Debian/Ubuntu) or sudo dnf install rsync (Fedora) fixes it in seconds, and macOS users should brew install rsync because the copy Apple bundles is years out of date.

Two version facts worth knowing, verified at write time: rsync 3.5.1 is the current stable release (September 21, 2026, per rsync.samba.org), and its predecessor 3.5.0 fixed 33 security issues found during a focused audit of rsync's path handling and daemon protocol. If your rsync --version shows anything below 3.4.0, update before you rely on it for anything important.

One prerequisite the man page states plainly: for remote transfers, rsync must be installed on both the source and destination machines — the two ends run a matching rsync process that talks over SSH. If a sync to a server fails mysteriously, a missing rsync on the server is the first thing to check.

What does your first rsync command look like?

Your first command copies one folder to another on the same machine: rsync -av ~/photos/ /backup/photos/. The -a flag is archive mode — recurse into subdirectories and preserve permissions, timestamps, ownership, and symlinks — and -v is verbose, so you watch each file go by instead of staring at a silent cursor.

Try it with a scratch folder first so the stakes are zero:

mkdir -p ~/rsync-test/photos ~/rsync-test/backup
echo "first photo" > ~/rsync-test/photos/img1.txt
rsync -av ~/rsync-test/photos/ ~/rsync-test/backup/

You will see rsync list each file it sends, then a summary line with bytes sent and received. Run the exact same command again immediately: this time almost nothing transfers, because rsync's quick check (size plus modification time) sees nothing changed. That second silent run is the delta magic — and it is why nightly backups take seconds instead of hours.

What does the trailing slash actually change?

The trailing slash decides whether rsync copies the contents of a folder or the folder itself — and getting it backwards is the single most common rsync mistake. photos/ (with slash) means "the stuff inside photos"; photos (no slash) means "the photos folder, as a folder".

Here is the exact result of each form, the load-bearing table of this guide:

Memorize it this way: the slash says "open the folder first, then copy what is inside." The official man page phrases it as "copy the contents of this directory" versus "copy the directory by name" — same rule, and it applies identically to remote syncs, which is why you learn it locally before a server is ever involved.

How do you sync files to a remote server over SSH?

You use the exact same command, with the destination rewritten as user@host:path: rsync -avz ~/site/ [email protected]:/var/www/site/. The -z adds compression for the network trip, and rsync opens an SSH connection by default — no daemon to configure, no extra ports, just the SSH access you already have.

Pushing to a server (local → remote) is a deploy; pulling from a server (remote → local) is a download or a backup. The direction is whichever side you list first, so read every command left to right: source first, destination second. Before your first remote sync, know what kind of machine you are pushing to — if the concept is new, our what is VPS hosting guide covers the server side of this exact workflow.

Two remote essentials: if your server listens on a non-standard SSH port, add -e "ssh -p 2222"; and always test a remote sync against a scratch directory first, because the trailing-slash rule plus a wrong path is how deploys land in the wrong folder. SSH keys (set up in the intro) keep this password-free — without them, every sync stops to ask for your password.

What do the -a, -v, and -z flags actually do?

-a is archive mode, and the man page defines it exactly: it equals -rlptgoD — recurse into directories, copy symlinks as symlinks, preserve permissions, times, group, owner, and device files. What trips up experienced users is what it does not include: no -H (hard links), no -A (ACLs), no -X (extended attributes) — the man page writes it as "-rlptgoD (no -H,-A,-X)".

If your workflow needs those — say, a backup that must keep file ACLs — add them explicitly: rsync -aAX. Most beginners never need them, but now you will not be surprised when an "archive" copy drops an ACL you expected to keep.

-v is verbose: it lists every file transferred, which is how you learn what rsync is doing. -z compresses data during transfer — a clear win on slow connections, a waste of CPU on a gigabit LAN or for already-compressed files like videos and zip archives. The canonical beginner command, rsync -avz, is the right default for remote syncs; drop the z for local ones.

How do you skip the files you never want synced?

You exclude them with --exclude patterns: rsync -avz --exclude='node_modules' --exclude='.git/' --exclude='*.log' ~/project/ deploy@server:/var/www/project/. Every developer deploy needs this — syncing node_modules wastes minutes and syncing .env leaks secrets, so excludes are a security habit as much as a speed habit.

When the list grows, move it into a file and use --exclude-from:

# deploy-excludes.txt
node_modules/
.git/
.env
*.log
storage/logs/

rsync -avz --exclude-from='deploy-excludes.txt' ~/project/ deploy@server:/var/www/project/

One caution from the man page: a pattern like dir/ matches a directory and everything under it, while dir matches files or directories with that name — the slash matters in excludes too. If your project runs in containers, pair this with our Docker beginner guide: exclude the volumes you back up separately, and never rsync a live database's data directory without stopping it first.

How does --delete work, and what is the never-lose-data rule?

By default rsync only adds and updates — files you deleted from the source linger at the destination forever. --delete makes the destination an exact mirror: anything missing from the source gets removed from the destination. That is what turns a sync into true mirroring, and it is also the most dangerous flag in this guide.

The never-lose-data rule has two parts, and they are non-negotiable: first, every command containing --delete gets --dry-run first, so you read exactly what would be deleted before anything happens; second, you verify the direction — source on the left, destination on the right — because --delete pointed the wrong way deletes the files you meant to keep. The working pattern:

# 1. Preview: read every "deleting" line carefully
rsync -avz --delete --dry-run ~/site/ deploy@server:/var/www/site/

# 2. Only when the preview is exactly right, run it for real
rsync -avz --delete ~/site/ deploy@server:/var/www/site/

The dry run ends its summary with "(DRY RUN)" so there is no ambiguity about whether anything changed. Guides written from live testing all say the same thing: this one habit has caught more disasters than any other rsync skill. Make it muscle memory before you automate anything.

How do you turn rsync into nightly backups with cron?

You schedule a tested command with cron and give each night its own dated folder, using --link-dest so unchanged files are hard-linked instead of recopied: 0 2 * * * rsync -a --delete --link-dest=/backup/latest /home/you/ /backup/$(date +\%Y-\%m-\%d)/ runs at 2 AM, and every backup looks like a full copy while costing disk space only for changed files. That is the professional incremental-backup pattern in one line.

The --link-dest trick deserves a plain explanation: rsync compares each file against yesterday's backup, and anything identical becomes a hard link to yesterday's copy — same file, two directory entries, one copy on disk. The first backup copies everything; the tenth costs almost nothing. Log the output (>> /var/log/rsync-backup.log 2>&1) so a silent cron failure does not go unnoticed for a month.

One honest boundary: a sync is not quite a backup. rsync mirrors the present; with --delete and one destination folder, yesterday's files are gone. The dated-folder pattern above fixes that by keeping history — and for code, remember that rsync moves files while version control remembers why they changed, so pair this with our Git beginner guide rather than treating sync as a substitute for commits.

What are the beginner mistakes that lose data?

Every mistake below is one real beginners make in their first month — and each has a one-line fix:

Sources

Every fact in this guide was verified against a source fetched at write time (October 31, 2026): the rsync(1) man page via linux.die.net (-a equals -rlptgoD with no -H,-A,-X; trailing-slash semantics; delta-transfer algorithm; rsync required on both ends; SSH as default transport); rsync.samba.org, the official project site (rsync 3.5.1 stable, September 21, 2026; 3.5.0 fixed 33 security issues); the Wikipedia rsync article (stable release 3.5.1, September 21, 2026; original authors Andrew Tridgell and Paul Mackerras, 1996); the FOSS Linux rsync beginner's guide, updated October 2026 (--link-dest incremental backup pattern with hard links; -P equals --partial --progress for resumable transfers; quick-check compares size and modification time); the SUSE Linux Enterprise Server documentation, published October 29, 2026 (rsync on both systems with SSH connectivity for remote transfers; archive mode definition); the dev.to SFTP-vs-SCP-vs-rsync comparison (OpenSSH 9.0, April 2022, switched scp to SFTP internals; legacy SCP protocol deprecated); the dev.to rsync-for-developers guide (trailing-slash rule with examples); the Servebolt rsync how-to (trailing-slash behavior); and the Web Coding Center SSH file-transfer guide, updated October 2026 (scp speaking SFTP underneath since OpenSSH 9.0; trailing-slash and exclude-file examples).

Frequently asked questions

Is rsync installed by default on Linux and macOS?

Almost every Linux distribution ships rsync, and rsync --version tells you in one second. macOS includes a copy, but it is years out of date — install the current release with brew install rsync. On Windows, run rsync inside WSL2, or use one of the native Windows builds (version 3.5.1 builds exist as of this writing) if you prefer no Linux layer.

Does rsync overwrite newer files at the destination?

Not in the way you fear: rsync's quick check skips files whose size and modification time already match, and it will happily update a destination file that is older. If you want to protect newer destination files, add --update (-u), which skips any file that is newer on the receiving side. For a deeper comparison than size-plus-time, --checksum compares content hashes at the cost of more disk I/O.

Can rsync resume an interrupted transfer?

Yes — add -P, which combines --partial (keep partially transferred files) with --progress (show a progress bar). If a 20 GB transfer dies at 80 percent, the next run picks up near where it stopped instead of starting over. This alone is reason enough to prefer rsync over scp for large files.

What is the difference between rsync and scp?

scp copies whole files every time and cannot resume or sync deletions; rsync transfers only differences, resumes with -P, and mirrors with --delete. Since OpenSSH 9.0 (April 2022), the scp command uses the SFTP protocol internally and the legacy SCP protocol is deprecated — fine for one-off copies, but for anything you run twice, rsync wins on speed and features.

Does rsync work on Windows?

Yes, three ways: Windows Subsystem for Linux (WSL2) gives you the real Linux rsync; MSYS2 and Git Bash ship rsync builds familiar to developers; and native Windows builds of rsync 3.5.1 are available as single executables that work with Windows OpenSSH. Pick WSL2 if you want the exact commands in this guide to work unchanged.