You’ve got a Linux server somewhere on the internet, and now you need to move files to it without dragging in some huge deployment tool. That’s where SCP Linux commands come in: small, built-in, and secure because they ride on top of SSH.
In this guide, we walk through practical SCP examples you’ll actually use for web hosting, DevOps, and backups, so you can ship files quickly, keep transfers stable, and lower the “deployment is scary” feeling a lot.
SCP means “secure copy.” You use it to copy files:
From your laptop to a server
From a server back to your laptop
Or even from one server straight to another
It uses the same authentication and encryption as SSH, so if you can ssh into a box, you can almost always scp to it too.
The basic shape of the command is:
bash
scp [options] source target
The remote side usually looks like:
bash
username@host:/path/to/file_or_directory
host can be an IP or a domain name. After you press Enter, SCP will usually prompt for the SSH password (unless you’re using keys).
Let’s start with the everyday stuff.
You’re pulling a file down from a server to your machine:
bash
scp username@from_host:file.txt /local/directory/
This copies file.txt from the home directory of username on from_host into /local/directory/ on your local machine.
Now the other way around:
bash
scp file.txt username@to_host:/remote/directory/
This uploads your local file.txt into /remote/directory/ on to_host.
Need a whole folder?
bash
scp -r username@from_host:/remote/directory/ /local/directory/
The -r means “recursive,” so SCP walks through the directory and copies everything under it.
Same idea, but push to the server:
bash
scp -r /local/directory/ username@to_host:/remote/directory/
This is handy for pushing up a simple website or config set.
No need to download to your laptop first:
bash
scp username@from_host:/remote/directory/file.txt
username@to_host:/remote/directory/
Here, scp runs from your local machine, but the file goes directly from from_host to to_host.
SCP looks simple, but a few flags make it a lot nicer in real life.
If your SSH server listens on a non‑standard port (for example 2222):
bash
scp -P 2222 username@from_host:file.txt /local/directory/
Note the capital -P (lowercase -p means something else).
For big files or lots of small files, compression often helps:
bash
scp -C username@from_host:file.txt /local/directory/
-C turns on compression for the SSH connection. On fast CPUs and slower networks, this can make transfers noticeably faster.
If you don’t want SCP to hog the entire line:
bash
scp -l 1000 username@from_host:file.txt /local/directory/
-l 1000 limits the transfer to about 1000 Kbit/s, so your video call doesn’t die while you’re copying logs.
Copy a file but keep its timestamps and permissions:
bash
scp -p username@from_host:file.txt /local/directory/
-p preserves modification times, access times, and modes. This is useful for backups or anything where you care about the original metadata.
Once the basic SCP Linux examples feel comfortable, these extras help with more complex setups.
Maybe you can only reach your server through a “jump host.” SCP can pass SSH options with -o:
bash
scp -o "ProxyJump user@jump_host"
username@from_host:file.txt /local/directory/
Here, scp first connects to user@jump_host and then jumps to from_host.
Don’t want progress bars and messages?
bash
scp -q username@from_host:file.txt /local/directory/
-q turns off the progress meter and most warnings. Good for scripts where you only care if it fails.
When things don’t work, turn on the noise:
bash
scp -v username@from_host:file.txt /local/directory/
-v prints a lot of debugging info about connection, authentication, and configuration. You can even stack it (-vvv) for more detail.
Real-world example: copy an entire directory through a jump host, with compression:
bash
scp -r -C -o "ProxyJump user@jump_host"
username@from_host:/remote/directory/ /local/directory/
This:
Copies recursively (-r)
Compresses data (-C)
Goes through a jump host with ProxyJump (-o ...)
When you use combinations like this, test them first on non‑critical data. Different servers and SSH configurations may behave slightly differently.
Here’s a bigger example that looks closer to everyday server work. Say you want to back up a website from a remote server to your local box:
bash
scp -r root@123.123.123.123:/var/www/html/ /home/youruser/backups/test/
This:
Logs in as root to 123.123.123.123
Copies everything under /var/www/html/
Stores it in /home/youruser/backups/test/ on your machine
You’d usually run this as a non‑root user if possible and make sure your backup directory has enough space.
A few easy-to-miss details that can save you headaches:
If the target file already exists, SCP simply overwrites it. No trash, no “are you sure?”, it just replaces the content.
Check paths carefully. A missing trailing slash can change where the directory ends up.
Remember: host can be IP or domain, as long as DNS resolves and the port is open.
For production servers, test commands with harmless files first, then run them on the real data.
On macOS, you can use the exact same scp commands from the built-in Terminal app. It’s the same SSH ecosystem, just a different OS.
On Windows, you can either use scp from PowerShell (OpenSSH is built into newer versions) or use a graphical SCP/SFTP client if you prefer clicking instead of typing.
Once you understand the SCP basics, switching between Linux, macOS, and Windows is more about the terminal you open than the command you run.
All these SCP commands work fine on paper, but the experience changes a lot depending on where your servers live and how fast the network is. Pulling a 10 GB backup over a slow or overloaded host can feel like watching paint dry.
If you’re doing regular deployments, backups, or log transfers, it helps to run SCP against fast, nearby servers with solid bandwidth. That’s where your hosting choice becomes part of your “tooling,” just like the scp command itself.
👉 Get a low-latency GTHost server that’s ready for SSH and SCP in a few minutes
With a setup like that, your SCP Linux transfers finish faster, your backup windows stay reasonable, and you spend less time staring at progress bars and more time actually shipping features.
Here’s a human-friendly recap of the key flags:
-r – Copy directories recursively (follows symlinks during traversal).
-C – Enable compression by passing -C to SSH.
-l limit – Limit bandwidth in Kbit/s.
-o ssh_option – Pass extra SSH options like ProxyJump or IdentityFile.
-P port – Use a custom port on the remote host (capital P).
-p – Preserve modification time, access time, and mode.
-q – Quiet mode (no progress meter, fewer messages).
-v – Verbose mode for debugging connection/auth issues.
You won’t use all of them every day, but knowing they exist makes SCP much more flexible.
Q1: Is SCP still safe to use for production servers?
Yes, SCP is built on SSH, so it benefits from the same encryption and authentication. For many small to medium deployments and backups, SCP on Linux is still a simple, secure choice.
Q2: When should I prefer SCP over rsync or SFTP?
Use SCP when you just need quick one-off copies or straightforward scripts. When you need sync, checksums, or partial updates, rsync or SFTP usually make more sense.
Q3: Do I have to open a special port for SCP?
No, SCP uses the SSH port (often 22). If you changed your SSH port, just use -P with that port in your SCP commands.
Q4: Why are my SCP transfers slow?
Common reasons: slow server disk, weak CPU (for encryption/compression), long network distance, or overloaded hosting. That’s where a good hosting provider, close to your users, makes a difference for SCP Linux performance.
Now you’ve got a set of practical SCP Linux examples you can copy, tweak, and reuse for everyday file transfers: backups, deployments, log pulls, and quick “grab that file from the server” moments. You know the core flags, the common patterns, and the little safety checks that keep you from overwriting the wrong thing.
For real-world use, the quality of your SCP experience depends a lot on the servers you connect to, which is why GTHost is suitable for secure SCP Linux file transfer scenarios like frequent deployments and backups: you get fast, ready-to-go hosting that plays nicely with SSH and SCP, so your secure copy commands feel like a normal part of your workflow instead of a bottleneck.