Procedures for nvram:startup-config restore points

[denmendoza]

Might anyone have procedures for setting up nvram:startup-config "restore points"?

Such as having local storage (onboard 9800WLC, for example) of nvram:startup-config_bk1, nvram:startup-config_bk2, nvram:startup-config_bk3

And then, as desired, overwriting the present nvram:startup-config with any desired saved backup version bk1, bk2, bk3 ????

Thanks in advance!!!

In case it matters, my 9800WLC is running 17.8.1

[balaji.bandi]

what is the use case - may be not able to what you trying to achieve.

You want to replace with startup config with different startup config ? what is the reason ?

startup config only need when the device reload or restarted

you can use different method like EEM script or pulling from tftp so on..

[denmendoza]

If along the way, there are changes to the running-config that are "write memory" saved to startup-config, I am wanting means to possibly back out from all those changes and directly revert back to the startup-config prior to any of those changes, for example.

[balaji.bandi]

you can setup EEM Script or config back can be done based requirement.

I am wanting means to possibly back out from all those changes and directly revert back to the startup-config prior to any of those changes

this is not clear to me, what changes -  you can daily back up to have controlled version to look everyday changes right ?

[denmendoza]

"...you can daily back up..." <<<< What might details be for your perceived 'back up' method?

Presently, I would extract a "show startup-config" and save output with some date/timestamp appendage... this is what I refer to as "original startup-config" henceforth.

And then some time afterwards, when some changes may have been "write memory"-saved from running-config overwriting the original startup-config, if I want to confidently restore the config state from the initially extracted "original startup-config", I am spoon-feeding that back through privileged EXEC config commands...

But (I believe) that method would not properly address "added/new configs" relative to the "original startup-config" but rather would only restore the original config items to their original state, correct? 

[balaji.bandi · Accepted solution]

Its all depends on the requirement.

Let me give some example as below :

when device configured and wr the config - that time current running config and startup config same.

taking running config backup is also most all identical of startup config - version 1 (dated configuration backup)

some changes done X date and write conifig, running config and startup config same - ver2 (backup done daily based).

you can use any tools to backup the config or you can use EEM script copy the show run and show start and to TFTP date and time based, so you can have number of copies you can as long as you have enough space on the remote storage of TFTP.

example based on the syslog when any changes occurred, you can also do daily changing your requirement, (you can also change running to startup config to backup also - based on the requirement)

event manager applet Backup-Running-Config-To-TFTP

description Backup-Running-Config-To-TFTP

event syslog pattern "%SYS-5-CONFIG_I: Configured from"

action 0.1 info type routername

action 1.0 cli command "enable"

action 1.1 cli command "copy run tftp" pattern "Address"

action 1.2 cli command "192.168.5.4" pattern "filename"

action 1.3 cli command "$_info_routername-config_$_event_pub_sec"

action 2.0 syslog priority informational msg "Configuration change detected. Write to TFTP succesfully executed"!

[denmendoza]

Thanks BB

That sounds like what will suit my need/want... for a progression where "version 2" does NOT have a superset of outstanding configurations enabled/config'd relative to "version 1", i.e. when "ver1" gets restored its config commands (from its saved "show startup-config") would not include disabling/removing the superset of configs in "ver2", correct?

As such, I would think punting back to Day0 (a known clean slate) and then restoring "ver1" by feeding back in the "ver1 startup-config" would be the way to go, agree? And, the physical connections are preserved by way of the VLAN database file persistence, right?

But, to eliminate the Day0 side journey, I would more ideally like the mechanism to directly overwrite the nvram:startup-config (with my desired saved timestamped version) and reload... 

[balaji.bandi]

sure if that works for you, Day 0 means there is nothing in the box like factory reset, so once you configure the vrsion1 that is your base line config to restore to day 1 config from there you can do load what version best known to work as expected.

[marce1000]

  - There is no auto provisioning of that feature on the 9800 WLC ; if you are in need of saving multiple versions of the startup configuration then use an external repository (too) , in case of fatalities on the controller (e.g.)

 M.

[denmendoza]

In the case of controller falling into irrecoverable state other than punting back to Day0, what then would be the procedure to get any startup-config from an external repository directly into nvram:startup-config (without scripting it in via privileged exec commands)?