Rsync vs SCP vs SFTP: Which Should You Use?

Your deploy script has pushed a build artifact to production with scp for two years. Then the artifact grows to 4GB, the connection drops at 87%, and the script restarts the whole transfer from zero while your team watches the deploy window shrink.

That is when most engineers learn that scp, sftp and rsync are not interchangeable. All three run over SSH and all three encrypt data in transit, but they were built for different jobs, and the wrong choice silently costs you time, bandwidth or a stuck deploy.

What is the core difference between rsync, scp and sftp?

scp is a one-shot copy, sftp is an interactive file-management session, and rsync is a synchronization engine that sends only what changed. Each was designed for a different job, and that design goal should drive your choice more than command syntax.

Think of scp as cp across a network, sftp as a remote shell for files, and rsync as a diffing sync engine. Using the wrong mental model is usually why a script feels slower or clunkier than it should.

What does the same task look like in each tool?

Here is the same job, copying a build directory to a server, in all three tools.

Watch the trailing slash in rsync. ./dist/ copies the contents of dist into the destination, while ./dist copies the directory itself and creates dist inside it.

rsync -a (archive mode) preserves permissions, timestamps, ownership and symbolic links. scp copies file contents and, with -r, follows symlinks, so a link becomes a copy of its target. Add -p to scp if you need to preserve modes and times.

How does rsync avoid resending data?

rsync compares source and destination first, then sends only what differs. By default it checks file size and modification time, and for changed files it transfers just the changed blocks. At the end it verifies the whole-file checksum.

That is why the second and later runs of a nightly sync are fast, and why a first-time copy of a single new file shows little advantage over scp.

How do the three tools handle interrupted transfers?

rsync and sftp can resume, and scp cannot. If a transfer matters or the link is unreliable, use one of the first two.

-P in rsync is shorthand for --partial --progress. Use -c only when you need checksum comparison of every file, because it reads all data on both sides and is slow.

Important: be careful with --delete, which removes files at the destination that no longer exist at the source. Always run with -n (dry run) first and double-check the source path, because a wrong path plus --delete can wipe a production directory.

Why are all three slow over long distances?

All three ride on one SSH connection, and SSH uses a flow-control window. Throughput is capped at roughly the window size divided by round-trip time, so on a high-latency path the cap can sit far below your available bandwidth.

On a local network or within a region you will rarely notice. Across continents, a single stream can be many times slower than a link capable of much more. Options when that happens:

1. Run several transfers in parallel, for example one rsync per subdirectory.
2. Use a tuned SSH build (such as HPN-SSH) on both ends if you control them.
3. Use object storage tools such as aws s3 sync or rclone, which use parallel streams.
4. Use a dedicated transfer service like Globus for very large scientific or archival datasets.

Measure with your own path and file sizes before you pick, since results depend heavily on latency, loss and file count.

How do you lock down automated transfers?

Use dedicated keys with restrictions, never a shared admin login. A transfer job needs to move files, not open a shell.

For rsync jobs, restrict the key in authorized_keys with options like restrict and a forced command (for example the rrsync helper that ships with rsync), so a stolen key can only do rsync into one directory. Also store keys with strict permissions and rotate them.

Trade-offs and Alternatives

Behavior comparison:

rsync and use cases:

For cloud storage, rclone and the cloud vendors' CLIs are usually a better fit than any SSH-based tool.

Production Implementation Guidelines

Use rsync as the default for anything that repeats: nightly backups, deploy artifact syncs and mirroring between environments. After the first run it moves only what changed.

Use sftp when a human needs to browse or manage files, or when a partner or platform only exposes an SFTP endpoint. Its audit-friendly operations and chroot support make it a good fit for controlled upload areas.

Avoid writing new automation against scp. It still works, and existing scripts do not need urgent rewriting, but rsync and sftp handle everything it does and add resume.

A few habits make any of these safer:

1. Dry-run first: rsync -avn before any sync that uses --delete.
2. Cap bandwidth with --bwlimit on links shared with production traffic.
3. Skip compression for compressed data: -z wastes CPU on archives and images, so add --skip-compress or drop it.
4. Check the exit code in scripts, and alert on non-zero.
5. Use restricted keys and dedicated service accounts.

Related reading: rsync and sftp both run over SSH, so configuring SSH for secure server access is the foundation for either. Recurring syncs are usually scheduled, which is covered in scheduling Linux tasks with cron, and because rsync -a carries ownership and modes across, Linux file permissions and ownership explains what you will see on the destination.

References and Further Reading

• rsync Manual Page - Official flag and option reference
• OpenSSH sftp Manual - Interactive and batch mode usage
• OpenSSH Release Notes - scp moving to the SFTP protocol
• Fasterdata: Say No to scp - SSH transport limits on long paths