FTP vs Rsync: The Verdict
FTP is a 1971 file-transfer protocol; rsync is a delta-syncing transfer tool. For moving files between machines today, rsync wins on speed, safety, and security — and it isn't close.
The short answer
Rsync over Ftp for most cases. Rsync only sends the bytes that changed, runs over SSH by default, and resumes interrupted transfers without re-sending the whole file.
- Pick Ftp if a legacy appliance, mainframe, or vendor system only speaks FTP/FTPS and you have no SSH access — then you're stuck with it, so use FTPS, never plain FTP
- Pick Rsync The Verdict if control both ends and can run SSH — which is nearly always. Deploys, backups, mirroring directories, and syncing large datasets all belong to rsync
- Also consider: SFTP (SSH file transfer) is the sane middle ground if you need an interactive transfer protocol but want FTP's plaintext nightmare gone — but for repeated syncs, rsync still beats it.
— Nice Pick, opinionated tool recommendations
They're not the same category
FTP is a protocol from 1971 whose only job is shoving whole files across a wire. Rsync is a tool with a clever algorithm: it compares source and destination, computes a rolling checksum, and transfers only the differing blocks. That single design difference cascades into everything else. If you change one line in a 2GB file, FTP re-uploads 2GB; rsync uploads a few kilobytes. People conflate them because both 'move files,' but that's like comparing a wheelbarrow to a forklift because both 'move dirt.' The moment your workflow involves transferring the same files more than once — deploys, nightly backups, directory mirrors — FTP's stateless re-send everything model becomes pure waste. Rsync was literally built to make repeated transfers cheap. Choosing FTP for a recurring sync is choosing to pay full freight every single time for no reason.
Security is where FTP earns its mockery
Plain FTP transmits your username, password, and file contents as cleartext across the network. Anyone sniffing the link reads your credentials. That's not a hot take — it's why every serious shop banned it years ago. FTP's defenders point to FTPS, but FTPS is a graft job: it bolts TLS onto a protocol with separate control and data channels, and that dual-channel design is a firewall and NAT nightmare that ops teams curse weekly. Rsync, by contrast, rides over SSH by default. You get encrypted transport, key-based authentication, and a single port (22) that your firewall already understands. No passive-mode port-range gymnastics, no cleartext passwords, no 'why won't this work behind NAT' debugging session at 2am. If your threat model includes 'someone might be on the network,' and it should, FTP loses before the file even moves.
Resumes, idempotency, and not corrupting things
Drop a connection mid-transfer on FTP and you're often re-uploading from scratch or, worse, left with a half-written file and no clean way to know it's broken. Rsync resumes from where it stopped with --partial, verifies integrity via checksums, and only replaces the destination once the transfer completes — so an interrupted run doesn't leave corrupted garbage in place. Rsync is also idempotent: run it twice, the second run is nearly instant because nothing changed. That makes it safe to wedge into cron, CI pipelines, and deploy scripts without fear. FTP gives you none of this for free. You'd be scripting retry logic, integrity checks, and atomic swaps by hand — reimplementing, badly, what rsync ships out of the box. For backups and deploys specifically, this reliability gap is the whole ballgame.
The only honest case for FTP
FTP isn't dead because it's good — it's alive because some systems give you no choice. Managed hosting panels, ancient CMS installs, certain enterprise appliances, and a handful of vendor data-exchange setups still only accept FTP or FTPS. If that's your constraint, you use it, and you use FTPS so you're not broadcasting passwords. There's also the thin argument that FTP clients with GUIs are friendlier for non-technical users doing one-off uploads — fine, but SFTP clients fill that same niche without the cleartext sin. What you should not do is reach for FTP out of muscle memory for a job where you control both ends and have SSH. That's the common case, and in the common case rsync is faster, safer, and more reliable. FTP is the answer to 'what am I forced to use,' never 'what should I use.'
Quick Comparison
| Factor | Ftp | Rsync The Verdict |
|---|---|---|
| Transfer efficiency | Re-sends entire files every time, stateless | Delta algorithm sends only changed blocks |
| Security (default) | Cleartext credentials and data; needs FTPS bolt-on | Runs over SSH: encrypted, key-based, single port |
| Resume & integrity | Poor resume; can leave half-written files | --partial resume, checksums, atomic replace, idempotent |
| Firewall/NAT friendliness | Dual-channel passive-mode port-range pain | One port (22) the firewall already trusts |
| Forced-compatibility reach | Universally supported, including legacy/vendor systems | Needs rsync or SSH on both ends |
The Verdict
Use Ftp if: A legacy appliance, mainframe, or vendor system only speaks FTP/FTPS and you have no SSH access — then you're stuck with it, so use FTPS, never plain FTP.
Use Rsync The Verdict if: You control both ends and can run SSH — which is nearly always. Deploys, backups, mirroring directories, and syncing large datasets all belong to rsync.
Consider: SFTP (SSH file transfer) is the sane middle ground if you need an interactive transfer protocol but want FTP's plaintext nightmare gone — but for repeated syncs, rsync still beats it.
Rsync only sends the bytes that changed, runs over SSH by default, and resumes interrupted transfers without re-sending the whole file. FTP sends everything every time, ships credentials in plaintext, and needs FTPS bolted on to be remotely safe. Unless a vendor literally only accepts FTP, rsync is the correct tool.
Related Comparisons
Disagree? nice@nicepick.dev