Rsync vs SCP: Which Linux Copy Command to Use

Use rsync for anything bigger than a quick one-off copy, and scp when you just want a file on another box right now. The core difference: scp streams the whole file again every time and has no memory of a dropped connection, while rsync compares source and destination, transfers only the changed blocks, and resumes an interrupted copy where it stopped. On a large backup over a flaky link that is the gap between two minutes and starting over. Both ship with OpenSSH on virtually every Linux distribution, so this is a habit choice, not an install choice — and the habit should default to rsync. Below: a straight comparison table, real speed differences, the resume trick scp cannot do, and the cases where scp is still the right answer.

What is the difference between rsync and scp?

scp does one thing: open an SSH channel, stream the bytes, close. It has no state between runs, so if the transfer dies at 90% you restart from zero.

rsync is a synchronisation tool that happens to use SSH as its transport. Before sending, it builds a checksum list of the destination file (the rolling-checksum delta algorithm) and transmits only the blocks that differ. Run the same command twice and the second pass moves almost nothing. That also makes rsync the natural tool for keeping two directories in sync — schedule it and each run copies just the deltas.

The practical consequences:

• Interruptions: rsync resumes; scp restarts the file.
• Second copies: rsync sends only changes; scp re-sends everything.
• Deletions: rsync can mirror deletions with --delete; scp cannot.
• Filtering: rsync has --exclude patterns; scp copies everything you point at.
• Dry runs: rsync shows what it would do with --dry-run; scp offers nothing.

Is rsync faster than scp?

For a first-time copy of one large file over a fast link, they are close — both are saturating SSH, and the checksum pass adds only a small overhead. The gap opens in three places:

1. Small files in bulk. rsync pipelines directory walks and can reuse one connection; older scp setups spawned work per file. Thousands of little files (a node_modules, a WordPress install) finish noticeably faster with rsync.
2. Re-runs. Copy a 4 GB file where 50 MB changed and rsync moves roughly 50 MB; scp moves 4 GB again.
3. Compression. -z compresses in flight, which helps on slow WAN links.

You can time both yourself — the command is identical in shape:

# same file, same server, both over SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# re-run both: scp re-copies, rsync verifies and sends ~nothing
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

If you spend your day in servers, transfer speed is one of those things worth measuring once — the same way ss beats netstat on busy hosts (see ss vs netstat: which Linux port command to use).

Can scp resume an interrupted transfer?

No. scp has no resume; if the connection drops at 900 MB of 1 GB, you start again. This is the single most quoted reason in every rsync-vs-scp debate, and it is real.

rsync’s whole design assumes the transfer will be interrupted sometimes. The canonical resume incantation:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial keeps the half-written file instead of deleting it.
• --append-verify resumes by appending, then checksum-verifies the appended region — safe against a corrupt partial file, unlike the old plain --append.
• --progress shows you where it picked up.

Wrapped in a retry loop, this is a set-and-forget backup over even a hostile connection:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

When should you use scp instead of rsync?

scp is still the right tool in a handful of cases:

• One small file, once. Typing scp app.conf user@host:/etc/myapp/ is shorter than any rsync invocation, and there is nothing to resume.
• rsync is missing on the far end. rsync needs its binary on both sides. Many minimal containers and appliances ship scp’s SFTP server but not rsync.
• You don’t want an rsync server exposed. Rare, but some environments lock down the rsync daemon specifically.

One subtlety worth knowing: the OpenSSH project deprecated scp’s original protocol years ago, and modern scp actually speaks SFTP underneath. That fixed a path-escaping quirk, but it changed nothing about the two limitations that matter here — no resume, no delta transfer. The protocol change does not make scp rsync.

Also related: if your question is really “rsync vs cp”, the answer mirrors this one — cp is the local-only equivalent of scp (no resume, no delta, no attributes unless you add flags), and rsync works for both local and remote. For local one-shots, cp is fine.

Which rsync flags matter most?

Most people only ever need one line:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Flag	What it does
-a (archive)	Recursive + preserves permissions, times, group, symlinks, devices
-v (verbose)	Lists what it transfers
-h (human)	Human-readable sizes
--partial	Keep partially transferred files, so a re-run resumes
--progress	Per-file progress — the thing scp never had
-z	Compress in flight (slow CPUs on fast LANs: skip it)
--delete	Mirror deletions too — dangerous, always pair with a dry run
--dry-run (-n)	Show what would happen, change nothing

Two habits worth adopting. First, dry-run anything with --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # review
rsync -avh --delete src/ user@server:/srv/dest/             # then commit

Second, mind the trailing slash — /srv/src copies the directory itself into the destination, while /srv/src/ copies its contents. This trips up everyone once; rsync even warns “no bytes transferred” when you meant the other form.

For a daily or weekly sync, drop rsync into a systemd timer and let it copy only the deltas — the journalctl side of scheduling is covered in the journalctl cheat sheet.

Rsync vs scp: the verdict

	scp	rsync
Ships with OpenSSH	Yes	Yes (both ends needed)
Resume interrupted transfer	No	Yes (--partial)
Delta transfer on re-runs	No	Yes
Preserve permissions/symlinks	Partially	Fully (-a)
Exclude patterns	No	--exclude
Dry run	No	--dry-run
Mirror deletions	No	--delete
Best for	Quick one-off copies	Backups, syncs, bulk trees

Default to rsync for backups, big trees, anything over a link that can drop, and anything you will run more than once. Use scp when the command is shorter than the thought. If you take one flag away, take --partial — it converts every future dropped connection from a restart into a pause.