SCP vs rsync in Linux: When to Use Each for Remote File Transfer

scp fits a one-off copy: you point it at a file or folder and it sends the data. rsync fits repeated synchronization: it compares source and destination, skips what already matches, and on remote transfers can update existing files with changed blocks instead of re-sending everything.

Both can run over SSH with the same login you use for remote shell access. The choice is not “which is more secure” but “do I need a simple copy once, or a sync job I will run again?”

SCP vs rsync at a glance

For flag syntax, use the scp and rsync cheat sheets. This page explains when each tool fits.

When to use scp

scp is OpenSSH secure file copy. The scp(1) manual describes copying between hosts over SFTP on an ssh(1) connection, with the same authentication and security as a login session.

Reach for scp when you:

• copy one file or folder once and will not repeat the job soon;
• want the smallest command with no sync options;
• do not need exclude rules, dry-run, or destination cleanup.

scp syntax

Remote paths always use a colon after the host (host:). There is no trailing-slash rule like rsync — scp -r /var/www/html host:/backup/ creates /backup/html/ on the remote side.

Common scp patterns

Common scp flags

Each run sends the files you named. Run the same command again tomorrow and scp sends them again, even if nothing changed.

When to use rsync

rsync behaves differently from scp. Ask rsync to copy a file again and it compares source and destination first. If a file is already unchanged, it skips it. For remote transfers, rsync can use its delta-transfer algorithm to send changed blocks of an existing file instead of retransmitting the entire file. rsync may still use whole-file transfer in some cases; --whole-file explicitly disables the delta algorithm. The rsync(1) manual describes the delta-transfer algorithm in full.

By default, rsync decides whether a file needs transfer with a quick check — mainly size and modification time. It does not checksum every unchanged file unless you add --checksum. rsync performs that comparison on each run; it does not store persistent metadata on the destination for later jobs.

Use rsync when you:

• run the same backup or deploy regularly;
• sync a directory tree and care about permissions and timestamps;
• need --exclude, --delete, or --dry-run.

rsync syntax

The trailing slash on the source is one of the most common rsync mistakes. Check the destination layout before a large sync.

Common rsync patterns (remote over SSH)

The examples above often combine -av. Here is what those letters mean:

Some metadata, such as ACLs and extended attributes, needs flags beyond -a — see the rsync command reference for those cases.

scp comes with OpenSSH and normally uses the remote SSH server's SFTP subsystem. Remote rsync additionally requires the rsync program on the remote host.

What happens when you run the command again

Unchanged file

scp copies the whole file every time.

rsync compares size and mtime. When they match, rsync skips the file and sends almost no payload. Re-run verbose rsync against a file that is already on the destination:

rsync -av /tmp/demo50m.bin root@192.168.56.220:/tmp/dest/demo50m.bin

Sample output:

sending incremental file list

sent 61 bytes  received 12 bytes  48.67 bytes/sec
total size is 52,428,800  speedup is 718,202.74

The high speedup means rsync confirmed the file already matched and did not re-send the 50 MiB.

Changed file

If you edit part of a large file and run scp again, scp re-sends the entire file.

On a remote transfer, rsync detects that the file changed (quick check fails) and can use its delta-transfer algorithm to send changed blocks rather than the full file. That is where rsync saves bandwidth on large, partially updated files — not on the very first copy.

In a lab test from vm1.lab.example to vm2.lab.example, a 50 MiB file was already on the destination. Changing 5 bytes at the start and re-running each command produced:

Re-copy the patched file with scp:

time scp -q /tmp/big50m.bin root@192.168.56.220:/tmp/dest/scp-target.bin

Sample output:

real    0m2.500s

scp transfers the whole file again even though only a few bytes changed.

Update the same destination with rsync:

time rsync -av /tmp/big50m.bin root@192.168.56.220:/tmp/dest/rsync-target.bin

Sample output:

sending incremental file list
big50m.bin

sent 36,311 bytes  received 50,729 bytes  58,026.67 bytes/sec
total size is 52,428,800  speedup is 602.35
real    0m1.240s

The sent line is far below 52 MiB because rsync moved changed blocks, not a full second copy. Exact seconds depend on your network and CPU; the pattern — scp re-sends everything, rsync sends less when part of the file already matches — is what matters.

Speed: which is faster?

There is no single winner; it depends on whether destination data already exists.

Do not read a one-off benchmark on one VM pair as a universal rule. Cipher choice, disk cache, CPU, and network shape the seconds. The behavior in the table above is what matters in production.

Metadata, resume, filtering, and delete

Both tools can use SSH for encrypted remote access when you write user@host:path. rsync can also use other remote shells or rsync daemon mode (host::module); this comparison stays on the SSH path most admins use alongside scp.

Common differences that cause mistakes

Trailing slash on rsync paths

This is covered in the rsync syntax table above: src/ copies contents; src copies the directory itself. List the remote destination with ssh user@host ls /dest/ before you run a long sync.

rsync must exist on the remote host

Remote rsync over user@host:path starts the rsync binary on both ends. If the remote host lacks rsync, you get command not found even though SSH works. scp comes with OpenSSH and normally uses the remote SSH server's SFTP subsystem; it does not require rsync on the remote side.

scp always re-copies; rsync is for repeat jobs

Using scp for a nightly backup of a large tree works, but every run re-sends unchanged files. rsync is the better default when the job runs on a schedule.

Troubleshooting

References

• scp(1) — OpenSSH secure file copy
• rsync(1) — rsync file copying tool
• OpenSSH project

Summary

scp and rsync both move files over SSH, but they answer different questions. scp behaves like remote copy: simple, predictable, and fine for one-off transfers. rsync compares source and destination on every run, skips unchanged files, and on remote transfers can delta-transfer changed blocks when an existing file was updated.

Choose scp when you copy once and do not need sync features. Choose rsync for repeated backups, directory mirrors, filters, and jobs where most data is already on the destination. Watch rsync trailing-slash semantics and install rsync on both hosts before you rely on it remotely.

For command flags and examples, keep the scp and rsync cheat sheets handy; use this page when you need to pick the tool before you write the command.