Cisco / IOS · Tutorial · July 2026

Cisco IOS
Backup & Restore

A router config is only as safe as its last backup. Save to startup, export off-box to TFTP or SCP, automate it with the archive feature and kron, roll back a bad change with configure replace, and recover a device nobody has the password to.

Cisco IOS Backup TFTP Archive Config Replace Recovery CCNA

There are three places a Cisco config can live, in increasing order of safety. running-config (RAM) is what's live right now and dies on reboot. startup-config (NVRAM) is what boots and survives a power cut. And an off-box copy — on a TFTP/SCP server or in a git repo — is the only thing that survives the device itself dying, being stolen, or being wiped by a bad command.

Most outages caused by "we lost the config" are really "we only ever saved to startup." This tutorial covers all three tiers, then the parts that separate a technician from a professional: automating backups so they happen without you, rolling back a bad change in one command with configure replace, and recovering a device when the password is long gone.

Prerequisites

Comfort with the IOS CLI and Privileged EXEC — see Cisco IOS: First Contact
A reachable TFTP or SCP server for off-box copies (any laptop can run one)
For recovery: physical console access to the device

Tier 1 — Save to Startup

The first and most-forgotten step. Your changes are live but volatile until you copy running-config into startup-config. This is the "type wr after every change" habit.

IOS — save the running config

# The explicit form
R1# copy running-config startup-config
Destination filename [startup-config]? ← press Enter
Building configuration...
[OK]

# The shortcut everyone types — identical result
R1# write memory       # or just:  wr

# Did anything change since the last save? Compare the two.
R1# show archive config differences nvram:startup-config system:running-config
# Empty output = running and startup match. Non-empty = unsaved changes.

Tier 2 — Export Off-Box (TFTP / SCP)

NVRAM dies with the device. An off-box copy is the real backup. TFTP is the classic (and insecure) transport; SCP is the same idea over SSH and is what you should use in production.

IOS — copy the config to a TFTP server

R1# copy running-config tftp:
Address or name of remote host []? 192.168.1.50
Destination filename [r1-confg]? R1-2026-07-10.cfg
!!
1846 bytes copied in 0.4 secs

# Pull it back the same way (careful — see the merge gotcha in section 03)
R1# copy tftp: running-config

IOS — the secure version over SCP (SSH)

# One-liner: source, then the full scp:// destination URL
R1# copy running-config scp://backup@192.168.1.50/R1-2026-07-10.cfg
Address or name of remote host [192.168.1.50]? 
Password: 
1846 bytes copied in 0.5 secs

# To let the device RECEIVE scp pushes, enable the server side:
R1(config)# ip scp server enable
# (requires SSH + a local AAA user — see the SSH section of "First Contact")

💡 Pro Tip — TFTP Is Clear-Text; Don't Use It Over Untrusted Links

TFTP has no authentication and no encryption — your entire config, including (weakly) encrypted password hashes, crosses the wire in the clear. It's fine on an isolated management segment for a quick copy, but for anything crossing a real network use SCP. Same muscle memory, wrapped in SSH. If a config is worth backing up, it's worth not broadcasting.

Restoring — The Merge Trap

The single most dangerous misconception in Cisco backup. Copying a config INTO running-config does not replace it — it merges. This surprises everyone once, usually painfully.

⚠ Gotcha — copy … running-config MERGES, It Does Not Replace

When you copy tftp: running-config, IOS applies the backup on top of what's already running. Commands that exist get overwritten; commands in the live config that aren't in the backup stay put. So restoring an old backup does not return the device to that old state — you get a Frankenstein merge of both. To truly replace the running config, either copy to startup and reload, or use configure replace (section 04).

IOS — the two honest ways to restore

# Option A — restore to STARTUP, then reboot into a clean state
R1# copy tftp: startup-config
R1# reload
# The device boots entirely from the restored file. Clean, but a reboot.

# Option B — replace the RUNNING config live, no reboot (section 04)
R1# configure replace tftp://192.168.1.50/R1-good.cfg

The Archive Feature & One-Command Rollback

IOS can keep automatic versioned snapshots of the config and roll back to any of them live — no reboot, no merge. This is the professional safety net for risky changes.

IOS — enable config archiving

R1(config)# archive
R1(config-archive)# path flash:/archive/R1-config
R1(config-archive)# maximum 14          # keep 14 versions
R1(config-archive)# time-period 1440     # auto-snapshot every 1440 min (daily)
R1(config-archive)# write-memory         # also snapshot on every "wr"
R1(config-archive)# end

# Take a snapshot on demand, and list what's stored (safe)
R1# archive config
R1# show archive
 The maximum archive configurations allowed is 14.
 Archive #  Name
   1        flash:/archive/R1-config-1
   2        flash:/archive/R1-config-2  <- Most Recent

IOS — roll back a bad change in one command

# You made a change, it broke something. Roll the RUNNING config back to
# a known-good snapshot — live, no reboot, a true replace (not a merge).
R1# configure replace flash:/archive/R1-config-1
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: y
Total number of passes: 1
Rollback Done

# Even safer for remote changes: auto-rollback if you lose the session
R1# configure terminal revert timer 5
# Make your changes; if you don't "configure confirm" within 5 minutes,
# IOS reverts automatically. Your parachute for remote config work.

💡 Pro Tip — reload in 5 Is the Poor Man's Auto-Rollback

No archive configured and about to make a scary change on a remote device? Type reload in 5 before you start. If your change locks you out, the device reboots in 5 minutes back to the last saved startup-config. If everything's fine, cancel it with reload cancel. It's crude — it costs a reboot and only reverts to startup — but it has saved countless admins stuck 300 km from the rack.

Automating Backups with kron

A backup you have to remember to run is a backup you won't have. IOS has a built-in scheduler — kron — that can push the config off-box on a timer, with no external tooling.

IOS — scheduled nightly config export

# 1. Define WHAT to run — a policy that copies running-config to SCP
R1(config)# kron policy-list NIGHTLY-BACKUP
R1(config-kron-policy)# cli copy running-config scp://backup@192.168.1.50/R1-nightly.cfg
R1(config-kron-policy)# exit

# 2. Define WHEN — every day at 02:00, recurring
R1(config)# kron occurrence NIGHTLY at 2:00 recurring
R1(config-kron-occurrence)# policy-list NIGHTLY-BACKUP
R1(config-kron-occurrence)# end

# Verify the schedule (safe)
R1# show kron schedule
Kron Occurrence Schedule
  NIGHTLY inactive, will run again in 0 days 13:41:22

⚠ Gotcha — kron Runs Commands from Privileged EXEC, Non-Interactively

Kron executes each cli line as if typed at the # prompt — but there's no human to answer prompts. Commands that ask a question (like an interactive copy that prompts for a filename) can stall. Use fully-qualified one-line forms with the destination baked into the URL, as above, so nothing needs answering. Test the exact command by hand once before trusting the schedule.

Backing Up the IOS Image

Config is not the only thing worth saving. A corrupt or deleted IOS image turns a switch into a paperweight. Keep a copy of the .bin off-box too.

IOS — what's in flash, and copy the image out

# See the image files and free space (safe)
R1# show flash:
-#- --length-- -----date/time------ path
  1   45088768 Jul 10 2026 09:14:02 c2900-universalk9-mz.SPA.157-3.M9.bin
  2       1846 Jul 10 2026 10:02:11 R1-2026-07-10.cfg

# Copy the image to your server (note the exact filename from above)
R1# copy flash:c2900-universalk9-mz.SPA.157-3.M9.bin tftp:
Address or name of remote host []? 192.168.1.50
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
45088768 bytes copied in 78.2 secs

# Confirm integrity against Cisco's published hash
R1# verify /md5 flash:c2900-universalk9-mz.SPA.157-3.M9.bin

Password Recovery Console Required

Inherited a device nobody has the password to? You don't wipe it. You boot around the startup-config using the configuration register, recover the config, and reset the passwords. Physical console access is mandatory — which is exactly why console security matters.

IOS — router password recovery (via ROMMON)

# 1. Console in, power-cycle, and send a BREAK during boot to reach ROMMON
rommon 1 > confreg 0x2142   # tell it to IGNORE startup-config on next boot
rommon 2 > reset

# 2. It boots with a blank running-config (setup wizard) — say no. Then
#    load the REAL config from NVRAM into running WITHOUT its passwords taking effect:
Router> enable
Router# copy startup-config running-config   # your config is back, and you're already privileged

# 3. Set a new password and make sure interfaces you need are not shut
Router# configure terminal
Router(config)# enable secret NewStr0ng!Pass

# 4. CRITICAL: restore the config register so it boots normally next time
Router(config)# config-register 0x2102
Router(config)# end

# 5. Save and reboot
Router# write memory
Router# reload

⚠ Gotcha — Don't Forget Step 4

If you skip config-register 0x2102, the device keeps ignoring its startup-config on every future boot — it'll come up blank each time and you'll think the recovery failed. Confirm with show version (last line shows the configuration register). Switches use a slightly different procedure (hold the MODE button during boot, then flash_init / rename flash:config.text) but the idea is the same: boot around the config, recover it, reset the password, restore normal boot.

Command Reference

The backup and recovery commands worth committing to memory.

Command	What it does
copy run start · wr	Save running-config to NVRAM (survives reboot).
copy run tftp: / scp:	Export the config off-box. SCP for anything untrusted.
copy tftp: startup-config	Restore to startup — then `reload` for a clean replace.
configure replace <file>	Replace the running config live — a true replace, no reboot.
archive config	Take a versioned config snapshot now.
show archive	List stored config versions.
show kron schedule	See scheduled automated jobs.
show flash: / dir flash:	List files and free space (config + IOS image).
reload in 5 / reload cancel	Arm / disarm a safety reboot before a risky change.
config-register 0x2102	Normal boot (0x2142 = ignore startup, for recovery).

Takeaways

Three tiers, increasing safety: running (RAM) → startup (NVRAM, wr) → off-box (TFTP/SCP/git). Only the third survives the device itself dying. Most "we lost the config" outages are really "we only saved to startup."
Restoring into running-config MERGES, it doesn't replace. To truly return to an old state, restore to startup and reload, or use configure replace. This gotcha bites everyone exactly once.
The archive feature is your live rollback. Versioned snapshots plus configure replace undo a bad change with no reboot and no merge. Turn it on before you need it.
Automate it or it won't happen. kron pushes the config off-box on a schedule with no external tooling — use fully-qualified one-line commands so nothing prompts.
Back up the IOS image too. A missing or corrupt .bin bricks the box. Keep a copy off-device and verify /md5 it.
Arm a parachute for remote changes. configure terminal revert timer or a plain reload in 5 auto-recovers you if a change cuts your own session.
Recovery needs the console. You can reset any password with physical access and the config register — which is precisely why the console port and physical security are part of your threat model, not an afterthought.

Managing Cisco gear for an office, hotel, or SMB in Crete?

NOCTIS sets up automated, off-site config backups and tested recovery procedures for every device we manage — so a dead switch is a 20-minute swap, not a lost weekend. We hand over the runbook too.

Book a Discovery Call →