Configuration History

TNSR software version 21.07 and later includes an optional configuration history which uses Git to track changes. This history can be used in either a manual or automated manner, depending on user preference. Stored versions can be manually loaded to roll back to earlier configurations as needed.

Warning

Though this feature automates management of local backups, it is not a substitute for periodic backups kept off the router in a safe and secure location. See Configuration Backups for details.

Overview

The Configuration Database files are held in /var/tnsr which is now initialized as a Git repository. There are two ways TNSR retains information about changes:

  • The version list, which contains manually saved entries and periodic automatic entries depending on the configuration.

  • The log, which contains information about every configuration change.

Configuration versions can then be loaded to go back to an earlier point as needed.

Enabling Configuration History

To have TNSR automatically create configuration history versions which can later be restored, TNSR must know how frequently to create these versions. When viewing versions, these are prefixed with auto- and contain a timestamp corresponding to when the change was made.

This is accomplished via the following command in config mode:

tnsr(config)# configuration history enable
tnsr(config)# configuration history autosave-period 1

The value after autosave-period controls how often new version entries are created by TNSR. The possible values and their behavior are:

0:

Disables automatic transaction storage. Manual entries are still possible. This is the default value.

1:

Creates a new version for every change to the configuration. This is the most comprehensive method of tracking, but over time will create a large number of entries in the version list, which may be undesirable.

>1:

Creates a new version every N number of configuration changes. For example, when set to 2, then every second change will result in a new version. When set to 5 then a new version is created after every fifth change, and so on.

To view the current history configuration:

tnsr# show configuration history config
Configuration history
=====================
Enable: true
Version autosave period: 1

To disable history tracking:

tnsr(config)# configuration history disable

Note

Disabling configuration history does not remove data from the history. See Managing Configuration History.

To disable the feature and reset the autosave period to 0 in one step, use:

tnsr(config)# no configuration history

Saving a Configuration Version

A manual version can be created at any time by the following command:

tnsr(config)# configuration history version save <version-name>

The format of the name is strict. The name must adhere to the same guidelines as a Git reference, which has numerous restrictions on its contents. Put simply, it must be a single printable ASCII word without spaces. Some punctuation values are OK, such as - and _, while others have restrictions, such as . can be used so long as it is not at the end of the name, and the name cannot contain ... Follow the link earlier in this paragraph for details.

Viewing Configuration History

As mentioned in Overview the history is separated into two areas, the version list and the log.

Configuration Version List

To view the list of manual and automatic versions which can be loaded, use:

tnsr# show configuration history versions
auto-2021-06-24_08-03-34
auto-2021-06-24_08-06-10
auto-2021-06-24_08-45-41
myversion

Among the entries in this list example are:

  • A manually saved version named myversion.

  • Automatically stored entries from configuration changes, named auto-<timestamp>.

The version list is presented in alphabetical order, which naturally sorts the automatic versions of each type in ascending order.

Configuration Version Differences

The configuration history can also show differences in the configuration database between two versions in the history. The difference is shown in unified diff format.

Compare two versions using the following command:

tnsr# show configuration history version-diff <old-version> <new-version>

For example, using entries from the list above, to view what changed between the entry named myversion and the auto-2021-06-24_08-45-41 entry, use the following command:

tnsr# show configuration history version-diff myversion auto-2021-06-24_08-45-41

Configuration Log

The log contains more detail than the version list. The log tracks every change even if a version restore point is not created.

To view the log:

tnsr# show configuration history log
user-2021-06-24_16-44-42
startup-2021-06-24_16-42-22
startup-2021-06-24_16-41-31
Initial-2021-06-24_16-13-00

Among the entries in this list example are:

  • Automatically stored entries from configuration changes, named user-<timestamp>.

  • Automatically stored entries from TNSR startup, named startup-<timestamp>.

  • The initial state of the repository when it was created, named Initial-<timestamp>.

The log is presented in chronological order with the most recent entry printed first.

To view the details of a log entry which shows configuration changes between entries, use:

tnsr# show configuration history log <version-name>

Loading Configuration History Entries

Entries from the version list may be restored by the following command:

tnsr(config)# configuration history version load <version-name>

The name may be any entry in the version list (show configuration history versions), and pressing ? at the end of the command will make the CLI print a list of available version names.

Settings from the loaded configuration are immediately committed. If the older configuration contained changes to TNSR services (e.g. IPsec, DHCP) or the dataplane, restarting the affected services is required. TNSR does not perform those steps automatically since they are potentially disruptive.

tnsr(config)# configuration history version load myversion
TNSR services or dataplane restart could be required!

Tip

The safest way to ensure all settings are applied as desired is to load the configuration and then restart TNSR. Copy the running configuration database to startup before restarting TNSR.

Managing Configuration History

Over time the number of entries in the version history will grow. Individual entries may be removed if desired, for example to keep the list short or to remove a known bad configuration state so that others cannot load it accidentally.

To remove a single entry from the version list, use the following command:

tnsr(config)# no configuration history version <version-name>

The entire history may be cleared using the following command, which includes all manual versions, automatic versions, and log entries may be cleared:

tnsr(config)# no configuration history storage

Note

This removes the entire history, but it does not disable history tracking. The existing settings remain in place. See Enabling Configuration History.