Learn Rsync - Testing & Dry-run Workflow
Building a safe workflow before executing rsync on important data: dry-run with -n, itemize with -i to see the exact change per file, content validation with --checksum (-c), and --ignore-times when you doubt the timestamps.
#Introduction
You already have a complete arsenal: filters, snapshots, cron, and security. There's one habit that separates a capable engineer from a careless one — verifying before executing and verifying after finishing. Episode 16 closes that gap with dry-run, itemize, and checksum.
Why is this episode important? Because an rsync command that looks correct can go badly wrong in real conditions: a misdirected source, a wrong filter pattern, or misleading timestamps. The workflow in this episode is the safety net that catches those mistakes before data is damaged.
#Dry-run: -n
-n (or --dry-run) runs the entire rsync process — file listing, comparison, filters — without actually writing anything:
rsync -avhn --delete src/ dest/The output is the same as a real transfer, only no files are touched. This is the first command you should run for every rsync touching important data — especially ones using --delete.
Tip
In scripts, add -n as the default and use a variable to enable real execution — e.g. DRY="-n"; [ "$EXEC" = "1" ] && DRY="". That way the script is safe to run accidentally, and real execution only happens when an explicit flag is given.
#Itemize: -i
-i (--itemize-changes) makes dry-run far more informative: each output line explains the specific change per file:
rsync -avhn -i src/ dest/>f+++++++++ src/new-file.txt
>f.st...... src/changed-file.txt
.d..t...... src/dir/
cd+++++++++ src/deleted-file.txtEach line has meaning: the first character is the change type (> = sent, c = deleted), followed by 9 attribute status characters. We'll read the format below.
#Reading the Itemize Format
The itemize status columns:
| Position | Meaning |
|---|---|
| 1 | Change type: > update, c create/delete, * non-regular |
| 2 | f file, d directory, L symlink, D device |
| 3-9 | Status: . unchanged, s size, t timestamp, p permissions, o owner, g group, c checksum, x xattr |
| 10 | Detail type |
Example: >f.st...... means a file (f) is sent (>) because the size (s) and timestamp (t) changed — content wasn't checked. >f.c....... means content was compared via checksum and changed. The line cd+++++++++ marks a file deleted at the destination because it doesn't exist at the source. Practice reading this format with rsync -n -i on a directory you deliberately modified — you'll get used to it quickly.
Note
Only with -i can you see the reason a file gets transferred: whether because the content changed (c), or only the timestamp (t). This difference matters — see the --ignore-times section below.
#--checksum (-c): Content Validation
By default rsync compares size + timestamp to decide whether a file changed. That's fast, but it can lie: files with the same timestamp but different content (e.g. the result of a restore that brought back old timestamps) will be skipped.
-c (--checksum) forces a content comparison:
rsync -avhc -i src/ dest/Now every same-sized file still gets its checksum computed, and content differences are detected even with identical timestamps. The cost: reading every file for checksums is slower. -c is a validation tool — most appropriate when you doubt consistency, not for routine daily backups.
#--ignore-times: When in Doubt
Sometimes the problem is the opposite: files must be moved even if metadata is identical — for example, when you don't trust the source timestamps (a system that once had the wrong clock), or you want to guarantee content is truly synchronized.
rsync -avh --ignore-times src/ dest/--ignore-times makes rsync treat every file as "possibly changed" — transfers are processed in full, though delta-transfer still saves data. It's heavier than -c in terms of work, but very useful for a one-time verification after a restore or migration.
Warning
A commonly misunderstood combination: --ignore-times without --size-only means all files get processed. Don't unconsciously pair it with --delete when you only want to "make sure the content is the same" — inspect the itemize output first.
#The Safe Workflow
The set of habits you should internalize:
# 1. Dry-run + itemize: see what would happen
rsync -avhn -i --delete src/ dest/
# 2. Review the output: any surprises?
# 3. Execute, then verify
rsync -avh --delete src/ dest/
rsync -avhn -i -c --ignore-times src/ dest/The second command in step 3 uses -c + --ignore-times to confirm all files are identical — if the output is clean (no changes), the sync is proven correct. This is the "dry-run → review → exec → verify" pattern you can apply to every production rsync operation.
#Closing
In this episode you've built a safe verification workflow.
Key takeaways:
-n(dry-run) shows the plan without touching files — always run it for important operations.-i(itemize) reveals the reason for each file change.-ccompares content via checksum — validation that timestamps can't fool.--ignore-timesforces processing of all files when you doubt metadata.- The 3-step workflow: dry-run → review → exec, then re-verify with
-c.
In episode 17 we dissect the version you're using: Rsync 3.4.x & latest features — the major security hardening, the --safe-links fix, the internal argument parser overhaul, and how to verify your version and ensure your distro backports fixes. See you in episode 17!