scp vs sftp vs rsync at the Command Line: Choosing Your Copy Tool

Sit three administrators at three terminals, ask each to move the same directory to the same server, and you may well see three different commands: an scp -r, an sftp session, and an rsync -a. All three will work. That is precisely what makes the choice confusing for someone newer — when everything works, what makes one tool right?

The answer is that the three tools overlap at the center and differ enormously at the edges. Every one of them can copy a file over SSH; only one can resume a broken transfer of a 60 GB file, only one can rename and delete on the far side, and only one can re-run tonight and send just the bytes that changed since last night. This article maps tool to task: a portrait of each, a task-by-task walkthrough, honest performance notes, and a pocket decision table you can keep. It is part of our SCP & SSH Copying series.

Three Tools, One Transport

Start with what they share, because it eliminates a whole category of worry. In everyday use, all three run over SSH: one connection to one port (22 by default), the server's identity checked against your known_hosts, your login by password or key, and everything encrypted in transit. Firewalls see identical traffic in all three cases. Your ~/.ssh/config — aliases, keys, ports, jump hosts — applies to all three equally, which is why the tuning in SSH config as a transfer accelerator pays off triple. Security is not the differentiator here. Capability is.

Sharing a transport buys you more than comfort. Operationally it means one firewall conversation ("allow SSH to that host" covers all three tools), one credential system to manage (the same key pair authenticates every tool), one hardening effort on the server, and one set of debugging instincts — if ssh host works, the transport layer is proven and any remaining failure belongs to the tool or the filesystem. Compare that with juggling separate protocols, each with its own ports and its own authentication story, and the appeal of the SSH family as a family becomes obvious.

scp is the pocketknife: a copy verb and nothing else. Source, destination, done. It is on every system, needs zero setup, and its syntax mirrors cp so closely that nobody forgets it. Its protocol story — a design inherited from Unix's old rcp, now often carried over SFTP internally — is told earlier in this series. What it cannot do — resume, list, rename, delete, send only changes — is catalogued in SCP's limitations.

sftp is the file manager: an interactive session (or a scripted batch) speaking the SFTP protocol, with a full vocabulary — ls, get, put, rename, rm, mkdir, chmod — plus the two commands scp users envy most, reget and reput, which resume interrupted transfers from where they stopped. It is also the protocol that graphical transfer clients and locked-down, transfer-only server accounts speak. Our SFTP series covers it top to bottom.

rsync is the synchronizer: a tool whose real question is not "copy this?" but "make that side match this side." Its famous delta algorithm compares source and destination and sends only the parts that differ, which turns a nightly copy of a mostly-unchanged tree from gigabytes into megabytes. The price of admission: rsync must be installed on both ends (it usually is on Linux, and usually is not on Windows), and its option surface takes learning. The full story lives in our rsync & delta transfer series.

Task by Task: Which Tool Wins

One file, right now

scp. No contest. For a config file, a certificate, a quick log pull, nothing beats the shortest correct command in the business:

scp app.conf alex@web01:/etc/app/

sftp would need a session or a here-document; rsync brings machinery the task does not need. This is the case scp was born for, and the reason it will never die.

A directory tree, one time

scp -rp for simple trees; rsync -a when the tree has structure worth respecting. The scp version is fine when the tree is plain files and you want it there once:

scp -rp site/ alex@web01:/var/www/staging

But scp -r follows symbolic links rather than copying them, offers no way to exclude the cache/ directory you did not mean to ship, and restarts from scratch if interrupted. rsync -a preserves links, owners, and times, takes --exclude patterns, and — the quiet killer feature — if the copy dies halfway, running the same command again finishes the job instead of repeating it.

A big file over an unreliable link

rsync or sftp — anything but plain scp. scp cannot resume, so an interruption at 97 percent of a 60 GB transfer costs you 58 GB of progress. rsync with --partial keeps the fragment and continues on the next run; sftp's reget/reput do the same interactively:

rsync --partial --progress dump.sql.gz alex@dr-site:/backups/

The moment file size times link fragility crosses "an interruption would ruin my afternoon," scp is out of the running.

The same tree, again and again

rsync, decisively. A repeated copy is a synchronization problem, and delta transfer is the whole reason rsync exists. The first run copies everything; every run after sends only changes — typically a rounding error of the full size. scp re-sends every byte every time, which is why "our nightly scp takes four hours" is one of the most commonly solved problems in system administration. The mirroring patterns, --delete hazards included, are covered in the rsync series.

Poking around: list, rename, delete, fix permissions

sftp. This is not a copy task at all, and the copy-only tools have nothing to offer. An sftp session gives you a working directory on both sides and the verbs to manage the far one — including on hardened servers whose transfer-only accounts refuse shell commands outright, where the ssh host 'mv a b' workaround dies.

Unattended, on a schedule

sftp in batch mode or rsync under cron — up to a point. sftp's -b flag runs a file of commands non-interactively and exits nonzero on failure, which makes it honest in scripts:

sftp -b upload.batch alex@partner-drop
# upload.batch:
#   put /out/invoices-today.csv /incoming/
#   rename /incoming/invoices-today.csv /incoming/invoices-today.done

That covers the mechanics. What neither tool provides is the operational shell around a business transfer: retry with backoff when the partner is down, alerting a human when retries run out, watching a folder for files to appear, encrypting before sending, logging for the auditor. Teams script those pieces until the scripts become a maintenance burden of their own; on Windows, that is the point where a scheduled-transfer product like Sysax FTP Automation replaces the scaffolding — folder monitoring, retries, error handling, and OpenPGP encryption around SFTP, FTPS, or FTP transfers, defined as jobs instead of code.

A one-way publish where deletions must carry over

rsync with --delete — handled like the power tool it is. Sometimes "make that side match this side" includes removing files that no longer exist at the source: publishing a website build, maintaining a mirror. Neither scp nor sftp has any concept of this; rsync does it in one flag — and that flag, pointed at the wrong directory, will faithfully empty it. The professional habit is a dry run first (-n) to see what would be deleted, then the real run. The safety rituals around --delete get a full article in the rsync series; the takeaway here is that only one of the three tools can even express the requirement.

When you don't control the far side

sftp, usually by elimination. Transfers to a partner's server, a customer drop point, or a managed appliance go to an endpoint someone else configured — and hardened endpoints commonly offer a transfer-only SFTP account: no shell, no rsync binary to invoke, sometimes no classic scp path at all. In that world sftp is not the best choice; it is the menu. This is worth remembering in reverse when you are the far side for someone else: publishing an SFTP endpoint is the choice that every client on every platform can meet.

Thousands of tiny files

rsync — or a tar stream. Per-file ceremony is the enemy at this scale: ask scp or sftp to move 80,000 small files and the overhead of announcing each one dwarfs the payload. rsync amortizes much of that; the blunt-force classic is to stream one tar archive through ssh so the network sees a single continuous flow. That pattern — and when to prefer it — is worked through in copying through bastions.

The Pocket Decision Table

The one-glance version. Disagreements with your muscle memory are worth a moment's reflection, not a fight.

Performance, Honestly

Performance claims about these tools attract folklore, so here is the grounded version.

• Encryption costs the same everywhere. All three ride SSH's cipher, so raw crypto throughput is a wash. On modern hardware, a single big file on a clean LAN moves at broadly similar speed whichever tool you pick — differences there are implementation details, not categories.
• Small files punish chatty tools. Each file costs a round of announcements and acknowledgments. One 10 GB file is one ceremony; 100,000 files of 100 KB is 100,000 ceremonies, and on a high-latency WAN the ceremonies cost more than the bytes. Streams (tar) and pipelined protocols (rsync, good SFTP implementations) win exactly here.
• Delta transfer wins only when data repeats. rsync's algorithm shines when destination and source mostly match — nightly syncs, resumed copies. When everything is new, the checksum machinery is pure overhead and rsync runs no faster than anything else. And it cannot find useful deltas inside well-compressed or encrypted files, where any change scrambles the whole file.
• Compression is situational. -C (scp/ssh) or -z (rsync) can multiply effective throughput for text over a slow WAN, and it actively wastes CPU on fast LANs or on data that is already compressed — archives, images, video, encrypted blobs.
• Measure before optimizing. A five-minute trial with your real files over your real link beats any table on the internet, including this one.

A worked example makes the delta point concrete. A 20 GB document tree syncs offsite nightly, and on a typical day perhaps 300 MB of it changes. Copied with scp, every night moves 20 GB — call it four and a half hours at a steady 10 Mbps effective WAN rate. Synced with rsync, the same night moves roughly 300 MB plus some checksum chatter: a few minutes. Same data, same link, same encryption — a fifty-fold difference, produced entirely by not re-sending what the far side already has. That is the gap tool choice can open, and no flag on scp can close it.

Availability and the Windows Angle

On Linux and macOS, all three tools are effectively guaranteed: scp and sftp ship with OpenSSH, and rsync is either present or one package away. Current Windows systems include the OpenSSH client tools — ssh, scp, sftp — usable directly from PowerShell, but not rsync, which on Windows means an extra installation (commonly via a Linux compatibility environment or a third-party build) on both ends of the transfer. That asymmetry quietly shapes real-world choices: in mixed shops, sftp is often the lowest-friction common denominator because every platform speaks it natively, graphical clients included.

The server side of the question matters just as much. To receive any of these transfers, the far machine needs an SSH-based service. Linux servers have one by definition. A Windows machine can run the optional OpenSSH server, or — where file exchange is a first-class duty with named users, access rules, and an audit trail — a dedicated product such as Sysax Multi Server, which gives Windows an SFTP (SSH2) endpoint alongside FTPS and HTTPS, administered from a GUI rather than a config file. Whichever way you build the endpoint, the client-side decision framework on this page stays the same.

The Defaults Worth Adopting

If you want a policy instead of a decision each time, this one serves well. Reach for scp when the task is one boring file and the link is trustworthy — its economy is unbeatable. Reach for sftp when you need to see or manage the far side, when resume matters mid-session, or when the server allows nothing else. Reach for rsync the moment the words "again," "sync," "mirror," or "every night" enter the sentence. And treat any transfer that a business process depends on as having outgrown all three bare tools — wrap it in real scheduling, retries, and alerting before it teaches you why.

Notice what the policy optimizes: not speed, but the cost of the failure you have not had yet. The tools' happy paths are nearly interchangeable; their failure paths — restart from zero versus resume, silent overwrite versus verified sync — are where the hours go.

Wrap-Up and Where to Go Next

Three tools, one transport, three centers of gravity: scp copies, sftp manages, rsync synchronizes. Match the tool to the task's edge cases — resume, repetition, management, scale — and every one of them is excellent inside its lane.

From here: the scp command, mastered makes the quick-copy lane effortless; SCP's limitations gives the fine print behind this article's warnings; and SSH config as a transfer accelerator speeds up all three tools at once, since they share every connection setting. For depth on the two bigger siblings, the SFTP and rsync & delta transfer series continue the story.

Frequently Asked Questions