Backing Up, Restoring, and Upgrading the Cisco C9800

The Catalyst 9800 makes backup, restore, and upgrade look simpler than it actually is. The commands are short, the GUI has wizards, and most of the time the process works. The trouble starts on the 2 percent of upgrades that go wrong — a commit timer you didn't know about expires, an AP image is missing at cutover, an SMU gets applied to the wrong version, or a restore overwrites a config you wanted to keep. This guide walks through the full lifecycle the way you should actually operate it: backing up the configuration and state you'd need to rebuild a WLC, restoring cleanly, and upgrading with Install mode, ISSU, SMU, and N+1 rolling upgrades — with the gotchas that don't fit on a GUI tooltip.

What "Backup" Actually Means on a C9800

If you ask five network engineers what a WLC backup is, you'll get five answers — running config, startup config, the full flash, something from Catalyst Center, "whatever RANCID grabs." On a C9800 there are several distinct things you might want to back up, and they are not interchangeable.

The config is the single most important artifact, but the trustpoints are the one people forget. A C9800 rebuilt from config alone without its LSC or WebAuth certificate will come up with every AP failing DTLS and every captive-portal client seeing certificate warnings. Always back up the crypto material alongside the config.

Backing Up the Configuration

The basic backup is what you'd expect — a copy of the running config to an external destination. Two ways to do it, both of which should be scripted or scheduled rather than run by hand.

C9800#copy running-config tftp://10.10.10.5/c9800-primary.cfg
Address or name of remote host [10.10.10.5]?
Destination filename [c9800-primary.cfg]?
!!
14782 bytes copied in 2.143 secs (6898 bytes/sec)

C9800#archive config
C9800#show archive
The maximum archive configurations allowed is 10.
The next archive file will be named flash:archive-Oct-5-2026-09-15-22.cfg

 Archive #  Name
   1        flash:archive-Oct-4-2026-08-00-01.cfg
   2        flash:archive-Oct-4-2026-20-00-03.cfg
   3        flash:archive-Oct-5-2026-08-00-02.cfg <- Most Recent

For operational use, configure the archive subsystem to take a config snapshot on every write memory and on a timed interval, store them to both flash and an external path, and retain enough history that you can roll back to any point in the last week without asking your backup team.

C9800(config)#archive
C9800(config-archive)#path tftp://10.10.10.5/c9800-archive/$h-$t
C9800(config-archive)#write-memory
C9800(config-archive)#time-period 1440
C9800(config-archive)#maximum 14

That stanza captures the config every 24 hours (1440 minutes) and on every write memory, keeps the last 14 versions, and pushes each one to TFTP. Replace TFTP with SFTP in any environment that cares about transport security.

Exporting Trustpoints

Trustpoints — the certificate and private-key pairs used for LSC, WebAuth, and NETCONF — are stored inside the config in an encoded form, but the safer practice is to export them explicitly so you can re-import on a rebuild without parsing the running config by hand.

C9800(config)#crypto pki export lsc-trust pkcs12 tftp://10.10.10.5/lsc-trust.p12 password 0 S3cretPassphrase

% Exporting trustpoint 'lsc-trust' in PKCS12 format
% The PKCS12 file has been successfully exported

Store the exported PKCS12 with strong access control; it contains the private key. On a restore, import it back with crypto pki import … pkcs12.

Restoring a Controller

Restoration is usually one of two scenarios: either you're rebuilding a controller from scratch after a hardware swap or a total software reinstall, or you're rolling back a recent config change. They have different procedures.

Full rebuild. Install the OS image (or boot into one), complete Day 0 setup enough to get a management IP, then copy the saved config to flash and either copy flash:saved-config.cfg running-config or set it as the startup config and reload. After the controller reloads, import the trustpoints, verify AP join, and check show wireless client summary counts against your baseline.

Config rollback. If a recent change broke something and you want to revert to yesterday's config, use configure replace rather than an overwrite:

C9800#configure replace flash:archive-Oct-4-2026-08-00-01.cfg 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

Total number of passes: 1
Rollback Done

configure replace computes the diff between the current running config and the target file and applies only what's needed, which is both faster and less disruptive than a reload. It's the right tool for "undo the last change" scenarios.

Upgrade Methods, and Which One to Use When

The C9800 gives you more upgrade options than any previous wireless platform. They look redundant until you realise each is optimised for a different combination of risk, outage budget, and release delta.

Three practical rules before you pick a method:

Always be in Install mode. Bundle mode works but locks you out of ISSU, SMU, and reliable rolling upgrades. Check with show version | include Installation; if it doesn't say "Installation mode is INSTALL," convert before you do anything else.

Always pre-download AP images. Without it, every AP downloads the image during cutover and your window stretches to the slowest WAN link. With it, the cutover is just a reboot.

Always have a rollback plan that someone has tested in a lab. The commands exist for every method, but rehearsing rollback during a real incident is the wrong time to learn the syntax.

Install-Mode Upgrade: The Standard Path

For a single chassis or a non-ISSU upgrade on an HA pair, the normal flow is install add file … activate commit. Each phase is a distinct step and each has a rollback.

C9800#copy tftp://10.10.10.5/C9800-SW-17.15.1.SPA.bin bootflash:
C9800#install add file bootflash:C9800-SW-17.15.1.SPA.bin
install_add: START Sun Apr  5 10:14:22 UTC 2026
install_add: Adding IMG
--- Starting initial file syncing ---
Finished initial file syncing
--- Starting Add ---
Performing Add on all members
Add: Passed on [R0]
Finished Add
SUCCESS: install_add  Sun Apr  5 10:16:02 UTC 2026

C9800#install activate
This operation may require a reload of the system. Do you want to proceed? [y/n]y

C9800#install commit
SUCCESS: install_commit Sun Apr  5 10:45:12 UTC 2026

C9800#show version | include Cisco IOS Software
Cisco IOS Software [IOSXE], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.15.1

The critical step most engineers skip is install commit. Without the commit, IOS-XE runs a rollback timer (default 6 hours on 17.4 and later) after which the controller reverts to the previous image automatically. That's a safety feature — if you can't reach the box after activation, it self-heals — but it's also a trap if you forget. Commit as soon as you've verified the upgrade is healthy.

If you need to back out before committing, install abort rolls to the previous image cleanly:

C9800#install abort
This operation will cancel the current installation. Are you sure you want to proceed? [y/n]y

ISSU: Upgrade Without Dropping Clients

ISSU upgrades an SSO pair between compatible releases with zero data-plane impact. The active chassis pushes the new image to the standby, the standby reloads and comes up on the new version, a switchover happens, then the former active reloads on the new image and the pair resynchronises. From a client's perspective, nothing happens — RUN-state clients stay associated, and active flows keep forwarding.

C9800#install add file bootflash:C9800-SW-17.15.1.SPA.bin activate issu commit

install_add_activate_commit: START Sun Apr  5 10:14:22 UTC 2026
--- Starting ISSU Compatibility Check ---
ISSU compatibility check is SUCCESSFUL
--- Starting Add ---
Add: Passed on [R0,R1]
--- Starting ISSU Activate ---
...
SUCCESS: install_add_activate_commit

ISSU compatibility is not guaranteed across every pair of releases. Read the Cisco ISSU compatibility matrix for your source and target version before you plan the window, and if the pair is not ISSU-compatible, fall back to a standard install-mode upgrade with SSO failover — you'll still keep APs joined (the standby takes over), but clients mid-flow may experience a brief drop.

SMU: Hot Patches for Specific Bugs

A Software Maintenance Upgrade is a pointed fix for a specific defect, shipped as a package that applies on top of a base release. SMUs are release-specific — an SMU built for 17.12.3 will not apply to 17.12.4 — and they come in two flavours: cold SMUs require a reload, hot SMUs do not. The release notes for every SMU state which it is.

C9800#install add file bootflash:C9800-SMU-CSCab12345.SPA.smu
C9800#install activate file bootflash:C9800-SMU-CSCab12345.SPA.smu
C9800#install commit

C9800#show install summary
[ R0 R1 ] Installed Package(s) Information:
State (St): S - Installed and Set State, N - Not installed,
            C - Installed and Committed
Type   St   Filename/Version
--------------------------------------------------------------
IMG    C    17.12.4
SMU    C    C9800-SMU-CSCab12345.SPA.smu

SMUs are the right answer when you have a single production-impacting bug and don't want to take a full upgrade. They are not a general-purpose patching strategy — Cisco expects you to move to the next base release on a normal cadence and consume bug fixes that way.

N+1 Hitless Rolling AP Upgrade

In an N+1 deployment, you have one or more primary controllers and a backup controller that APs failover to when the primary goes down. The N+1 hitless rolling upgrade uses that pattern deliberately: you upgrade the secondary first, then move APs in waves from the primary to the secondary. Each wave reboots onto the new image; clients at sites in other waves are unaffected. When all waves are done, you upgrade the now-empty primary and let APs drift back.

The key enabler is that both controllers have the same target image ready to go, and APs have pre-downloaded the new image. Rolling upgrade is a Catalyst Center-friendly workflow but can also be driven from the CLI with ap image predownload and controlled failover steps.

C9800#ap image predownload
Initiating predownload on all APs

C9800#show ap image
Total number of APs     : 412
    Predownloading       : 412
    Completed predownloading : 412

C9800#ap image swap <ap-name-or-all>

Verification That Matters After Any Upgrade

The commands that tell you whether an upgrade is actually healthy — not just whether it reloaded without crashing:

C9800#show version | include Cisco IOS Software
C9800#show install summary
C9800#show redundancy states
C9800#show ap summary | include Joined
C9800#show wireless client summary | include RUN
C9800#show wireless stats ap join summary
C9800#show logging | include -3-|-4-

Match the version, confirm SSO is in HOT state, confirm the AP join count is at or above your pre-upgrade baseline, confirm client count in RUN state is recovering, and scan the log for any error- or warning-level messages that appeared during or after the upgrade. If any of those look wrong, investigate before you commit — the commit timer is your friend.

Key Takeaways

A real backup covers the config, the trustpoints, and the image — not just the running config. Use archive to capture config snapshots on every write memory and to an external path, and export certificates explicitly with crypto pki export pkcs12. Use configure replace for rollbacks rather than overwriting the config. Always run in Install mode, never Bundle mode. Always pre-download AP images before a window. Pick ISSU when your SSO pair supports it and you want zero client impact; pick a standard install-mode upgrade with SSO failover when it doesn't. Use SMUs for targeted bug fixes, and use N+1 hitless rolling upgrades when you need to stage a very large AP fleet through waves. And never forget to install commit — the rollback timer is a safety net, not a completion step.