Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Network device configuration archives: what has to be somewhere else to matter

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A configuration archive matters only for the failure it does not share. A copy on the device can undo a bad change while that device still boots. It cannot rebuild the device after the storage is gone. A copy on a server that you can reach only through the network you are trying to restore cannot be read at the moment you need it.

That is the whole test. Before you argue about tools, name the failure, then name a copy that still exists and that someone can open without that failure being fixed first.

This article is about that test for routers, switches and firewalls. It is not a procedure for rolling a change back. The Cisco behaviour below is taken from one published guide for IOS XE Fuji 16.7.x. Later releases can differ, and nothing here was run on equipment.

Why it matters

Network devices fail in three different ways that people lump together as "we have backups".

The first is a bad change. The device is up, the operator can still reach it, or can reach it on a console, and the last good configuration is the thing that would put the service back. The second is a lost device: a failed supervisor, a wiped flash, a replacement chassis. The third is a lost place: the management network, the site, or the server that stored every "remote" copy.

A single archive location can pass one of those tests and fail the other two. Teams discover which one they passed during the incident, because the archive job has been reporting success for years.

NIST's firewall guidance treats the configuration as something you manage, not as a file the device will look after for you. SP 800-41 Revision 1 says firewall policies and rulesets should be backed up regularly, and that if the product can store the information in more than one format, backups should be kept in all of them. It also says ruleset and policy changes belong in a formal change process, with a log of policy decisions and ruleset changes kept in association with the device. The publication does not say the word "offline". The requirement to keep a backup is not, by itself, a requirement that the backup survive the device.

What the built-in archive actually is

Cisco's configuration archive, as described in the Configuration Replace and Configuration Rollback chapter of the IOS XE Fuji 16.7.x managing-configuration guide, is a managed set of copies of the running configuration. The archive config command saves the running configuration under a path and filename prefix you set, with an incremental version number and an optional timestamp. show archive lists what was saved.

You choose how many versions to keep. The guide says the valid maximum is 1 to 14, and the default is 10. When the archive is full, the oldest file is deleted as the newest is saved. An optional time-period saves the running configuration on a timer, in minutes, once the path is set.

Two consequences follow straight from that design.

The archive is a history of whatever was running, not a label that says "this one was good". If the timer is short, a bad running configuration is archived too, and it can push an older file out once the maximum is reached. A ten-file archive with a ten-minute timer holds less than two hours of history. That can be enough to undo the change you just made. It is not a record of last Tuesday.

The archive lives on a local or remote file system the device can write. Its built-in management does not make every archive on-box. The same chapter lists local media such as disk0: and disk1: where the platform has them, and remote systems such as FTP, TFTP, RCP, and, on platforms without disk0:, HTTP. "Remote" means the device copied the file somewhere else at save time. It does not mean you can fetch that file when the device is dead, and it does not mean the remote server is outside the failure.

The old guide’s FTP, TFTP, RCP and HTTP examples describe historical supported transports, not a recommendation to send credentials or configurations over plaintext networks. Use a release-supported protected transfer path and restrict access to stored configurations; transport support must be checked separately.

Before this feature, the guide says, operators saved the running configuration with copy running-config to a local or remote URL, and that method had no automated file management. The archive adds the rotation and the naming. It does not add a judgement about which copy is safe to return to.

Replace is not the same as copy

The reason the archive exists, in Cisco's own wording, is to give configure replace a checkpoint to return to. configure replace compares the running configuration with a complete saved configuration, builds the differences, and applies those differences. The guide says only the differences are applied, so commands that are already present are not re-entered. It also says the operation removes commands that are in the running configuration and absent from the replacement file.

copy into the running configuration is a merge. The guide is explicit: it keeps commands from both the file and the running configuration, and it does not remove commands that are missing from the file. A partial file is allowed for that merge. configure replace requires a complete configuration of the kind the device itself writes, or an external file that follows the same indentation rules.

That distinction is the recovery mistake. Restoring "the backup" with a merge can leave the bad lines in place and add the old lines beside them. Access lists and other order-dependent commands are called out as something the replace algorithm handles over multiple passes, with a limit of five passes. A merge does not make that promise.

There is a second limit that no archive fixes. The guide says commands that describe physical parts of the device cannot be added or removed to match a file when the hardware is not there. A replace that tries to delete an interface that is physically present, or to add one that is not, reports an error for those lines. In rare cases, the guide says, a command cannot be removed from the running configuration without a reload, and replace will report that the line failed. Free memory must be larger than the two files combined, or the replace is not performed at all.

So a perfect archive of the old configuration is not a guarantee that the running device can become that configuration. The hardware and the memory have to be able to accept the difference. A replacement chassis with a different interface layout will not absorb the old file cleanly. That is a planning fact, not a reason to keep editing the file until it loads.

The chapter also disagrees with itself in two places a recovery plan should not paper over. Earlier it says no archive setup is required to use configure replace, and that the archive is optional. The procedure section then says you must create a configuration archive before the replace procedure. Its confirmation-timer descriptions also disagree about units. No timer syntax, value or archive prerequisite is recommended from those conflicting passages. Release-specific vendor documentation and controlled validation are required before an operational procedure can be approved.

What NIST adds, and what it does not

SP 800-41 Revision 1 is about firewalls, not about every router. Its management section is still the clearest public statement of what a configuration backup is for. Policies and rulesets should be backed up regularly. Where the product has a binary form used to load the device and a human-readable form used by auditors, keep both. A binary blob you cannot read is a poor input to a decision. A text file the device will not load is a poor input to a restore.

The same section says changes should be managed, and that a log of policy decisions and ruleset changes should be associated with the firewall: attached to the device, or kept in the same inventory record. Comments on rules are recommended because a later reviewer has to know why a line exists. Reviews should happen on a schedule, not only during an audit or an emergency, and each review should look at who changed what since the last review.

None of that tells you the file is on a different site. It does tell you that a backup which is only the device's private binary, with no human-readable twin and no change log, may not support a human ruleset review even if it would load; that is not by itself a finding of non-compliance with a named audit standard. For recovery, the human-readable copy is also how a second person checks that the file you are about to trust is the change you think it is.

Our recommendation, not a NIST statement: treat the change log as part of the archive. A file named with a timestamp is not a reason. The reason is the ticket, the operator, and the comment that says whether this copy was taken before the change, after a successful change, or by a timer that does not care.

Three failures, three copies

Use the three failures as the design, not as a slogan.

Bad change, device still reachable. The on-box archive is the right tool if a known-good file is still inside the rotation. That means the maximum and the timer have to be chosen for the time it takes a person to notice, not for how tidy the flash looks. A promoted copy, saved under a name the timer does not rotate, is the file you intend to return to. The rotating archive is evidence of what happened afterwards. Cisco's guide does not describe a separate "known-good" flag. Keeping one is an operational choice on top of the feature.

Device lost. Anything stored only on that device's flash, including the startup configuration and the archive, is in the same failure. The copy that matters was written to another system while the device was healthy. The Cisco remote file systems are a way to do that write. They are not, by themselves, a check that the write succeeded, that the file is complete, or that you can read it without the device. NIST's point about keeping every format applies here: keep the text a person can review, and keep whatever form a replacement device of the same software family will accept. A replacement of a different model may not accept either form. The archive does not convert hardware.

Network or site lost. A file server on the same management network is remote from the device and local to the outage. TFTP and FTP to a host in the same building fail the same test as the flash if the building is the problem. The copy that matters for this failure is one you can open from somewhere that does not depend on the failed network. That can be another site, or media that is not plugged into the failed site. Off-site or independently accessible does not necessarily mean offline. Reserve offline for a disconnected copy; choose both location and connectivity to match the failure being covered. NIST SP 800-41 does not define an air-gap model.

A practical set is small. One rotating history on the device, for the bad change you can still reach. One recent copy on a management host, for the dead device while the site network still works. One copy outside that site, taken often enough that its age is an accepted recovery-point decision, for the loss of the site. If you only have the first, say so in the design. Do not describe it as coverage for the third.

What the outside copy has to contain

A configuration file is not only addresses and routes. On a firewall it is the policy. On a router it is often the local usernames, SNMP communities, key chains and VPN material that the device needs in order to speak. NIST does not, in this publication, give a handling rule for those secrets. Our recommendation, not a NIST or Cisco statement: the outside copy needs the same restriction as administrative access to the device. A copy that everyone can read, because it was exported to an open file share to make the backup "easy", has traded a recovery gap for a credential leak. A copy that is encrypted by a key stored only on the device you just lost cannot be opened either. The key has to survive the same failure as the file, in a place a named person can reach.

The file also has to be the kind of file the platform will accept. Cisco's guide says a replace file must follow the indentation the device uses when it writes a configuration: no indent at the top level, one space in the first submode, and so on. A file produced by the device meets that rule. A file reassembled by hand, or saved by a tool that rewrites whitespace, may not. This article does not test any tool. If a tool is in the path, the recovery plan should include a comparison of a device-written file with the tool's file, done before an incident, on a platform you are allowed to use.

Keep the association NIST asks for. The outside copy should be tied to the device name, the software version, the date, and the change record. A directory of unnamed "running-config.txt" files from a weekend script is not an archive you can choose from under pressure.

What to decide

Decide these points in writing, while nothing is broken.

Which failure each copy is for, and who can get it without the device. If the answer is "the on-call engineer, from home, through the management VPN", that copy does not cover a failure of the management path. Say which copy does.

How old the outside copy may be. That age is the configuration recovery point. It is not the same number as the on-box timer. A timer of ten minutes and an off-site copy from last month are both real. They answer different questions.

Which file is allowed to be used for a return, and which files are only history. Timer copies need a human choice. A promoted copy needs a rule for when promotion happens: after a change is accepted, not after every save.

Which format is for loading and which is for reading. If the platform has both, keep both, as NIST recommends for firewalls. Do not assume a text export will load, and do not assume a binary will explain itself.

What will not return even if the file is perfect. Interface names that do not exist on the replacement hardware, commands the running image cannot remove without a reload, and a merge that leaves the bad lines behind. The Cisco guide states the first two for configure replace. The merge behaviour is why the command you intend to use has to be chosen before the night, not invented from the help text during it.

Who is allowed to read the copy, and where the key is if the copy is encrypted. Write the names. "The security team" is not a person who can be phoned when the directory service is down.

Risks and limits

This chapter of the Cisco guide was updated on 10 December 2017 for IOS XE Fuji 16.7.x. On 13 November 2026 the vendor site refused the retrieval from this research host, so the text used here is the Internet Archive copy of that URL captured on 9 December 2022. The feature may have changed in later trains. The guide itself says not every release supports every feature, and points readers to the release notes and Feature Navigator. Nothing in this article confirms behaviour on a current release.

SP 800-41 Revision 1 is dated September 2009. It describes firewall policy and management. It is not a standard for router archives, and it does not mention Cisco. Using it beside the Cisco chapter is an editorial choice about management practice, not a claim that NIST certified the Cisco feature.

The contradictions inside the Cisco chapter, minutes against seconds, and archive optional against archive required, are left as contradictions. A recovery plan that depends on the confirmation timer needs a reading of the guide for the exact release, on the platform in question.

No configuration was saved, replaced, or restored for this article. No timer value is recommended as a default. The ten-minute figure above is only arithmetic on the documented default of ten files, to show how fast a timer can erase history.

Research and verification

Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No equipment was configured, no article commands were executed and no lab behaviour is claimed. This is educational source research, not an approved production recovery procedure.

Sources

This article was originally published on .