How to Back Up and Restore Cisco Device Configurations: Complete Guide with Best Practices

Every network engineer has a story about the config that wasn’t backed up when it needed to be — a bad write memory after a fat-fingered ACL, a switch that dies at 2 AM with no recent copy of its running-config anywhere, a rushed firmware upgrade that wipes NVRAM. Configuration backup isn’t glamorous work, but it’s the single highest-leverage thing you can do to make outages short instead of catastrophic. This guide covers the full picture: how Cisco devices store configuration, every practical method for backing it up, how to restore it correctly, and the automation patterns that make this a non-issue instead of a fire drill.

Understanding Where Configuration Lives

On a Cisco IOS/IOS-XE device, there are two configuration files that matter:

• running-config — held in RAM, this is the active configuration the device is currently using. It’s lost on reboot unless saved.
• startup-config — held in NVRAM, this is what the device loads on boot. This is your persistent configuration.

The command that copies one into the other is the single most important command in Cisco administration:

Router# copy running-config startup-config

or the shorthand:

Router# write memory

Everything else in this guide is really about getting a copy of one of these files off the device and onto external, durable storage — because NVRAM on a single device is not a backup strategy, it’s just where the device itself keeps its own copy.

Backup Methods Overview

Part 1: Manual Backup via TFTP

TFTP is the classic method — simple, unauthenticated, UDP-based. Fine for lab and trusted management networks; avoid it over untrusted links since it has no encryption or authentication.

Step 1 — Set Up a TFTP Server

Any TFTP server software works (SolarWinds TFTP Server, tftpd64, or a Linux tftpd-hpa instance). Confirm it’s listening and reachable from the device’s management interface.

Step 2 — Copy the Running Config to the TFTP Server

Router# copy running-config tftp:
Address or name of remote host []? 10.10.1.50
Destination filename [R1-confg]? R1-running-2026-07-29.cfg

Expected output:

!!
1483 bytes copied in 0.512 secs (2897 bytes/sec)

Step 3 — Verify the File on the Server

Check the TFTP server’s root directory for the file and open it to confirm it’s a complete, readable configuration (not zero bytes, which usually indicates a permissions or path issue on the server side).

Part 2: Backup via SCP (Secure, Recommended for Production)

SCP encrypts the transfer and requires authentication, making it the preferred method for any production environment.

Step 1 — Enable SSH and SCP Server Functions (if backing up FROM the device via a pull, skip this and just configure SCP client mode)

For a push from the router to a remote SCP server (most common pattern):

Router(config)# ip scp server enable
Router(config)# aaa new-model
Router(config)# username admin privilege 15 secret StrongPassword123!
Router(config)# aaa authentication login default local
Router(config)# aaa authorization exec default local

Step 2 — Copy Config via SCP

Router# copy running-config scp:
Address or name of remote host []? 10.10.1.60
Destination username [admin]? backupuser
Destination filename [R1-confg]? R1-running-2026-07-29.cfg
Password: ********

Expected output:

!
1483 bytes copied in 1.204 secs (1232 bytes/sec)

Part 3: Backup to a USB Flash Drive (Offline/Air-Gapped)

Useful for devices without network reachability to a backup server, or as a secondary local copy during major changes.

Router# dir usbflash0:
Router# copy running-config usbflash0:R1-running-backup.cfg

Expected output confirms the file is written; verify with:

Router# dir usbflash0:

Part 4: Automated, Version-Controlled Backups with RANCID or Oxidized

For any network beyond a handful of devices, manual backups don’t scale and don’t get done consistently. RANCID (Really Awesome New Cisco confIg Differ) and its more modern alternative Oxidized are purpose-built tools that:

• SSH into every device in an inventory list on a schedule (commonly via cron, hourly or nightly).
• Pull the running-config automatically.
• Commit changes to a Git (or CVS/SVN) repository, so every configuration change in the network’s history is diffable and reversible.
• Email a diff to the network team whenever a config changes unexpectedly — often the first sign of an unauthorized or accidental change.

A minimal Oxidized router.db inventory entry looks like:

R1-CoreSwitch:10.10.1.5:ios
R2-Branch:10.10.2.5:ios
FW1-ASA:10.10.3.5:asa

Oxidized then handles the SSH pull, credential management (via its config file, ideally referencing a vault rather than plaintext), and Git commits automatically. This is the recommended approach for any production network of meaningful size — it turns “did anyone back up the core switch last week” into a solved problem that requires zero manual effort.

Part 5: Restoring a Configuration

Restoring the Full Running Configuration

Restoring by copying a saved file back into running-config merges it with the current configuration — it does not replace it outright. This is a critical distinction:

Router# copy tftp: running-config
Address or name of remote host []? 10.10.1.50
Source filename []? R1-running-2026-07-29.cfg
Destination filename [running-config]?

Because this is a merge, any configuration added after the backup was taken (and not present in the backup file) will remain — the restore doesn’t roll those changes back automatically. For an incident where you specifically need to undo unwanted recent changes, a merge might leave stale config behind.

Restoring by Replacing (True Rollback)

To fully replace the running configuration with a saved file — removing anything not present in that file — use configure replace instead:

Router# copy tftp: flash:R1-rollback.cfg
Router# configure replace flash:R1-rollback.cfg
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]: yes

Expected output confirms the number of lines added/removed and that the operation succeeded. This is the correct tool for true configuration rollback, and it’s non-disruptive — it calculates a diff and applies only the necessary changes rather than reloading the device.

Restoring startup-config Directly (Full Device Recovery)

If a device has lost its configuration entirely (e.g., after a factory reset or RMA), copy the backup straight to startup-config, then reload:

Router# copy tftp: startup-config
Router# reload

Real-World Enterprise Scenario: Pre-Change Backup Workflow

Before any planned maintenance window on core infrastructure, a disciplined workflow looks like this:

1. Take a fresh backup immediately before the change: copy running-config tftp: (or trigger an out-of-cycle Oxidized pull).
2. Save the current config’s checksum/archive as <hostname>-preChange-YYYYMMDD.cfg.
3. Make the planned changes.
4. If something goes wrong, use configure replace flash:<hostname>-preChange-YYYYMMDD.cfg to instantly revert, rather than trying to manually undo each change under pressure.
5. Once confirmed stable, save the new running-config to startup-config and let the automated backup system pick up the new baseline on its next scheduled run.

Best Practices

• Never rely on startup-config alone as your backup. If the device’s flash/NVRAM fails, that “backup” fails with it — always keep copies off-device.
• Automate. Manual backups get forgotten. RANCID/Oxidized (or Cisco DNA Center / Prime Infrastructure in larger enterprises) should run on a schedule without human intervention.
• Version control everything. Git-backed config history lets you answer “what changed and when” in seconds instead of hours of guessing.
• Encrypt credentials and transport. Prefer SCP/SFTP over plain TFTP/FTP wherever the network path isn’t fully trusted.
• Test restores periodically. A backup you’ve never restored from is an assumption, not a verified capability — periodically practice a restore in a lab environment.
• Back up before and after every change, not just on a fixed schedule, so you always have a clean rollback point tied to a specific maintenance window.

Common Configuration Mistakes

• Assuming copy running-config startup-config is a “backup” — it only protects against a reboot losing unsaved changes, not against device failure or accidental misconfiguration.
• Using copy tftp: running-config when a full replace was intended, resulting in stale/unwanted configuration lines persisting after the “restore.”
• Storing backup files with generic, non-timestamped filenames, making it impossible to tell which backup corresponds to which point in time.
• Not securing the backup server itself — configuration backups often contain sensitive information (SNMP communities, local usernames, sometimes even encrypted or weakly obfuscated passwords) and deserve the same access controls as production systems.
• Forgetting to back up ancillary files (VLAN database on older platforms, ACL definition files, licensing information) that aren’t always part of the main running-config.

Troubleshooting

TFTP copy fails with “Error opening tftp://… (Timed out”) Confirm the TFTP server is running, listening on UDP 69, reachable (ping), and that no ACL on the device’s management interface is blocking outbound UDP 69.

SCP copy fails with authentication error Confirm ip scp server enable is set if pulling from the device, verify the username/password or SSH key, and check aaa authentication login and aaa authorization exec are correctly pointing at a valid method list.

configure replace fails or is rejected Ensure the target file is a complete configuration (not a partial snippet) — configure replace expects a full config, and will warn or fail if it detects an incomplete file. Also confirm the file exists in local flash (copy it there first if pulling from a remote server).

FAQs

How often should configs be backed up? At minimum, nightly automated backups for all production devices, plus an on-demand backup immediately before and after any planned change.

Is write memory the same as a backup? No — it only saves running-config into the device’s own NVRAM as startup-config. That protects against a reboot, not against hardware failure, theft, or a bad change you need to roll back from.

What’s the safest way to test a restore without risking a production device? Restore the backup file into a lab device or virtual instance (e.g., a CML/EVE-NG virtual router) running comparable software, and confirm it boots cleanly and matches expected configuration.

Can Cisco DNA Center or Prime Infrastructure replace RANCID/Oxidized? Yes, for organizations already invested in those platforms — both include scheduled configuration archiving, compliance checking, and rollback features, but they come with licensing costs that RANCID/Oxidized (both free/open-source) avoid.

Summary

Configuration backup on Cisco devices is really about moving a copy of running-config (or startup-config) off the device onto durable, ideally version-controlled storage, on a reliable schedule — not just before disasters, but as routine practice. TFTP and SCP cover manual/scripted transfers, with SCP preferred for anything production-facing due to encryption and authentication. For restoring, understand the critical difference between a merge (copy ... running-config) and a true replace (configure replace), since using the wrong one during an incident can leave unwanted configuration behind. And for any network beyond a handful of devices, automate the whole process with a tool like RANCID or Oxidized so backups happen whether or not anyone remembers to run them.

References

• Cisco: Using the copy Command — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/configuration/xe-16/fundamentals-xe-16-book/cf-file-mgmt.html
• Cisco: configure replace and configure confirm Commands — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/command/cf_command_ref/c_5.html
• Cisco: Managing Configuration Files — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/configuration/xe-16/fundamentals-xe-16-book/cf-mgmt-config-files.html