Explain what a trailing slash on an rsync SOURCE path changes, using `rsync -a /var/www /backup/` versus `rsync -a /var/www/ /backup/`, and why getting it wrong is dangerous once `--delete` is added.

## The rule, in one line rsync gives the **source** argument one special piece of syntax: a trailing `/` (or the equivalent `/.`) means *the contents of this directory*. Without the trailing slash, the argument means *this directory as an object*, and rsync recreates it by name underneath the destination. Nothing else about the command changes — same flags, same transport, same algorithm. One character decides the shape of the result. ## Worked example Assume `/var/www` contains `index.html` and `assets/`. ``` rsync -a /var/www /backup/ -> /backup/www/index.html /backup/www/assets/ rsync -a /var/www/ /backup/ -> /backup/index.html /backup/assets/ ``` The second form is what people usually mean when they say "mirror this directory to that one". The first form is what they usually type. ## The destination slash does not matter `/backup`, `/backup/` and `/backup/.` behave identically here. When the source is a directory, rsync treats the destination as a directory and creates it if the final component is missing (only the last component — rsync 3.2.3 added `--mkpath` for creating the whole path). Interviewers ask about the destination slash specifically to see whether you have internalised the rule or just memorised "put a slash on both". A good habit for the safe form is `rsync -a /var/www/. /backup/` — the explicit `.` is harder to lose to a shell completion or a copy-paste than a bare slash, and it means the same thing. ## What `--delete` compares `--delete` tells rsync to remove files in the destination that do not exist in the transferred source tree. It only applies to directories rsync is actually recursing into, so it needs `-r`/`-a` (or `-d`) to do anything, and it only judges the parts of the tree the transfer covers — a `--exclude`d path is *not* automatically deleted (that is what `--delete-excluded` is for). Now combine the two rules. You intended: ``` rsync -a --delete /var/www/ /backup/ # /backup becomes a copy of /var/www ``` and you typed: ``` rsync -a --delete /var/www /backup/ # /backup becomes a directory containing only www/ ``` In the second command the transferred source tree, as seen from the destination root, contains exactly one entry: `www`. Every other file in `/backup` — including the previous night's backups of other trees — is extraneous, so rsync deletes it. The destination is not corrupted or half-written; it is exactly what you asked for, which is why the mistake is so easy to make and so expensive. ## Making the mistake impossible - **Dry-run first, always, for anything with `--delete`.** `-n` (`--dry-run`) plus `-i` (`--itemize-changes`) prints one line per action, with `*deleting` lines for removals, and changes nothing. Read those lines; if you see deletions you did not expect, the slash is the first thing to check. - **Bound the blast radius** with `--max-delete=N`: rsync stops deleting once it hits the limit and exits with a non-zero status, so a mirror job that suddenly wants to remove ten thousand files fails loudly instead of succeeding destructively. - **Pin the source in a variable and write the slash once**, so the scheduled job cannot drift from the version you tested. - **Keep the destination recoverable.** A `--link-dest` snapshot chain, filesystem snapshots or object-store versioning means even a correct-but-unwanted deletion is undoable. A mirror is not a backup precisely because it faithfully replicates deletions. ## Two related traps in the same family The slash rule also applies to remote sources: `rsync -a host:/srv/data/ /local/` and `rsync -a host:/srv/data /local/` differ in exactly the same way, and the remote-side path is expanded by a shell on that host, so wildcards behave differently again. And `--delete` has one built-in safety you should know about: if rsync cannot read the source directory because of an I/O error, it aborts rather than treating the tree as empty (unless you pass `--ignore-errors`). That protection does **not** cover the common operational version of the accident — a backup source that is an *empty but successfully readable* mount point because the filesystem failed to mount. Then the source really is empty, rsync does what it was told, and `--delete` empties the destination. Guard the job by checking for a sentinel file in the source before you run it.