Submit a ticketCall us

AnnouncementsAre You “Flying Blind?”

When it comes to your complex IT infrastructure, you want to ensure you have a good grasp of what’s going on to avoid any fire drills that result from guesswork. Read our white paper to learn how proactively monitoring your IT environment can help your organization while giving you peace of mind.

Get your free white paper.

Home > Success Center > Kiwi CatTools > Kiwi CatTools Documentation > Kiwi CatTools 3.11 Administrator Guide > Activities > Activities list > Device.Backup.Running Config > Why you should backup your configs

Why you should backup your configs

Table of contents
No headers
Created by Caroline Juszczak, last modified by Caroline Juszczak on Jun 28, 2016

Views: 196 Votes: 0 Revisions: 1


Why it is important to backup your configs?


The Device.Backup.Running Configactivity is one of a number of default activities provided with the CatTools program. It is designed to copy the currently running configuration from the selected device, into a text file on your local file system.


This is an important distinction: it copies the configuration parameters that are currently running on the device. Many devices have their own local storage, where one or more versions of their configuration files may be stored. Most network devices managed by CatTools will have a start-up config file that they load and run when the power is switched on.


Because this running config can be changed in real-time, by someone logged into the device via a telnet session for example, the running config may no longer be the same as the start-up config. Capturing these different versions of your device configurations is exactly the sort of thing that CatTools is for.


Say you have a night-shift engineer who encounters a problem on your network, hurriedly telnets into a router and makes some changes to that device that restores service to your internal customers, but in the panic forgets to document or save these changes. If you power cycle that device at some later time, those changes will be lost, potentially recreating the problem, only this time it might be during your busiest period of the day. Now you have the problem back, but the fix is gone and the engineer is at home in bed. You may have to start the whole problem resolution process from scratch, costing your organisation money and costing you (and your department) credibility.


There are several ways that the activity might be useful in this reasonably common scenario.


Firstly, it is best practice in change management to always have a roll-back contingency. Naturally, such a plan is no good if you can't actually recover and re-install the old configuration. You should make it a habit to always capture a restorable copy of the current configuration before making any changes to it, and CatTools is a very effective means of doing this.


Secondly, CatTools contains a Diff Report function which runs as a part of the activity. This compares the configuration that has just been downloaded to the previous copy stored on file. If any changes are detected then it creates a report in HTML format that highlights the lines that are different (that's why it's called a Diff Report). The default setting is for this report to be emailed to you as soon as it is created, as well as being stored in the Reports directory.


So if our hypothetical night-shift engineer had run a Device.Backup.Running Config before and after they had made changes to the router, then you'd have a report showing you exactly what changes had been made, plus you'd have two copies of the config in two text files; one before the changes and one after.


You could use either of these files to restore the router to the configuration you want. Or, you could use the Diff Report to manually identify and recreate the changes.

Last modified