scp vs rsync: Comprehensive Guide to Server File Transfer, Usage, and Pros/Cons

Background and Use Cases

Transferring files between a local machine and remote hosts—or directly between two remote hosts—is a routine task for Linux system administrators. Two built‑in tools are commonly used:

scp – simple, SSH‑based copy suitable for occasional, small transfers.

rsync – a powerful synchronization utility that supports incremental updates, compression, bandwidth limiting, and fine‑grained filtering, making it ideal for large data sets and regular backups.

scp Overview

scp runs over SSH, encrypting all traffic. It copies the entire source each time, which keeps the command line short and easy to use. scp [options] source_path destination_path Key options: -r – recursive copy of directories. -p – preserve timestamps, permissions, and ownership. -C – enable compression. -P port – specify a non‑default SSH port (capital P). -i identity_file – use a specific private key. -l limit – limit bandwidth (Kbit/s). -o ssh_option – pass additional SSH flags.

Typical scp scenarios:

Upload a single file: scp /path/to/file.txt user@host:/remote/path/ Upload using a non‑standard port: scp -P 2222 file.txt user@host:/remote/path/ Upload with a private key: scp -i ~/.ssh/id_rsa file.txt user@host:/remote/path/ Upload a directory recursively: scp -r /local/dir user@host:/remote/dir/ Limit bandwidth to 500 KB/s (≈4000 Kbit/s):

scp -l 4000 largefile.tar.gz user@host:/remote/

rsync Overview

rsync can work locally, over SSH, or via its own daemon. It transfers only the differences between source and destination, dramatically reducing network traffic for repeated synchronizations. rsync [options] source_path destination_path Important options: -a – archive mode (equivalent to -rlptgoD), preserving permissions, timestamps, owners, groups, symlinks, and device files. -z – compress data during transfer. -P – show progress and keep partially transferred files ( --partial --progress). --delete – delete files in the target that no longer exist in the source (mirror sync). --exclude=PATTERN / --include=PATTERN – filter files. -n or --dry-run – preview changes without copying. --bwlimit=RATE – limit bandwidth (KB/s). --partial – keep partially transferred files for resume.

Typical rsync scenarios:

Local directory sync: rsync -av /src/ /dst/ Remote sync over SSH: rsync -avz -e ssh /src/ user@host:/dst/ Incremental sync (only changed files): rsync -avzP /src/ user@host:/dst/ Mirror a directory (delete extraneous files): rsync -avz --delete /src/ user@host:/dst/ Exclude logs: rsync -avz --exclude='*.log' /src/ user@host:/dst/ Limit bandwidth to 1 MB/s:

rsync -avz --bwlimit=1024 /src/ user@host:/dst/

Feature Comparison

Transfer mode : scp copies the whole source each time; rsync copies only differences.

Resume support : scp does not support resume; rsync supports it via --partial (or -P).

Compression : scp uses -C; rsync uses -z.

File exclusion : not available in scp; available in rsync with --exclude / --include.

Dry‑run preview : scp lacks this; rsync provides -n / --dry-run.

Speed (full copy) : comparable for small transfers.

Speed (incremental) : scp is slower because it always copies everything; rsync is faster because it transfers only changed blocks.

Syntax complexity : scp is simple; rsync has more options but offers finer control.

Best suited for : scp – small, one‑off files; rsync – large data sets, regular backups, deployments.

Best Practices and Security

Prefer SSH key authentication over passwords.

Use rsync for large or recurring transfers; employ -n to preview destructive actions such as --delete.

Limit bandwidth with --bwlimit (rsync) or -l (scp) to avoid impacting production traffic.

Exclude sensitive files (e.g., .env, *.key, *.pem) when syncing code or configuration.

When using --delete, run a dry‑run first to confirm the target will not lose needed data.

Log all transfers (e.g., redirect output to a file) for audit and troubleshooting.

Common Errors and Troubleshooting

ssh: connect to host port 22: Connection refused – Verify the SSH port and that the SSH service is running. Use ssh -p PORT user@host or scp -P PORT … to specify the correct port.

Permission denied (publickey) – Ensure the correct private key is used and its permissions are 600. Test with ssh -v user@host and specify the key with -i (scp) or -e "ssh -i …" (rsync).

rsync: connection unexpectedly closed – The remote rsync daemon may not be running, or the SSH session timed out. Start the daemon or increase the timeout with --timeout.

rsync: safe_read failed – Network instability. Increase the timeout ( --timeout) or resume with -P.

Real‑World Case Studies

Case 1: Large Log Migration

Goal : Move 500 GB of logs from an old server to a new one over a 100 Mbps link without disrupting services.

Solution :

# First full sync with bandwidth limit (10 MB/s ≈ 80 Mbps)
rsync -avzP \
    --bwlimit=10240 \
    --exclude-from=/tmp/rsync_exclude.txt \
    -e "ssh -p 22" \
    [email protected]:/var/log/myapp/ \
    [email protected]:/var/log/myapp/

# After the initial copy, run an incremental sync during the low‑traffic window
rsync -avzP \
    --exclude-from=/tmp/rsync_exclude.txt \
    -e "ssh -p 22" \
    [email protected]:/var/log/myapp/ \
    [email protected]:/var/log/myapp/

Notes: --exclude-from can list files that are still being written (e.g., *.current.log) to avoid copying incomplete logs.

Case 2: Zero‑Downtime Code Deployment

Goal : Deploy a new version of a web application without service interruption.

Process :

# Sync to a staging directory on the target host
rsync -avz --exclude={'.env','.git','node_modules'} \
    -e "ssh -p 22" \
    /local/release/ deploy@host:/var/www/app_test/

# Verify the staging copy (manual or automated checks)
# If everything looks good, sync to the live directory
rsync -avz --exclude={'.env','.git','node_modules'} \
    -e "ssh -p 22" \
    /local/release/ deploy@host:/var/www/app/

# Restart the application and run health checks
ssh -p 22 deploy@host "systemctl restart myapp && curl -s http://localhost/health"

Using --dry-run ( rsync -avzn …) before the final sync helps ensure no unintended deletions.

Case 3: Daily Database Backup Synchronization

Goal : Back up MySQL dumps to an off‑site server and retain 30 days of history.

# Create a timestamped dump and compress it
mysqldump -h localhost -u backup -p'password123' mydb \
    > /backup/db/mydb_$(date +%Y%m%d_%H%M%S).sql

gzip /backup/db/*.sql

# Sync to remote backup host with bandwidth limit (5 MB/s)
rsync -avzP --bwlimit=5120 \
    -e "ssh -p 22" \
    /backup/db/ [email protected]:/backup/mydb/

# Remove local backups older than 30 days
find /backup/db -name '*.sql.gz' -mtime +30 -delete

After the sync, verify with du -sh on both sides and optionally compare checksums for critical files.

Performance Considerations

Assume a source directory contains 1 000 files, but only 10 have changed since the last run.

scp transfers all 1 000 files each time.

rsync transfers only the 10 changed files (plus metadata), saving bandwidth and time.

For a single 10 GB file where only a few megabytes have changed, rsync may transfer only the delta (a few hundred MB), whereas scp would resend the full 10 GB.

Choosing Between scp and rsync

Use scp when :

Transferring small files (tens of MB) once.

Network is stable and you do not need resume support.

You prefer a simple command without extra options.

Use rsync when :

Copying large files or large numbers of files.

You need incremental transfers to save bandwidth.

Selective inclusion/exclusion of files or directories is required.

Resume of interrupted transfers is important.

Regular backups, deployments, or mirroring are needed.

You want to preview actions before they affect the target.

Summary

Both scp and rsync rely on SSH for secure transport. scp is straightforward and works well for quick, one‑off copies of small files. rsync adds powerful features—incremental syncing, filtering, dry‑run preview, and resume—that make it the tool of choice for large data migrations, regular backups, and zero‑downtime deployments. Selecting the appropriate utility depends on the size of the data, frequency of transfers, and need for fine‑grained control.