Your server is sitting in a data center somewhere, possibly on another continent. There’s no USB port you can reach, no drag-and-drop window, no screen to plug a flash drive into. Yet somehow your website’s files, your config files, your backups — all of it has to get there. And when something breaks at 2 a.m., you need to pull a log file off it just as quickly. So how does that actually happen?
The answer is a handful of small, reliable tools that have been doing this job for decades. Once you understand the few core ways to move files across a network, you’ll never feel stuck staring at a remote machine again. Let’s walk through them — what they are, when to reach for each, and the small details that save you a lot of frustration.
The problem: a computer you can only reach over the network
When a server is remote, you interact with it almost entirely through the network. You already do this when you open a terminal session on it — and if you’ve read about the command line, you know that text-based connection is your main steering wheel. File transfer is the same idea, just for files instead of commands.
There’s a useful mental split here. Some transfers go from your machine to the server (uploading your website, pushing a config change). Some go from the server to your machine (downloading a log, grabbing a backup). And some bring files from the internet straight onto the server, never touching your laptop at all. Each direction has a natural tool, and most of them ride on top of the same secure connection your terminal already uses.
YOUR LAPTOP REMOTE SERVER
│ │
│ upload ───────────────────► │ (scp / sftp / rsync)
│ │
│ download ◄─────────────────── │ (scp / sftp / rsync)
│ │
│ ┌─────────────┐ │
└──────────────│ INTERNET │──────┴──► download straight
└─────────────┘ onto the server
(wget / curl)Almost every secure transfer tool you’ll meet is built on top of SSH — the same encrypted channel you use to log into a server and run commands. That’s the key thing to hold onto: if you can SSH into a box, you can almost certainly move files to and from it too, because the file tools borrow that exact connection.
Secure by default, and that matters
Older tools like FTP sent your files — and sometimes your password — across the network in plain, readable text. On today’s internet that’s a serious risk. The tools we focus on here (scp, sftp, rsync over SSH) encrypt everything end to end, so anyone snooping on the connection just sees scrambled noise. Whenever you have the choice, pick the SSH-based tool. Plain FTP belongs in the past.
scp — the quick “copy this file over there”
scp stands for secure copy. It’s the most direct tool of the bunch: think of it as the regular cp copy command, except one end lives on a remote server. If you just need to shove a single file or a folder onto a server (or pull one back), scp is often the fastest thing to type.
The shape of the command is always source then destination:
# Upload a local file TO the server
scp report.pdf john@server.example.com:/home/john/
# Download a file FROM the server to your current folder
scp john@server.example.com:/var/log/app.log .
# Copy an entire folder (the -r means "recursive", i.e. include everything inside)
scp -r ./website john@server.example.com:/var/www/Read those colons carefully — they’re the whole trick. Anything in the form user@host:/path means “this part is on the remote machine.” Anything without a colon is a path on your local machine. So scp here.txt user@host:/there/ reads almost like a sentence: copy here.txt from here, to /there/ over on the host.
scp is wonderfully simple, and for a one-off “just get this file across” it’s hard to beat. Where it falls short is anything repeated or large: it copies everything every single time, with no memory of what it sent before. If you re-upload a folder, it re-sends all of it, even the parts that didn’t change. For that, there’s a smarter tool.
rsync — the smart, resumable copy for big jobs
rsync does the same fundamental job as scp — move files between machines — but it’s far cleverer about it. Its superpower is that it only transfers the differences. The first time you sync a folder, it copies everything. The second time, it looks at both sides, figures out what actually changed, and sends only those bits. For a website with thousands of files where you changed three of them, that turns a multi-minute upload into a one-second one.
# Sync a local folder up to the server (note the trailing slashes — they matter)
rsync -av ./website/ john@server.example.com:/var/www/website/
# Pull a folder down from the server
rsync -av john@server.example.com:/var/www/website/ ./backup/The flags you’ll use constantly:
-a(“archive”) — copy folders recursively and preserve useful details like file permissions and timestamps. This is the one you almost always want.-v(“verbose”) — print each file as it goes, so you can see what’s happening.-z— compress data during transfer, which can speed things up over a slow connection.--delete— make the destination match the source exactly, removing files on the server that no longer exist locally. Powerful, and a little dangerous — read the warning below.
The trailing slash and --delete will bite you
Two rsync details cause most of its accidents. First, a trailing slash on the source means “copy the contents of this folder,” while no slash means “copy the folder itself.” rsync ./site/ dest/ and rsync ./site dest/ put files in different places. Second, --delete removes anything on the destination that isn’t in the source — so a typo in the source path can wipe files you meant to keep. Before any real --delete run, add --dry-run: it shows you exactly what would happen without touching anything. Look at that output, then remove the flag and run for real.
Because rsync is resumable and efficient, it’s the standard choice for deploying websites, copying backups, and any job that runs more than once. If you find yourself reaching for scp repeatedly on the same folder, that’s your cue to switch to rsync.
sftp — an interactive file session
Sometimes you don’t know exactly which file you want yet. You want to look around the remote machine, see what’s there, then grab a file or two. That’s what sftp is for. Despite the name’s resemblance to old FTP, SFTP runs over SSH and is fully encrypted — it’s a completely different, secure thing.
Starting it drops you into an interactive prompt where you “walk” the remote filesystem with familiar commands:
sftp john@server.example.comsftp> ls # list files on the SERVER
sftp> cd /var/log # change directory on the SERVER
sftp> get app.log # download a file to your machine
sftp> put backup.tar.gz # upload a file to the server
sftp> lcd ~/Downloads # change directory on your LOCAL machine
sftp> bye # quitThe neat trick is the l prefix: cd and ls act on the remote server, while lcd and lls act on your local machine. So you can line up the right folder on each side, then get and put files between them. It feels like browsing two computers at once, which is exactly what you’re doing.
sftp shines when you’re exploring or when you only realize what you need after you’ve looked. For scripted, repeatable transfers, scp or rsync are usually cleaner because they’re a single line. Many graphical file-transfer apps are really just friendly windows wrapped around SFTP, so if you’ve ever dragged files onto a server in an app, you’ve already used it without knowing.
Downloading straight onto the server with wget and curl
Not every file needs to pass through your laptop. Often the file you want is already on the internet — a software package, an installer, a public dataset — and the fastest path is to have the server fetch it directly. Routing a large download through your home connection just to upload it again would be slow and pointless.
Two universal tools handle this, run while you’re logged into the server:
# wget — built for downloading; saves the file by its own name
wget https://example.com/software.tar.gz
# curl — a swiss-army transfer tool; -O keeps the original filename
curl -O https://example.com/software.tar.gzBoth grab the file over the network and drop it right onto the server’s disk, never touching your machine. wget is the simplest for a plain download. curl does far more (it speaks many protocols and is the go-to for testing APIs), but for “just download this URL,” either is fine. This pattern is everywhere in server work — half of every setup guide is some variation of “download this onto the server, then run it.”
Always check what you downloaded
When you pull a file straight onto a server, you usually want to confirm it arrived intact and is what you expected — especially for anything you’re about to run. Many download pages publish a checksum (a short fingerprint like an SHA-256 hash) next to the file. After downloading, you compute the hash of your copy and compare. If they match, the file is complete and untampered. It’s a thirty-second habit that catches corrupted downloads and, occasionally, something worse.
A quick word on permissions and ownership
Moving a file onto a server is only half the story. Once it lands, Linux still cares who owns it and who’s allowed to read, write, or run it. A file you upload often arrives owned by your user, which can be a problem if the program that needs it runs as a different user. This is exactly the territory covered by file permissions and users and groups — worth a look if a freshly uploaded file mysteriously “can’t be accessed” by your application.
The common pattern after an upload is a quick fix of ownership and permissions:
# Make the web server user own the uploaded site files
sudo chown -R www-data:www-data /var/www/website
# Give the owner read/write, others read-only
chmod -R 644 /var/www/websiteYou don’t need to memorize these now. Just file away the idea that transfer puts the file there; permissions decide whether anything can use it. A surprising number of “it uploaded but doesn’t work” mysteries are simply a permissions mismatch, not a transfer problem.
Which tool should you actually reach for?
With four-ish tools doing overlapping jobs, here’s the short version of when to use each:
┌─────────────┬──────────────────────────────────────────────┐
│ scp │ One quick file or folder, copied right now │
│ rsync │ Repeated / large transfers; deploys; backups │
│ sftp │ Browsing the server, grabbing files as you go │
│ wget / curl │ Pulling a file from the internet onto the │
│ │ server, skipping your laptop entirely │
└─────────────┴──────────────────────────────────────────────┘If you only learn two, make them rsync and wget. rsync covers nearly every “move my stuff between my machine and the server” need efficiently, and wget covers “grab something from the web onto the server.” Add scp for the truly quick one-offs and sftp for the rare time you want to poke around interactively, and you’re equipped for almost anything.
Wrapping up
Here’s the whole picture in one place:
- A remote server has no USB port and no screen you can reach, so files move over the network — and the secure tools all ride on the same SSH connection your terminal uses.
scpis a direct “copy this file over there.” Simple and great for one-offs; it re-sends everything every time.rsyncis the smart, resumable copy that transfers only what changed — the standard for deploys, large folders, and anything you do more than once. Watch the trailing slash and--delete, and use--dry-runfirst.sftpgives you an interactive, encrypted session to browse the server andget/putfiles as you go.wgetandcurldownload files from the internet straight onto the server, skipping your machine entirely.- After a transfer, remember that permissions and ownership decide whether anything can actually use the file.
Once files move freely between you and a server, the next natural step is making the machine do work on its own schedule — running backups, cleanups, and reports automatically without you typing a command each time. That’s where scheduled tasks come in.
