show running-config vs show startup-config: what actually matters

Two commands, similar output, one of them is what you want 99% of the time. Here's the difference, when each matters, and what to back up.

The 30-second version

• show running-config is the config that's currently active in memory. Edit with configure terminal. Lost on reload (unless you write memory first).
• show startup-config is the config stored in NVRAM. Loaded at boot. Survives reload. Updated only when you write memory (or copy running-config startup-config).

For backups, show running-config is what you want. It captures the live, effective state of the device. startup-config is a snapshot from the last save — useful as a fallback but not as the source of truth.

The longer version (when each matters)

When running-config matters

Every time. The running config is what the device is actually doing right now. Any change you've made but not saved is here. Any change someone else made via SSH and forgot to write is here. This is the config you want to monitor, diff, audit, and back up.

When you do configure terminal and add an ACL line, that change is in running-config immediately. It's in startup-config only after you write memory.

When startup-config matters

Three scenarios:

1. Before a reload. The reload loads startup-config into running-config. If you've made changes you didn't save, they're lost.
2. As a fallback for backup failures. If your backup system misses running-config for some reason (SSH broken, command failed), startup-config is at least the last saved state. Older, but non-empty.
3. Forensic comparison. If running-config looks weird and you want to compare against the last known good save, startup-config is your reference.

When neither matters (the third thing people forget)

On a switch, vlan.dat is a separate file. It holds the VLAN database. If your backup only pulls running-config, your VLANs aren't in the backup. Capture vlan.dat separately if you care about VLAN config.

Crypto keys (SSH host keys, SSL certificates, IPsec keys) are also separate from the running config on most platforms. If you're doing a full device-state backup, you need to capture those too — but for the typical "audit evidence" use case, running-config is enough.

The commands

! See what's running right now
show running-config

! See what's saved to NVRAM
show startup-config

! See the difference between them (if any)
show running-config diff startup-config

The diff form is underrated. It's the fastest way to see "what did I change since the last save" — useful right after a configuration change, before you write memory, to verify the change is what you intended.

What to back up

For most operational purposes:

• Primary: show running-config — captures current effective state
• Secondary: show startup-config — fallback if primary is unavailable
• Optional: show vlan (for switches) — VLAN database
• Optional: crypto keys — for forensic / re-provisioning use cases

You almost never need to back up startup-config as your primary. It is, by definition, older than running-config (unless the device has been freshly booted and nobody's made changes since).

A real failure mode I see

A network engineer makes a config change, doesn't write memory, walks away. The device crashes or reboots. The change is gone. The backup captured startup-config (which is what most "backup" scripts pull because it's simpler), which doesn't include the change. Everyone says "the backup worked but the change is missing" — because the change was never in startup-config to begin with.

Fix: back up running-config, not startup-config. Always.

How to capture both in your backup script

# Using Netmiko
with ConnectHandler(**device) as conn:
    running = conn.send_command("show running-config")
    startup = conn.send_command("show startup-config")

# Write them as separate files, dated
(running_dir / f"running-{today}.cfg").write_text(running)
(startup_dir / f"startup-{today}.cfg").write_text(startup)

The script from the Cisco config backup pillar post does this. Daily running-config is your primary; daily startup-config is your belt-and-suspenders.

Related

• Cisco IOS configuration backup: the complete guide — the full backup workflow
• Cisco archive vs kron: which config backup mechanism wins — when to use device-side mechanisms
• Why your Cisco configs drift (and what to do about it) — what to do with the diffs once you have them

Try it

If you've been running config backups from a cron job you wrote in 2019 and praying — there's a faster way. PacketPilot Config runs scheduled backups with diff-style compare, one-click restore, and a timestamped audit trail. Multi-vendor from day one (Cisco, Juniper, Arista, HPE/Aruba). 30-day machine-bound trial, no credit card.

Download PacketPilot Config

— Ole