CCNA online course

Backing Up and Restoring Cisco IOS Device Configurations

Learn how Cisco IOS stores configurations and how to save, verify, back up, transfer, restore, and troubleshoot router and switch configuration files.

A Cisco IOS device uses more than one place to hold configuration information. The running configuration is active in RAM, while the startup configuration is saved for the next boot. Understanding this distinction prevents accidental loss of changes and makes recovery procedures safer.

This lesson covers local saves, flash and USB copies, TFTP transfers, authenticated transfer alternatives, verification, restoration, and operational backup practices. Basic IOS command modes, IPv4 addressing, interface configuration, and ping knowledge are assumed. For related fundamentals, see the computer networking and OSI reference model lessons.

How Cisco IOS Stores Configuration

The running-config is the active configuration currently held in volatile RAM. IOS uses it immediately to operate interfaces, routing protocols, access rules, management services, and other features.

The startup-config is the saved configuration normally stored in nonvolatile NVRAM. IOS reads it during boot and uses it to build the running configuration. If you change the running configuration but do not save it, the changes are normally lost after a reload or power failure.

Flash is persistent storage commonly used for IOS images and other local files. It can also hold an emergency configuration copy, although a file in flash is not automatically the startup configuration. Some platforms provide USB storage such as usbflash0:. Remote files may be stored on TFTP, FTP, or SCP servers.

View and Verify the Current Configuration

Before making a backup, determine which configuration contains the intended state. Use these commands from privileged EXEC mode:

show running-config
show startup-config

show running-config displays the active configuration in RAM. show startup-config displays the saved boot configuration. Compare them when you need to find unsaved changes. On platforms that support it, show configuration or a platform-specific equivalent may expose configuration information in a different form; use show ? to inspect available commands.

Verify more than the text of the configuration. Confirm the device identity, management address, interface state, routing, and enabled services:

show running-config | section hostname
show ip interface brief
show interfaces <interface-id>
show ip route
show running-config | section interface
ping <server-address>

For a switch, also check the management VLAN interface and default gateway. A Layer 2 switch commonly uses an SVI for management:

interface vlan <management-vlan>
 ip address <switch-management-ip> <subnet-mask>
 no shutdown
exit
ip default-gateway <gateway-address>

The exact configuration depends on the platform. A routed switch may use a routed management interface and a routing table instead of ip default-gateway.

Save the Active Configuration Locally

After approved changes, save the active configuration so it will be available after the next reload:

copy running-config startup-config

IOS may ask for a destination filename. Press Enter to accept the displayed default, unless your platform or procedure requires another name. A successful operation normally displays a message indicating that the configuration was written or copied successfully.

The shortcut is:

write memory

write memory is widely recognized, but copy running-config startup-config is clearer for beginners because it explicitly shows the source and destination. After saving, verify the result:

show startup-config

Confirm that important recent changes, such as interface addresses, routing statements, VLAN settings, and management services, appear in the saved configuration.

Back Up to a TFTP Server

TFTP, or Trivial File Transfer Protocol, is a simple UDP-based file transfer service commonly used in labs and some legacy environments. TFTP typically uses UDP port 69 for the initial request. It provides little security, so do not treat it as a protected backup system.

Prerequisites

• The IOS device must be able to reach the TFTP server at Layer 3.
• You need the correct server address and a working route, or a correct default gateway.
• The TFTP service must be running and UDP port 69 and related return traffic must be permitted.
• The server must permit uploads and the destination directory must exist or be writable according to server policy.
• The server must have sufficient storage.
• The device management interface must have a valid IP address, subnet mask, and operational status.

Test reachability before starting the copy:

show ip interface brief
show ip route
ping <server-address>

On a switch, check the SVI, VLAN membership, and default gateway. On a router, check the relevant routed interface and route toward the server.

Interactive TFTP Copy

To back up the active configuration, enter:

copy running-config tftp:

To back up the saved boot configuration, enter:

copy startup-config tftp:

IOS usually prompts for the remote server address and destination filename. A typical workflow is:

Router# copy startup-config tftp:
Address or name of remote host []? <server-address>
Destination filename [router-confg]? branch-rtr-2026-08-16-startup-v1.cfg
Writing ... !!
[OK]

Use a descriptive, unique filename that identifies the device, date, site, and configuration version. For example, branch-rtr-2026-08-16-startup-v1.cfg is more useful than backup.cfg.

Noninteractive Syntax

Where supported by the IOS release, specify the server and filename in the source or destination URL:

copy running-config tftp://<server-address>/<backup-filename>
copy startup-config tftp://<server-address>/<backup-filename>

Syntax and prompts can differ by platform. Use copy ? when in doubt. Verify the transfer in two places: inspect the IOS completion message and confirm that the expected file exists in the TFTP server's configured directory. If your TFTP application provides transfer logs, check those as well.

Restore a Configuration from TFTP

Restoration is potentially disruptive. First obtain and inspect the source file. Pay particular attention to:

• Enable, console, local-user, and SSH credentials.
• Management interface addresses, VLANs, and default gateways.
• Physical interface addresses and shutdown states.
• Static routes and routing protocol settings.
• VLAN definitions and trunk or access settings.
• Access control lists, NAT, VPN material, and management restrictions.

Restore to the running configuration with:

copy tftp: running-config

Or, where supported:

copy tftp://<server-address>/<backup-filename> running-config

This applies the received commands immediately. It generally merges commands with the existing running configuration. It does not automatically erase every command that is absent from the source file. Therefore, an incorrect ACL, route, interface command, or service can remain unless the source contains an explicit negating command or you remove it separately.

Restore to the startup configuration with:

copy tftp: startup-config

Or:

copy tftp://<server-address>/<backup-filename> startup-config

This changes the configuration saved for boot. It does not normally change the current running configuration immediately. The restored startup configuration takes effect after a reload, unless you separately copy it into running-config or use a planned recovery procedure.

Safe Restore Sequence

1. Preserve the current known-good configuration by copying it to a uniquely named local or remote file.
2. Inspect the candidate backup and confirm device model, IOS version, interfaces, addressing, routing, VLANs, credentials, and access rules are appropriate.
3. Use console access or an out-of-band management path for a high-risk restoration. Out-of-band access is independent of the production network.
4. Copy the file to the intended destination, understanding whether the operation merges into running-config or changes startup-config.
5. Check the running configuration, interface status, routes, management reachability, and required services.
6. Save only after validation. If a reload is required, schedule it with a recovery plan and a tested backup.

A restore can disconnect a remote session if it changes the management IP, management VLAN, route, ACL, SSH settings, or credentials. A configuration from another model or IOS release may also contain unsupported commands, different interface names, or feature syntax that requires adjustment.

Other Supported Copy Methods

IOS uses the copy command family to move configuration and image files among supported locations. Discover available filesystems and protocols with dir ? and copy ?.

copy startup-config flash:<backup-filename>
copy running-config flash:<backup-filename>
dir flash:
more flash:<backup-filename>

copy startup-config usbflash0:<backup-filename>
dir usbflash0:

Flash is convenient for an on-device emergency copy. USB is useful when the platform supports the device and filesystem. Both require physical or administrative protection because configuration files may contain sensitive information.

FTP supports authenticated file transfer on supported IOS platforms. SCP, or Secure Copy Protocol, uses SSH and encrypts the transfer in transit. Generic forms may include copy ... ftp: and copy ... scp:, but exact prompts, prerequisites, and URL syntax vary by IOS release and device platform. SCP commonly requires a functioning SSH configuration and suitable user authorization. Prefer authenticated and encrypted methods when permitted by the environment.

Operational Backup Practices

• Back up before disruptive or high-risk changes.
• Back up after approved changes and confirm that the saved version is the intended one.
• Use a recurring schedule appropriate to the device's change frequency and business impact.
• Use consistent names containing device identity, site, date, and configuration version.
• Record the device model, IOS version, backup source type, and time of collection.
• Restrict repository access and apply retention policies and version tracking.
• Protect backups because they may contain credentials, SNMP community strings, VPN material, ACLs, topology details, and internal addresses.
• Use encryption at rest and encryption in transit where possible. Avoid exposing configuration files through an unrestricted TFTP service.
• Periodically test that backups can be read and restored in a controlled environment.

A configuration backup is sensitive operational data, not merely a text file. Store it in a controlled repository with auditability and an established retention and deletion process.

Verification and Troubleshooting

After a backup, confirm the correct source was copied and that the destination contains the expected file. After a restore, inspect the active or saved destination—not just the transfer message.

show running-config
show startup-config
show ip interface brief
show interfaces <interface-id>
show ip route
ping <server-address>

Use TFTP debugging only in a controlled lab or maintenance window:

debug tftp
undebug all

Debug output can consume device resources and obscure other events. Disable debugging immediately after collecting useful evidence.

Practical Workflows

Save Changes Before a Reboot

show running-config
copy running-config startup-config
show startup-config

Check that the interface and routing changes appear in both the active and saved configurations before rebooting.

Create a Pre-Change TFTP Backup

show ip interface brief
show ip route
ping <server-address>
copy startup-config tftp://<server-address>/branch-rtr-2026-08-16-prechange-v1.cfg

If the active configuration contains unsaved changes that must also be preserved, export running-config instead. Confirm the file on the server before beginning the change.

Create a Local Emergency Copy

copy startup-config flash:branch-rtr-known-good.cfg
dir flash:
more flash:branch-rtr-known-good.cfg

This file is a separate flash backup. It does not replace startup-config unless you deliberately copy it to that destination.

Recover from an Incorrect ACL or Route

1. Secure console or out-of-band access before changing a remote device.
2. Preserve the current state in a uniquely named backup.
3. Inspect the known-good source file for addressing, routing, VLAN, credentials, and access rules.
4. Copy it into running-config only when the merge behavior is acceptable, or use a planned replacement procedure when a clean state is required.
5. Check interfaces, routes, access rules, services, and management access.
6. Copy the validated result to startup-config.

Key Takeaways

• running-config is active in RAM; startup-config is the boot-time configuration normally stored in NVRAM.
• Unsaved running changes are lost after reload or power loss.
• Use copy running-config startup-config to save the intended active state.
• Use TFTP only after validating reachability, UDP service availability, permissions, and destination storage.
• Copying a remote file into running-config applies an immediate merge and may not remove old commands.
• Copying a remote file into startup-config changes the next-boot configuration but does not normally change the current running state.
• Use flash or USB for local copies and FTP or SCP when supported and appropriate; prefer secure, controlled repositories.
• Always preserve a known-good backup and an independent management path before a high-risk restore.

For password-related configuration details, review configuring passwords in IOS. Configuration backup is also closely connected to change management, secure SSH administration, and routing configuration verification such as OSPF configuration.