Cisco Switch Config Backup and Recovery on IOS XE

A Cisco switch configuration backup is only as good as the restore it supports. On a Catalyst 9000 switch running IOS XE, a complete backup is the running configuration plus the VLAN database file, flash:vlan.dat, whenever the switch runs VTP server mode, and the restore plan has to account for SSH keys that never leave the switch. To put a saved state back, use configure replace: copying a file into the running configuration only adds commands, so the lines that caused the problem stay in place.

This guide is written for engineers who operate Catalyst 9000 switches in production. Commands were checked against Cisco’s Catalyst 9300 configuration guides and command reference for IOS XE 17.15, and the same Configuration Replace and Configuration Rollback chapter appears in Cisco’s IOS XE guides for the Catalyst 9200, 9500, and 9600. If the problem is a lost enable password, start with our Cisco switch password recovery guide.

Cisco Switch Backup Contents: Config, VLAN Database, and Keys

copy running-config captures everything that show running-config displays. Two things a working switch depends on are stored somewhere else, and one of them never leaves the switch at all.

Item	Where it lives	Included in a running-config backup?	What to do
Running configuration	Memory (system:running-config)	Yes	Copy it off the switch and archive it
Startup configuration	NVRAM (nvram:startup-config)	Separate file; matches the running configuration only after write memory	Back it up when it differs from the running copy
VLAN database	flash:vlan.dat by default	No, when the switch runs VTP server mode	Copy the file itself
RSA key pairs	Private configuration in NVRAM	No, never	Plan to regenerate keys on a replacement switch
Software release	Boot image, shown by show version	No	Record the release next to the backup

The VTP mode decides whether VLANs are part of the configuration file at all. Cisco’s Catalyst 9300 command reference for IOS XE 17.15 lists server as the default VTP mode and flash:vlan.dat as the default VLAN database file, so a switch that nobody moved to transparent mode keeps its VLAN definitions outside the configuration. Describing VTP version 3 server mode, Cisco’s VTP configuration guide states that “you also have to take a backup of the vlan.dat file.” In transparent or off mode, VLAN configuration is saved with the switch configuration and the running-config backup covers it. Run show vtp status before deciding what to collect.

RSA keys are the second gap. Cisco’s IOS XE security command reference for crypto key generate rsa explains that the keys are written to the private configuration in NVRAM, which is never displayed or copied to another device. A restored configuration brings back the SSH settings and local users but not the host key, so a replacement switch has no SSH service until a new key pair exists, and every management station that stored the old host key will report that it changed.

Record the software release with every backup. A configuration saved on one IOS XE release can contain commands that another release rejects, and a restore that silently skips lines is harder to trust than one that fails loudly.

Back Up a Cisco Switch Configuration

The copy command is the same for every destination; the choice is about transport security and whether the copy is still reachable when the switch is not. Saving with write memory or copy running-config startup-config writes to NVRAM on the same switch, which protects against a reload, not against a failed switch.

Backup to a TFTP or FTP Server

Switch# copy running-config tftp://192.0.2.10/sw-core1-running.cfg
Switch# copy startup-config tftp://192.0.2.10/sw-core1-startup.cfg
Switch# copy flash:vlan.dat tftp://192.0.2.10/sw-core1-vlan.dat

TFTP has no authentication and no encryption, so the file crosses the network in clear text. Keep TFTP on an isolated management network, or use SCP. FTP works the same way with an ftp:// URL and adds a login, but the transfer is still unencrypted.

Backup to an SCP or SFTP Server

SCP runs over SSH, and Cisco’s Secure Copy chapter for the Catalyst 9300 lists its prerequisites: SSH, AAA authentication and authorization, an RSA key pair on the switch, and a user at privilege level 15.

Switch# copy running-config scp://backup@192.0.2.20/sw-core1-running.cfg
Switch# copy flash:vlan.dat scp://backup@192.0.2.20/sw-core1-vlan.dat

The ip scp server enable command is needed only when a workstation pulls files from the switch, because it turns on the SCP server side. A switch that pushes its own backups acts as the client. SFTP is the other encrypted option and uses an sftp:// URL in the same copy syntax.

Backup to Local Flash or USB

Switch# mkdir flash:backup
Switch# copy running-config flash:backup/sw-core1-running.cfg
Switch# copy running-config usbflash0:sw-core1-running.cfg

On a Catalyst 9300, USB storage appears as usbflash0:. A local copy is the fastest thing to roll back to, but it fails with the switch, so keep at least one copy on another system.

Treat every backup file as a credential store. The configuration carries enable secret hashes, local user credentials, SNMP community strings, and key strings, so apply the same access controls and retention rules to the backup server that apply to the switch itself.

Cisco Configuration Archive for Automatic Backups

Manual copies depend on someone remembering to make them. The configuration archive gives the switch its own numbered history: each saved version gets the next number, the oldest version is deleted when the limit is reached, and every file in the archive is a valid target for configure replace.

archive
 path flash:sw-core1-config
 maximum 14
 time-period 1440
 write-memory
 log config
  logging enable
  logging size 500
  notify syslog contenttype plaintext
  hidekeys

Enter these lines under configure terminal, then take a first checkpoint and confirm it:

Switch# archive config
Switch# show archive
There are currently 1 archive configurations saved.
The next archive file will be named flash:sw-core1-config-2
 Archive #  Name
   1       flash:sw-core1-config-1 <- Most Recent

The real show archive output lists every slot up to the maximum; it is shortened here.

path sets the location and the filename prefix, so versions are saved as sw-core1-config-1, sw-core1-config-2, and so on; a directory path needs a trailing slash, as in flash:/archive/. maximum keeps between 1 and 14 versions, with a default of 10. time-period saves a version every set number of minutes, 1440 for daily. write-memory saves a version every time the configuration is written to NVRAM. Cisco’s Catalyst 9300 configuration guide for IOS XE 17.15 documents path, maximum, time-period, archive config, and show archive; write-memory and the log config options are defined for Catalyst 9000 in the IOS XE 17.15.1 configuration model that Cisco publishes.

Timed saves and write-memory saves share one numbered sequence and one limit. With maximum 14, a busy change day that includes a dozen write memory commands can push the last known-good daily version out of the archive before anyone notices it is needed. On switches that change often, take an explicit archive config checkpoint before each change window and keep an off-box copy of the version you would roll back to.

The log config block records configuration commands in a change log that keeps up to 1,000 entries, notify syslog sends the logged commands out as syslog messages, and hidekeys suppresses passwords when logged commands are displayed. With syslog collection in place, the question “what changed between version 6 and version 7” has an answer that does not depend on anyone’s memory.

The archive path can also point to a server, such as a tftp:// or scp:// location, which turns the archive into an off-box backup. A local archive rolls back in one command but disappears with the switch, so the usual pattern is a local archive for rollback plus a scheduled off-box copy. Teams running dozens of switches typically centralize that off-box copy in a network configuration management platform, and the on-box archive stays as the rollback source.

Restore a Cisco Switch Configuration

Restoring a saved state takes one of two operations on IOS XE, and they behave differently enough that choosing the wrong one leaves the problem in place.

Copy to Running-Config vs. Configure Replace

Behavior	copy <file> running-config	configure replace <file>
Removes commands that are not in the file	No	Yes
Reapplies commands that already exist	Yes, every line	No, only the differences
Accepts a partial file	Yes	No, the file must be a complete configuration
Automatic rollback timer	No	Yes, with the time keyword

A copy into the running configuration is a merge. Suppose a change added snmp-server community public ro. Copying yesterday’s file back applies every line of yesterday’s configuration and leaves the new community in place, because the old file never mentions it. configure replace compares the two configurations, then adds and removes only what differs. In Cisco’s own example, the list output shows the replace removing exactly that line with no snmp-server community public ro. Cisco also warns that the merge approach reapplies commands that already exist, which is inefficient and can, in some cases, cause a service outage on its own.

Keep copy for what it does well: adding a partial snippet, such as a new ACL block, to a running switch. For returning to a known state, use configure replace, and know its limits. Cisco’s Configuration Replace chapter notes that the replacement file must be a complete configuration in the format IOS XE generates, that lines for physical interfaces cannot be added or removed, that a few commands cannot be removed without a reload, and that the switch needs free memory larger than the two configuration files combined.

Roll Back to an Archived Configuration

Switch# show archive
Switch# configure replace flash:sw-core1-config-6 list
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
Switch# write memory

The list keyword prints the commands applied in each pass, which is the record to keep for the change ticket; the operation normally completes within three passes. By default the running configuration is locked against other sessions until the replace finishes; show configuration lock displays the lock, and the nolock keyword turns it off. A replace changes only the running configuration, so the rollback is not persistent until write memory runs.

Apply a Change With an Automatic Rollback Timer

configure replace can also apply a new configuration with a safety net. Build the intended end state as a complete configuration file, copy it to flash, and apply it with a timer:

Switch# copy scp://backup@192.0.2.20/sw-core1-target.cfg flash:sw-core1-target.cfg
Switch# configure replace flash:sw-core1-target.cfg time 10
Switch# configure confirm

If configure confirm is not entered within 10 minutes, the switch restores the configuration that existed before the replace. That makes this the right method for changes that can cut off the session making them, such as management ACLs, AAA settings, and uplink or routing changes on a remote switch. Within the window, configure revert now rolls back immediately, and configure revert timer 20 resets the timer when testing needs longer. The revert trigger error option reverts automatically if any line fails to apply.

Configuration Restore on a Replacement Cisco Switch

A replacement switch of the same model can run the saved configuration unchanged. Moving a configuration to a different model is a migration with its own interface and feature mapping, and this section does not cover it. Work from the console in this order:

1. Match the software. Install the IOS XE release recorded with the backup before loading the configuration; our Cisco IOS XE upgrade guide covers install mode and boot variables.
2. Bootstrap management access. Configure a management address that can reach the backup server. If the backup will arrive over SCP, generate a key pair first with crypto key generate rsa modulus 2048, because SCP depends on SSH.
3. Restore the VLAN database. If the old switch ran VTP server mode, copy the saved file to flash:vlan.dat.
4. Replace the configuration. Copy the backup to flash, run configure replace flash:<file>, then write memory. The replace removes the bootstrap lines that the saved file does not contain, and write memory saves the configuration together with the new RSA keys.
5. Reload and verify. Reload once so the switch boots from the restored configuration and VLAN database, then check show vtp status, show vlan brief, and show interfaces status before connecting the uplinks.

Do the VTP check before the trunks come up. Cisco’s VTP guide warns that with VTP versions 1 and 2, adding a device whose configuration revision number is higher than the domain’s can erase all VLAN information from the VTP server and every switch in the domain; VTP version 3 does not erase it. A replacement unit that was staged in a lab or taken from another site can arrive with a stale, higher revision and take every access VLAN in the building down with it. When the replacement is meant to learn its VLANs from an existing VTP server, and show vtp status shows a revision number above 0, reset it first with the procedure in Cisco’s VTP guide, which changes the VTP domain name and then restores the original one.

Expect two gaps after the restore. The configuration archive starts over, because archived versions lived on the failed switch’s flash or on the server they were sent to. SSH clients will also warn about a changed host key, since the key pair is new.

Stack Member Replacement

A failed stack member does not need a configuration restore at all when the replacement matches it. Cisco’s Catalyst 9300 stacking guide states that a replacement of the identical model that uses the same stack member number automatically takes over the failed switch’s interface configuration. The stack’s configuration is backed up and restored the same way as a standalone switch.

The member number is what makes this work. Set it on the replacement before it joins, with switch 1 renumber 3 for example; the new number takes effect after that switch resets. Cisco rejects the renumber command on a provisioned switch, and a member that joins under a number with no interface configuration comes up with default port settings. A replacement running software that is incompatible with the stack can be brought to the stack’s release through the auto-upgrade and auto-advise features.

If the failed unit needs a like-for-like replacement, compare current models on our Catalyst 9300 switches and Catalyst 9200 switches pages.