Tip
This is the documentation for the 24.06 version. Looking for the documentation of the latest version? Have a look here.
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 to5
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.