Rsync vs SCP vs SFTP: Which Should You Use?

scp's underlying protocol is deprecated in favor of SFTP, and newer OpenSSH versions run scp via SFTP internally, but existing scripts don't need urgent rewriting — the practical guidance is simply to avoid writing new automation against scp going forward, since rsync or sftp handle every case scp does, plus resume support.

scp has no native resume mechanism — it opens a connection, copies, and exits, with no protocol-level support for picking up a partial transfer. rsync's --partial flag and sftp's reget/reput commands are the two options with a real resume story.

Not necessarily for a single one-time copy of an unchanged file — rsync's advantage comes from its delta-transfer algorithm on repeated syncs, where only changed data moves. For a true one-shot copy with no history to diff against, the practical difference versus scp is smaller, though rsync's resumability still makes it the safer default.

All three typically ride on OpenSSH's roughly 2MB fixed transfer buffer, which becomes the bottleneck rather than actual available bandwidth on a high-latency wide-area path — this can make them 100x or more slower than a single HTTP stream on a cross-continent transfer.

A parallel-stream transfer tool, such as Globus or a cloud-native S3/GCS sync API, since these are built specifically to avoid the single-stream SSH buffer ceiling that limits all three SSH-based tools on high-latency paths.