If you run any kind of Linux server—at home, in a rack, or in the cloud—sooner or later you need to move files around: backups, logs, database dumps, ISO images, random test scripts. Doing that over and over by hand, or via clunky GUIs, gets old fast.
In this guide we stay with one simple tool: scp (secure copy). It rides on top of SSH, gives you encrypted file transfer, and lets you copy between your laptop, a single remote server, or even two remote servers, all from one command. You’ll see how to keep your file transfers fast, safe, and low‑friction, without setting up extra services or raising your deployment complexity.
Picture this: you’re at your terminal, you’ve got a file on one machine, and you need it on another. You don’t want to open an FTP server, you don’t want to drag things through some random web panel, and you definitely don’t want to send it to yourself by email.
That’s where scp comes in:
It uses SSH under the hood, so everything is encrypted.
You don’t have to log into the remote server first; you run one command and it does the work.
It works between:
Local → remote
Remote → local
Remote → remote (server A → server B)
Even between two directories on the same remote server, triggered from your local machine
All you need is SSH access (username + password or key) on the systems involved.
If you don’t even have a second server handy to test with, that’s fine too. You can spin up a dedicated box, try a few scp commands, break things safely, and then rebuild. That’s where a flexible provider helps.
Once you have two SSH‑reachable machines, you’re ready to walk through the scenarios below.
The scp command always follows the same pattern:
bash
scp source destination
Either side (source or destination) can be:
A local path, like /home/alex/backup.sql
A remote path, like alex@203.0.113.10:/var/backups/backup.sql
A remote path always looks like:
bash
username@server_ip:/path/on/that/server
Remember that format and 90% of scp suddenly feels simple.
Let’s start with the most common thing you’ll ever do: push one file from your machine to a server.
Pattern:
bash
scp localmachine/path_to_the_file username@server_ip:/path_to_remote_directory
Example from macOS to a Linux server:
bash
scp /Volumes/MacDrive/Distros/fedora.iso
swapnil@10.0.0.75:/media/prim_5/media_server/
What’s happening here:
swapnil is the user on the remote Linux server.
10.0.0.75 is the server’s IP.
The remote path /media/prim_5/media_server/ is where the file will land.
You’ll be prompted for the password for swapnil on that server (unless you use SSH keys). After that, the file starts copying securely.
Same idea from a local Linux machine:
bash
scp /home/swapnil/Downloads/fedora.iso
swapnil@10.0.0.75:/media/prim_5/media_server/
On Windows 10 and later, if you have the Ubuntu subsystem (WSL) installed, you can do almost the same thing:
bash
scp /mnt/c/Users/swapnil/Downloads/fedora.iso
swapnil@10.0.0.75:/media/prim_5/media_server/
Once you’ve done this once or twice, it becomes muscle memory.
Sometimes you don’t want to move just a single file; you want the entire folder: configs, media, or a whole project.
The -r flag (recursive) tells scp to walk through a directory:
bash
scp -r localmachine/path_to_the_directory
username@server_ip:/path_to_remote_directory/
Key detail:
The source directory (local) usually has no trailing slash.
The destination directory (remote) should end with a trailing slash.
So if you run:
bash
scp -r ./project
alex@203.0.113.10:/srv/apps/
You’ll end up with /srv/apps/project/ on the server, containing all your files and subdirectories.
What if you don’t want the directory itself, just what’s inside it?
Then you use /*:
bash
scp -r localmachine/path_to_the_directory/*
username@server_ip:/path_to_remote_directory/
Example:
bash
scp -r ./webroot/*
alex@203.0.113.10:/var/www/html/
Result:
Everything inside ./webroot lands directly inside /var/www/html/.
You don’t get another nested webroot directory on the remote side.
This little difference (dir vs dir/*) is the kind of thing that makes or breaks a late‑night deployment.
Now flip it around. Maybe you have logs, snapshots, or a backup on the server that you want to grab locally.
Just swap source and destination.
bash
scp username@server_ip:/path_to_remote_file
local_machine/path_to_the_file
Example:
bash
scp alex@203.0.113.10:/var/backups/db.dump
/home/alex/backups/db.dump
bash
scp -r username@server_ip:/path_to_remote_directory
local_machine/path_to_the_directory/
Again, same rule:
Remote source directory: no trailing slash.
Local destination directory: trailing slash.
Example:
bash
scp -r alex@203.0.113.10:/var/www/
/home/alex/site_backup/
Just the contents, not the top folder:
bash
scp -r username@server_ip:/path_to_remote_directory/*
local_machine/path_to_the_directory/
Example:
bash
scp -r alex@203.0.113.10:/var/log/nginx/*
/home/alex/nginx_logs/
Now you can inspect logs, test backups, or diff configs locally with your usual tools.
Here’s a neat trick. You can copy files between directories on the same remote server without logging into it first. You stay on your local machine and let scp do the hop.
bash
scp username@server_ip:/path_to_the_remote_file
username@server_ip:/path_to_destination_directory/
Example:
bash
scp alex@203.0.113.10:/etc/nginx/nginx.conf
alex@203.0.113.10:/etc/nginx/nginx.conf.bak/
bash
scp -r username@server_ip:/path_to_source_directory
username@server_ip:/path_to_destination_directory/
Example:
bash
scp -r alex@203.0.113.10:/var/www/site/
alex@203.0.113.10:/var/www/site_backup/
bash
scp -r username@server_ip:/path_to_source_directory/*
username@server_ip:/path_to_destination_directory/
Example:
bash
scp -r alex@203.0.113.10:/var/www/site/releases/*
alex@203.0.113.10:/var/www/site/current/
You’re basically remote‑controlling the server’s filesystem from your local machine, without opening a shell session.
Now for the fun one: you’re on your laptop, and you want to move data directly from Server A to Server B. You don’t want to download it to your machine and then upload it again. You just want the two servers to talk to each other.
scp can do that as long as:
Your local machine can reach both servers via SSH.
Server A can reach Server B, or vice versa, depending on the command.
bash
scp username@server1_ip:/path_to_the_remote_file
username@server2_ip:/path_to_destination_directory/
Example:
bash
scp alex@203.0.113.10:/var/backups/db.dump
alex@198.51.100.20:/var/backups/
bash
scp -r username@server1_ip:/path_to_source_directory
username@server2_ip:/path_to_destination_directory/
Example:
bash
scp -r alex@203.0.113.10:/var/www/site/
alex@198.51.100.20:/var/www/site/
bash
scp -r username@server1_ip:/path_to_source_directory/*
username@server2_ip:/path_to_destination_directory/
Example:
bash
scp -r alex@203.0.113.10:/var/www/site/releases/*
alex@198.51.100.20:/var/www/site/current/
This is the kind of thing that makes migrations and sync jobs between hosting locations much smoother. You can move data between environments—test, staging, production—without juggling temporary files or manual downloads.
If you’re running serious workloads or testing real‑world sysadmin workflows, having quick access to multiple physical locations helps a lot. That’s where using a provider with instant dedicated servers in multiple regions becomes very handy.
To keep your scp life easier:
Use SSH keys instead of passwords for faster and safer logins.
If your SSH port isn’t the default 22, add -P <port> to the scp command.
For large files on slow links, consider adding -C to enable compression.
Always double‑check paths before hitting Enter; scp is powerful and doesn’t ask many questions.
Once you remember the pattern scp source destination, everything else is just swapping paths around.
Once you get a feel for scp, moving files between Linux servers stops being a chore and becomes a quick reflex: type one line, hit Enter, watch the progress bar. Whether it’s local → remote, remote → local, or server → server, the same simple pattern keeps your transfers encrypted, predictable, and low‑overhead.
If you want to try these commands in a more realistic environment—multiple locations, higher bandwidth, real server‑to‑server traffic—that’s exactly why scp plus a flexible hosting setup works so well. For that scenario, it’s worth looking at 👉 why GTHost is suitable for secure Linux server‑to‑server file transfer scenarios so you can practice and deploy on infrastructure that’s built for fast, stable, encrypted file movement.