You are hardening a nightly `rsync -a --delete` mirror to a remote host over SSH: it is regularly killed part-way through, it saturates the uplink, and once it emptied the destination. Which rsync options make the job resumable, bounded and safe to interrupt?

## Separate the failure modes The job has three distinct defects and they need three distinct fixes. Answering "add `-P`" to all of them is the weak answer. ## 1. It restarts from scratch after being killed By default rsync writes each file to a temporary in the destination directory and renames it on completion; if the run dies, that temporary is deleted and the next run starts the file over. For a mirror containing multi-gigabyte files on a link that cannot finish one in a night, the job never converges. - **`--partial`** keeps the partial file so the next run can use it as a starting point. - **`--partial-dir=DIR`** is the better production form: partial data goes into a named directory (relative paths are per-destination-directory, e.g. `--partial-dir=.rsync-partial`) instead of sitting in the live tree under the real filename. Nothing downstream ever sees a truncated file wearing the correct name. It also implies `--partial`. - **`-P`** equals `--partial --progress` and is for humans at a terminal; in a scheduled job use `--partial-dir` and `--info=progress2` if you want a single summary progress line in the log. - `--append-verify` is *not* a general resume option: it assumes the destination is a prefix of the source and verifies only that prefix. Right for append-only logs, wrong and quietly destructive for files that are rewritten. ## 2. It saturates the uplink and can hang - **`--bwlimit=RATE`** caps the transfer rate (`--bwlimit=20M`). Cruder than proper traffic shaping, but it is one flag and it works. - **`--timeout=SECONDS`** aborts if no data moves for that long, which converts a wedged run into a failed run you can alert on. **`--contimeout=SECONDS`** bounds the initial connection separately. - `-z` is worth a thought rather than a reflex: on already-compressed data it costs CPU on both ends for nothing. `--skip-compress=` excludes suffixes, `--compress-choice=` picks the algorithm. - Since the transport is SSH, `-e 'ssh -p 2222'` is how you pass a non-default port or other client options through to the connection. ## 3. It once emptied the destination This is the serious one, and rsync's own protections only cover part of it. - **`--max-delete=N`** is the circuit breaker. rsync stops deleting once N removals are reached and exits with a non-zero status, so an anomalous run fails loudly instead of succeeding destructively. Set it from the tree's real churn — a mirror that normally removes a few dozen files a night has no business removing ten thousand. - **Deletion timing.** With `--delete`, rsync 3.x prunes during the transfer by default (`--delete-during`). `--delete-after` moves all removals to the end, so an interrupted run has added the new content but not yet removed the old — a strictly safer intermediate state for a mirror something else is reading. `--delete-before` is the old behaviour and is the worst choice here: it empties first and requires building the whole file list up front rather than incrementally. Note the cost of `--delete-after`: it needs the full list too, so it gives up incremental recursion's earlier start and lower memory on very large trees. - **`--delay-updates`** puts every updated file in a holding area and renames them all at the end, so the destination flips much closer to atomically. It costs temporary space equal to the changed data. - **The unmounted-source trap.** rsync will abort rather than delete everything if it hits an I/O error reading the source (that is what `--ignore-errors` overrides — never set it on a `--delete` job). But a backup source whose filesystem failed to mount is usually an *empty, perfectly readable* directory, which is not an error. rsync then does exactly what it was told and `--delete` empties the mirror. The guard cannot come from rsync: the wrapper must verify a sentinel file exists in the source, or that `mountpoint -q` succeeds, before invoking it. - **Keep history.** `--link-dest=DIR` builds the new tree with hard links to an unchanged previous snapshot, so each night costs only the changed data yet every night is a complete browsable tree. A mirror alone replicates mistakes; a snapshot chain lets you walk back to the night before. ## 4. Make the run auditable - `-n -i` (`--dry-run --itemize-changes`) before any change to the command, read in full. - `--stats` in the log so you can see literal versus matched bytes and the file counts over time. - **Check the exit status.** rsync's exit codes are meaningful — notably 23 and 24 for partial transfers, and 25 for hitting `--max-delete` — and a job whose wrapper ignores the status has no safety at all, since every option above signals failure by exiting non-zero. ## A defensible nightly command ``` rsync -a --delete --delete-after --max-delete=1000 \ --partial-dir=.rsync-partial --bwlimit=20M --timeout=600 \ --link-dest=/srv/mirror/previous --stats \ -e 'ssh -p 2222' \ /srv/data/ backup@host:/srv/mirror/current/ ``` Every flag there answers a specific failure you can name, which is the standard to hold any production rsync command to.