> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Cisco ASA Upgrade and Backup Procedure - URL: https://www.pinglabz.com/cisco-asa-upgrade-backup/ - Published: 2026-05-10T06:40:11.000Z - Updated: 2026-08-24T09:43:46.000Z - Description: The production-ready ASA upgrade procedure: back up off-box, stage the image to flash, set the boot variable, reload, verify, and roll back if needed. Works for a single ASA or a failover pair. - Author: Jaime - Tags: ASA, #Import 2026-08-01 19:54 Backup before you change. Upgrade in a maintenance window. Test the rollback path before you need it. The Cisco ASA upgrade and backup procedures are unglamorous but they are the difference between a smooth Tuesday and a 2am bridge call. This article walks the production-ready procedure: what to back up, how to copy it off-box, how to stage a new image to flash, set the boot variable, reload, verify, and roll back if needed. The procedure works equally for a single ASA and a failover pair, with the pair-specific notes called out where they matter. This is an Operations article in the [Cisco ASA cluster](https://www.pinglabz.com/cisco-asa/). It pairs with [common outages](https://www.pinglabz.com/cisco-asa-common-outages/) (which covers what to do when an upgrade goes wrong) and [active/standby failover](https://www.pinglabz.com/cisco-asa-active-standby-failover/) (which is the foundation for zero-downtime upgrades). ## What to Back Up Before Touching Anything startup-config Why Last-known-good config in flash. Always. How to capture it `copy running-config startup-config` then `copy disk0:/startup-config scp://...` running-config Why Current state in RAM. Diverges from startup until you save. How to capture it `copy running-config scp://user@host/path` Identity certificates and private keys Why Cert revocation requires the CSR/key; lost keys mean a new cert. How to capture it `crypto ca export TRUSTPOINT pkcs12 PASSPHRASE` VPN pre-shared keys Why Masked in `show running-config`; you need the original list from your secrets vault. How to capture it External record (1Password, Vault, etc.) AAA shared secrets WhySame; masked. How to capture itExternal record Currently-running image filename Why The exact image you are running today, in case you need to roll back. How to capture it `show version | include image` License entitlements Why Smart licensing token, ASAv platform license How to capture it `show license all` \+ screenshot of the Smart Licensing portal The "external record" rows are the most-overlooked part of an ASA backup. The text config does not contain the actual PSK or shared secret values; the box stores them encrypted and prints `*****` in `show running-config`. You cannot reconstruct a tunnel-group from the config alone if you lose the original PSK list. ## Copy the Config Off-Box SCP is the modern way. SFTP and FTP also work. TFTP is for the lab only. ``` ASA-PERIM# copy running-config scp://backup-user@10.10.0.30/asa-perim/asa-perim-2026-05-10.cfg Source filename [running-config]? Address or name of remote host [10.10.0.30]? Destination username [backup-user]? Destination password []? ********** Destination filename [asa-perim/asa-perim-2026-05-10.cfg]? Writing file scp://10.10.0.30/asa-perim/asa-perim-2026-05-10.cfg !!!!!!!!!!!!!!!!! 12834 bytes copied in 1.220 secs (10519 bytes/sec) ``` For automated nightly backups, set up a scheduled cron on a backup host that pulls via SSH and the show-running-config command, or use a config-management tool (Solarwinds NCM, Oxidized, etc.) that does the same in a structured way. ## Export Certificates and Keys Identity certificates and the private keys behind them ride in the running config in encrypted PKCS#12 form. To export them, pick a passphrase (record it in your vault) and run: ``` ASA-PERIM(config)# crypto ca export ASDM-CERT pkcs12 BackupPassphr@se Exported pkcs12 follows: -----BEGIN PKCS12----- MIIJ4QIBAzCCCacGCSqGSIb3DQEHAaCCCZgEggmUMIIJkDCCBgkGCSqGSIb3DQEHAaCCBfoEggX2 [base64 continues for several KB] -----END PKCS12----- ASA-PERIM(config)# ``` Copy the entire base64 block (between the BEGIN and END lines) into a file in your secrets store. To restore on a replacement ASA, paste it back with `crypto ca import TRUSTPOINT pkcs12 PASSPHRASE`. See [trustpoints and certificates](https://www.pinglabz.com/cisco-asa-anyconnect-certificates/) for the full cert lifecycle. ## Stage the New Image to Flash Cisco distributes ASA images as `.SPA` files on cisco.com. Get the file (and the MD5/SHA512 from the download page), then push it to the ASA's flash: ``` ASA-PERIM# copy scp://image-user@10.10.0.30/asa9-23-2-smp-k8.SPA disk0:/ Address or name of remote host [10.10.0.30]? Source filename [asa9-23-2-smp-k8.SPA]? Destination filename [asa9-23-2-smp-k8.SPA]? Destination password []? ********** Accessing scp://image-user@10.10.0.30/asa9-23-2-smp-k8.SPA... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 116231632 bytes copied in 24.560 secs (4732097 bytes/sec) ``` Verify the image is intact and is what Cisco signed: ``` ASA-PERIM# verify /sha-512 disk0:/asa9-23-2-smp-k8.SPA Verifying file integrity of disk0:/asa9-23-2-smp-k8.SPA... .................................................................... Computed Hash: SHA2:7a3c8f2d ... [matches the value from cisco.com] Embedded Hash: SHA2:7a3c8f2d ... [matches Cisco's embedded signature] Computed signature: PASS ASA-PERIM# ``` Both hashes match and the embedded-signature check passes. If either fails, do not boot the image - re-download from Cisco. A bad image will not boot, and on a remote box that means a console-cable trip. ## Set the Boot Variable The `boot system` command tells the ASA which image to load on the next reload. Multiple `boot system` lines are allowed; the ASA tries them in order and falls back if the first is corrupted or missing. ``` ASA-PERIM(config)# show running-config boot boot system disk0:/asa9-23-1-smp-k8.SPA ! ASA-PERIM(config)# boot system disk0:/asa9-23-2-smp-k8.SPA ASA-PERIM(config)# no boot system disk0:/asa9-23-1-smp-k8.SPA ASA-PERIM(config)# boot system disk0:/asa9-23-1-smp-k8.SPA ! re-add the old as the fallback ! ASA-PERIM(config)# show running-config boot boot system disk0:/asa9-23-2-smp-k8.SPA boot system disk0:/asa9-23-1-smp-k8.SPA ASA-PERIM(config)# write memory ``` Order matters. The first `boot system` wins; the second is the safety net. If the new image refuses to boot, the ASA falls back to the second line and you reload back into the working version. ## Reload and Verify Single-ASA reload is one command: ``` ASA-PERIM# reload Proceed with reload? [confirm] ``` The box drops the console for 3-5 minutes (longer on hardware ASA with bigger image trees). After it comes back: ``` ASA-PERIM# show version | include System image|Compiled System image file is "disk0:/asa9-23-2-smp-k8.SPA" Compiled on 2026-04-15 12:34 by builder ``` Image is the new one. Sanity-check the rest: ``` ASA-PERIM# show interface ip brief ! All data interfaces up? ASA-PERIM# show route ! Default + static routes intact? ASA-PERIM# show xlate count ! Traffic flowing? ASA-PERIM# show conn count ! Conns building? ASA-PERIM# show vpn-sessiondb summary ! Active VPN sessions? ASA-PERIM# show failover ! (if HA pair) Both units up, sync OK? ``` If anything looks wrong, the rollback path is just another reload after re-ordering the `boot system` lines. ## Upgrading a Failover Pair (Hitless) Active/standby failover lets you upgrade with no traffic loss. The Cisco-recommended sequence: 1. Copy the new image to **both** units' flash. The standby auto-syncs config, but does not auto-sync image files. 2. Set `boot system disk0:/NEW-IMAGE.SPA` on both units (config replicates). 3. Reload the standby first: `failover reload-standby`. This reloads the standby unit only; it boots the new image and rejoins the pair as a now-current standby. 4. Verify on the active: `show failover state` should show standby unit healthy and on the new version. 5. Force a switchover: `no failover active` on the active (or `failover active` on the standby). The standby (new image) becomes active. Existing TCP conns survive because of stateful failover. See [stateful failover](https://www.pinglabz.com/cisco-asa-stateful-failover/). 6. Reload the now-standby (which is on the old image): `failover reload-standby`. 7. Both units now on the new image. Optionally `failover active` back to the original primary if you care about which physical unit is active. Cisco's TAC notes that some major-version jumps are not "hitless-failover-safe" - the version skew during the rolling upgrade is not always clean. Read the release notes for your target version's "Upgrade Path" section. The 9.x to 9.x point-version upgrades are almost always safe; cross-major (8.x to 9.x or 9.x to 10.x) often require both units off-active for the cutover. ## Rollback Two scenarios: **The box booted the new image but something is broken.** Re-order the `boot system` lines so the old image is first, save, reload. ``` ASA-PERIM(config)# no boot system disk0:/asa9-23-2-smp-k8.SPA ASA-PERIM(config)# no boot system disk0:/asa9-23-1-smp-k8.SPA ASA-PERIM(config)# boot system disk0:/asa9-23-1-smp-k8.SPA ASA-PERIM(config)# boot system disk0:/asa9-23-2-smp-k8.SPA ASA-PERIM(config)# write memory ASA-PERIM# reload ``` **The box did not come back up after the upgrade reload.** You are in ROMmon-or-console territory. Console in, interrupt the boot, set the ROMmon boot variable to the old image: ``` rommon> boot disk0:/asa9-23-1-smp-k8.SPA ``` Once it boots, fix the boot lines in the running config and save. The remote restore-from-backup procedure (TFTP server reachable from the management interface, point ROMmon at it) is what to use if disk0 itself is corrupt - which is rare but does happen. ## Restore from Backup To restore a config to a fresh ASA: ``` ! Console into the new box. ! Set up enough of the management interface to reach SCP source. ciscoasa(config)# interface Management0/0 ciscoasa(config-if)# nameif management ciscoasa(config-if)# ip address 10.10.99.1 255.255.255.0 ciscoasa(config-if)# no shutdown ciscoasa(config)# route management 10.10.0.0 255.255.0.0 10.10.99.254 1 ! ciscoasa# copy scp://backup-user@10.10.0.30/asa-perim/asa-perim-2026-05-10.cfg running-config ``` The config loads, the interfaces re-IP themselves, and SSH/AAA come back online. Save it: `write memory`. Then re-import any certificates with `crypto ca import` from your PKCS#12 backup. ## Pre-Upgrade Checklist 1. Read the release notes for the target version's Upgrade Path and Open Caveats. 2. Confirm sufficient flash free space (`show disk0:`). 3. Back up startup-config, running-config, certificates, PSK list. 4. Stage the new image to flash on both units (failover pair). 5. Verify the image hash and signature. 6. Set `boot system NEW` with the old image as the fallback. 7. `write memory`. 8. Identify and notify users of the maintenance window. 9. Have console access ready in case the remote management interface is the thing that breaks. 10. Reload (failover pair: standby first), then run the verification show commands. ## Key Takeaways Backups before changes, image hashes before reloads, two `boot system` lines for rollback safety, and console access at the ready. SCP is the modern transport for both config and image transfers. PKCS#12 export is the only way to back up certificates and their private keys. Failover pairs upgrade hitless if you reload the standby first and let stateful sync carry the conns through the switchover. For the things that go wrong during or after an upgrade, see [common outage scenarios](https://www.pinglabz.com/cisco-asa-common-outages/). For the rest of the cluster, the [Cisco ASA pillar](https://www.pinglabz.com/cisco-asa/) has the full reading order.