Sooner or later every engineer copies something onto or off a router: a config backup before a risky change, a new IOS image, a crash dump for TAC. The two classic transports are TFTP and FTP, they behave very differently, and the CCNA expects you to know when each is appropriate. This article backs up a real Cisco IOS XE config over both protocols to a Linux server, with the genuine transfer output (including an honest speed difference), as part of the IP Services complete guide.
Two Protocols, Two Philosophies
UDP port 69. No authentication, no directory listing, no encryption. Lock-step transfer: one 512-byte block, one ack, repeat. Trivial to serve, painfully simple, slow on anything big.
TCP ports 21 (control) + 20/negotiated (data). Username/password authentication, directory operations, TCP windowing for speed. Still cleartext on the wire.
Config Backup over TFTP
TFTP needs zero configuration on the router. Point copy at a TFTP URL and accept the prompts:
R1#copy running-config tftp://192.168.99.100/R1-confg
Address or name of remote host [192.168.99.100]?
Destination filename [R1-confg]?
.!!
2425 bytes copied in 4.243 secs (572 bytes/sec)572 bytes per second. That is not a broken lab: it is the lock-step protocol doing one small block per round trip (the leading . in .!! is a retry, also normal for the first datagram while the server process wakes up). For a 2 KB config it does not matter. For a 700 MB IOS XE image, do the math and pick something else.
Config Backup over FTP
FTP needs credentials, configured once globally:
R1(config)#ip ftp username j
R1(config)#ip ftp password Cisco@123Then the same copy syntax with an ftp:// URL:
R1#copy running-config ftp://192.168.99.100/R1-backup.cfg
Address or name of remote host [192.168.99.100]?
Destination filename [R1-backup.cfg]?
Writing R1-backup.cfg !
2469 bytes copied in 0.525 secs (4703 bytes/sec)Same file, same network path, roughly eight times faster (4703 vs 572 bytes/sec), because TCP streams instead of lock-stepping. You can also put credentials inline (ftp://user:pass@host/file), but that leaves the password in command history; the global config approach is the cleaner habit, and either way treat FTP credentials as disposable because they cross the wire in cleartext.
The Other Direction: Restoring to the Router
Downloads use the same command with source and destination swapped. On this virtual platform the writable filesystem is called unix: (on physical hardware you will use flash: or bootflash:, same syntax):
R1#copy tftp://192.168.99.100/R1-confg unix:R1-restore.cfg
Destination filename [R1-restore.cfg]?
Accessing tftp://192.168.99.100/R1-confg...
Loading R1-confg from 192.168.99.100 (via Ethernet0/0): !
[OK - 2425 bytes]
2425 bytes copied in 0.028 secs (86607 bytes/sec)
R1#dir unix: | include cfg
2624242 -rw- 2425 Jul 10 2026 22:57:07 +00:00 R1-restore.cfgshow file systems lists what filesystems your platform actually has, which is worth a look before any image work. Note the classic restore trap: copying a config to running-config merges it with what is there, it does not replace it. For a true replacement, copy to startup-config and reload, or use configure replace.
What the Server Side Sees (and a Security Lesson)
Both files landed on the Linux server, and the listing quietly teaches the security difference:
j@llmbits:~$ ls -l /srv/tftp/R1-confg /home/j/R1-backup.cfg
-rw-rw-rw- 1 tftp tftp 2425 Jul 10 15:56 /srv/tftp/R1-confg
-rw------- 1 j j 2469 Jul 10 15:56 /home/j/R1-backup.cfgThe FTP upload is owned by the authenticated user with private permissions. The TFTP upload sits in a world-writable directory owned by a daemon account, because TFTP has no concept of identity: anyone who can reach UDP 69 can read (and depending on server flags, overwrite) what is there. Your startup configs contain password hashes and SNMP strings; a TFTP directory full of them is a reconnaissance jackpot. Keep TFTP servers on isolated management segments and empty them when the maintenance is done.
The Workflow That Actually Matters: Image Upgrades
Config backups are the daily habit, but the high-stakes transfer is an IOS image. The discipline around it matters more than the protocol. Before anything: show file systems and dir to confirm free space, because a transfer that fills the filesystem mid-write leaves you with a truncated image and no room to fix it. After the copy, verify integrity before you ever point the boot system at it:
R1#verify /md5 flash:cat9k_iosxe.17.09.05.SPA.bin
! compare the digest against the one on Cisco's download pageA flipped bit in a 700 MB transfer over UDP-based TFTP is not hypothetical, and a corrupt image discovered at reload time is a very different evening than one discovered by verify /md5. Then stage the boot variable (boot system flash:<new-image>), save, and reload in a window. Keep the old image on flash until the new one has survived a week; disk space is cheaper than a rollback without media.
For recurring config protection there is also the built-in archive feature, which snapshots on every write and can push each snapshot to your FTP/TFTP/SCP server automatically:
archive
path ftp://192.168.99.100/backups/R1
write-memoryWith that in place, every write memory quietly ships a timestamped config copy off-box, which converts "when was the last good backup?" from an archaeology project into a directory listing.
Which One When (and the Modern Answer)
Use TFTP for small, quick, disposable transfers inside a protected management network: a config snapshot before a change window, a boot helper for appliance recovery (ROMMON environments often speak only TFTP, which is the real reason the protocol refuses to die). Use FTP when the file is big (IOS images) or when you want per-user accounting on the server. And for anything crossing untrusted networks, skip both: IOS XE speaks SCP and SFTP natively (copy running-config scp://user@host/R1.cfg, after enabling ip scp server enable for the inbound case), giving you SSH encryption and authentication with the same copy syntax. Automated config backup at scale usually rides SSH anyway, driven by automation tooling rather than hand-typed copies.
Key Takeaways
TFTP is UDP 69, unauthenticated, lock-step slow (572 B/s in the real capture), and perfect only for small files on trusted segments; FTP is TCP 21/20 with credentials and TCP speed (4703 B/s, same file, same path). The copy command is symmetric: URL as source restores, URL as destination backs up, with flash:/unix: naming varying by platform. Remember copy-to-running merges rather than replaces, keep TFTP directories clean because they are readable by anyone, and reach for SCP when security matters. The rest of the operational toolbox is in the IP Services complete guide.
