Cisco archive vs kron: which config backup mechanism wins

Cisco gives you two on-device mechanisms for automated config backup: archive and kron. They look similar, but they're built for different problems. Pick the wrong one and you'll either overshoot (managing two systems that do the same thing) or undershoot (missing the feature you actually needed).

The honest answer (1 paragraph)

Use archive if you want versioning tied to write memory events on a single device. It does one thing — snapshot the running-config to a remote location every time someone saves — and does it well. Use kron if you want to schedule arbitrary commands on a schedule and you already have an external target. Use neither if you have more than 10 devices — at that scale, central server-side pull (Netmiko, Ansible, or a managed tool) is operationally cleaner than managing per-device schedules.

Quick comparison

Dimension	archive	kron
What it does	Snapshots running-config to a remote target on every write memory (or per time-period)	Schedules any CLI command on a calendar
Native to Cisco	Yes (since 12.3(4))	Yes (since 12.3(1))
Best for	Versioned backups on a single critical device	Custom recurring tasks (backups + other things)
Triggers	write memory, configurable time-period	Time-of-day, day-of-week, recurring
Targets	TFTP, FTP, SCP, flash, http	Whatever the command produces — TFTP push, syslog, etc.
Configuration complexity	Low — one block under archive config	Medium — policy-list + occurrence blocks
Scaling to fleet	Bad — every device configures its own schedule	Bad — same problem
Failure handling	Implicit (next write memory retries)	Implicit (next scheduled run retries)
When to skip	>10 devices, multi-vendor, you want central alerting	You only need backups (use archive instead)

The archive command in practice

archive
 path scp://backup@10.0.100.5/configs/$h-config
 write-memory
 time-period 1440
 maximum 14

What this does:

• Every 1,440 minutes (24 hours), pushes a snapshot
• Every write memory also pushes a snapshot
• Keeps up to 14 versions on the device's archive list (the maximum line)
• Files land at the SCP target with the hostname prefix

Useful for: a single core router where you want a belt-and-suspenders backup tied to actual config changes. Not useful for: a fleet of 50 switches where you want central visibility.

The kron command in practice

kron policy-list Backup
 cli show running-config | redirect scp://backup@10.0.100.5/configs/$h-config
kron occurrence Daily at 23:00 recurring
 policy-list Backup

What this does:

• Defines a "policy" that captures running-config and pushes via SCP
• Schedules that policy to run every day at 23:00
• kron doesn't have native versioning — that's the archive command's job

Useful for: scheduling any command on a calendar, not just backups. If you want a daily config capture without the write memory trigger, kron works. If you want versioning, you need archive (or external tooling).

Where they overlap and where they don't

Both can push running-config to a remote target. That's the overlap.

The differences that actually matter:

• archive versions automatically. Every push is a numbered snapshot. kron overwrites unless you build filename timestamps into the redirect.
• archive triggers on save. You don't have to wait for the schedule — the moment someone writes the config, it gets backed up. kron only runs on its schedule.
• kron is more flexible. You can run any command, not just config capture. Useful if you want to schedule show commands, syslog rotations, or operational tasks alongside backups.

When to use what (real decisions)

1-3 critical devices, want every-save capture, don't need central visibility: archive. Set it up once, forget it, and the device maintains its own version history.

5-10 devices, want scheduled daily backups, willing to manage per-device schedules: Either works. archive for the save-triggers; kron if you also want other scheduled tasks on the same device.

10+ devices, multi-vendor, want central alerting and visibility: Neither. Use external pull (Netmiko, Ansible, or a managed tool) from a central server. You get a single source of truth, alerting on failures, and you don't have to log into 50 devices to check their schedules.

Already running TACACS+/RADIUS with authentication servers you trust less than your own infra: External pull is the only safe option. Don't have device-initiated outbound to backup servers in environments where outbound is restricted.

The configuration drift problem both create

Both archive and kron push from the device outward. They don't tell you when a device stops backing up. If a device's archive path silently fails (auth change, network ACL, disk full), the device happily keeps not backing up and you don't know.

External pull fixes this: the server sees "device X didn't respond to my SSH in 24 hours" and alerts you.

That's the operational reason central-pull wins at scale, even though archive is technically elegant for a single device.

Related

• Cisco IOS configuration backup: the complete guide — the pillar post for this cluster
• Why your Cisco configs drift (and what to do about it) — what to do once you've got the backup mechanism in place
• show running-config vs show startup-config: what actually matters — what you're actually capturing

Try it

If you've been running Cisco 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