Configuration backups that are actually restorable

Most organisations back up device configurations. Rather fewer could rebuild a failed device from those backups quickly, and the gap between the two is where outages become long outages.

What the text file does not contain

A configuration export usually omits licences, which on some platforms are tied to hardware and must be reissued. It omits certificates and keys. It omits the software version, and a configuration restored onto different firmware may not parse. It omits any state that was set outside the configuration, such as a boot variable. And it omits the physical context: which port went where.

Restoring a config onto a replacement device that runs different firmware, has no licence and is cabled differently is not a five-minute job.

What a restorable backup includes

• The configuration itself, plainly
• The exact software version, and where to obtain it
• Licence details or the process to reissue them
• Certificates and keys, stored securely and separately
• A port map: what connects to each interface
• The device’s role in one sentence, for whoever does the restore at 3am

Automate the collection

Manual backups are taken before changes and not after. Automate a daily collection, store it in version control, and you gain something more useful than the backup: a diff. You can see what changed, when, and correlate it with an incident.

# the useful question, answered instantly
git log -p --since="2 weeks ago" -- switches/core-01.cfg

Test a restore

This is the part that gets skipped, and it is the part that matters. Once a year, take a spare device and rebuild it from backup alone, with no access to the original. You will discover the missing licence, the undocumented cable, and the config that will not parse on current firmware — at a time of your choosing rather than during an outage.

A backup nobody has restored is a hypothesis, not a plan.