Configuration management is the most overlooked discipline in network engineering. Every engineer knows how to do a one-off copy running-config tftp:, but very few have automated, versioned, and tested restoration procedures.

Why Config Management Matters

• Switch failure — A dead switch takes hours to rebuild from scratch
• Config rollback — A bad change needs to be reverted in minutes, not days
• Audit trail — Who changed what and when
• Compliance — PCI-DSS, SOC2, and ISO 27001 all require config backup
• Standardization — Ensures every switch runs the same base config

Backup Methods

TFTP Backup

The simplest method. No authentication, runs over UDP port 69.

! Save running-config to TFTP server
copy running-config tftp://192.168.1.100/ACCESS-SW-1-running-config.txt
 
! Save startup-config
copy startup-config tftp://192.168.1.100/ACCESS-SW-1-startup-config.txt
 
! Save both in one command
copy running-config tftp://192.168.1.100/ACCESS-SW-1-config-$(date +%Y%m%d).txt

Restore from TFTP:

copy tftp://192.168.1.100/ACCESS-SW-1-config-20250621.txt running-config

FTP Backup

Not recommended — passwords are sent in plaintext.

SCP Backup (Secure Copy)

SCP runs over SSH and encrypts everything.

! Enable SCP server on the switch
ip scp server enable

From the management host:

scp admin@ACCESS-SW-1:running-config backup/ACCESS-SW-1-$(date +%Y%m%d).txt
scp admin@ACCESS-SW-1:startup-config backup/ACCESS-SW-1-startup-$(date +%Y%m%d).txt

Push config to switch via SCP:

scp backup/ACCESS-SW-1-new-config.txt admin@ACCESS-SW-1:running-config

HTTP/HTTPS Backup

copy running-config http://backup-server/configs/ACCESS-SW-1.cfg
copy running-config https://backup-server/configs/ACCESS-SW-1.cfg

Requires an HTTP server listening on the backup host.

Cisco IOS Archive Feature

The archive feature provides automatic versioned backups integrated with the CLI.

Archive Configuration

archive
 path tftp://192.168.1.100/$h-config
 maximum 10
 time-period 1440
 write-memory

• $h expands to the hostname
• maximum 10 keeps 10 backup revisions
• time-period 1440 takes a snapshot every 24 hours
• write-memory triggers a backup on every write memory (copy run start)

Manual Archive Snapshots

archive config

This immediately copies the running config to the archive path with an incremental version number.

List Archive Versions

show archive
show archive log config all

Rollback with Archive

configure replace tftp://192.168.1.100/ACCESS-SW-1-config-3

This replaces the running config with the archived version without reloading the switch. It is the fastest way to revert a bad change.

Configuration Replace and Rollback

Cisco IOS supports atomic config replacement and rollback without a reload.

Configure Replace

! Preview changes without applying them
configure replace tftp://192.168.1.100/ACCESS-SW-1-config-base.txt list
 
! Apply the replacement
configure replace tftp://192.168.1.100/ACCESS-SW-1-config-base.txt force

The force option suppresses prompts. The list option shows what will change.

Rollback on Error

configure replace tftp://192.168.1.100/ACCESS-SW-1-previous-good-config.txt

If the rollback introduces more problems:

configure revert now

Or if within the idle timeout:

configure revert timer 5

This gives you a 5-minute window to confirm the replacement.

Automated Backup Script

Run this from a Linux management host:

#!/bin/bash
# backup-switches.sh — Backup all switch configs via SCP
 
BACKUP_DIR="/backup/switches/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"
 
SWITCHES="CORE-SW DIST-SW-1 DIST-SW-2 ACCESS-SW-1 ACCESS-SW-2 ACCESS-SW-3"
USER="admin"
PASS="YourPasswordHere"
 
for switch in $SWITCHES; do
    echo "Backing up $switch..."
    sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no "$USER@$switch" \
        "show running-config" > "$BACKUP_DIR/$switch-running.cfg"
 
    sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no "$USER@$switch" \
        "show startup-config" > "$BACKUP_DIR/$switch-startup.cfg"
 
    sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no "$USER@$switch" \
        "show vlan brief" > "$BACKUP_DIR/$switch-vlans.txt"
 
    echo "$switch done"
done
 
# Generate checksums
cd "$BACKUP_DIR"
sha256sum *.cfg > checksums.txt

Backup with RANCID/Oxidation

For larger networks, use automated config collectors:

# RANCID — runs via crontab, diffs configs
# Config location: /usr/local/rancid/var/router.db
 
# Oxidation — web interface for RANCID
# View config diffs in browser

Disaster Recovery Procedure

Prepare a Recovery Bundle

For each switch model, keep a base config file:

BACKUP_DIR/
├── 2025-06-01/
│   ├── CORE-SW-running.cfg
│   ├── DIST-SW-1-running.cfg
│   └── ACCESS-SW-1-running.cfg
├── templates/
│   ├── base-2960.cfg
│   ├── base-3850.cfg
│   └── base-9300.cfg
└── recovery-drill.sh

Switch Replacement Procedure

When a switch dies and a new one arrives:

# 1. Copy base config for the model
cp templates/base-2960.cfg /tftp/ACCESS-SW-1-recovery.cfg
 
# 2. Modify hostname, IP, and VLANs specific to ACCESS-SW-1
vim /tftp/ACCESS-SW-1-recovery.cfg
 
# 3. On the new switch, set initial IP on VLAN 99
#    Connect console, configure management IP
interface vlan 99
 ip address 192.168.1.10 255.255.255.0
 no shutdown
ip default-gateway 192.168.1.1
 
# 4. Copy the full config
copy tftp://192.168.1.100/ACCESS-SW-1-recovery.cfg running-config
 
# 5. Verify and save
show running-config | section hostname|vlan
copy running-config startup-config

Validate Backup Integrity

# Check checksums
cd /backup/switches/2025-06-21
sha256sum -c checksums.txt
 
# Compare with last known good config
diff /backup/switches/2025-06-20/ACCESS-SW-1-running.cfg ACCESS-SW-1-running.cfg

Version Control for Configs

Track configs in Git for full audit trail:

cd /backup/switches
git init
git add .
git commit -m "Initial backup of all switch configs"

Automated Git Backup

#!/bin/bash
# backup-to-git.sh
 
cd /backup/switches
./backup-switches.sh   # Run the backup script above
git add -A
git commit -m "Auto-backup $(date +%Y-%m-%d %H:%M)"
git push origin main

Now every config change is tracked, diffable, and revertible.

Restore Drill Checklist

Test restoration quarterly:

• Can you reach the TFTP/SCP server from a bare switch?
• Do you have the correct base config template for each model?
• Does the configure replace command apply cleanly?
• Are interface names consistent (Gi0/1 vs Gi1/0/1)?
• Does the management VLAN IP change between configs?
• Is AAA reachable after restore? (Fallback local user configured?)
• Can you verify connectivity across all VLANs?
• Is the restoration documented and accessible to the on-call engineer?

Best Practices

• Backup every switch weekly — Automate it, do not rely on memory
• Keep 30+ days of history — Config drift happens slowly; you need a time machine
• Use SCP instead of TFTP — Encryption matters even in the management network
• Store configs in version control — Git makes diffing and rollback trivial
• Test restoration quarterly — A backup you have never restored is a wish
• Include VLAN and interface data — The full show tech is better than just running-config
• Document the recovery procedure — Write it down for the person who gets paged at 3 AM
• Use the archive feature — Automatic versioned backups on every write memory

Quick Reference

One-Liner Backup

for sw in CORE DIST ACCESS; do ssh admin@$sw "show run" > backup/$sw-$(date +%Y%m%d).cfg; done