7210 SAS-MXP, R6, R12, S, SX, T BASIC SYSTEM
CONFIGURATION GUIDE RELEASE 22.9.R1
CLI usage
• When a rollback save [no ‟-”] is executed, the system shifts the file suffix of all the previous checkpoints
by 1 (new ID= old ID+1). If there are already as many checkpoint files as the maximum number
supported, the last checkpoint file is deleted.
• The maximum number of rollback checkpoints is configurable and defaults to 10 (the latest files and
files 1 through 9, where checkpoint file 9 is deleted during the next rollback-save).
• The location and name of the rollback checkpoint files are configurable to be local storage (for example,
compact flash) or remote storage. The file URL must not contain a suffix (just a path/directory and
filename). The suffix for rollback checkpoint files is .rb and is automatically appended to rollback
checkpoint files.
config>system>rollback# rollback-location file-url
• There is no default rollback location. If a location is not specified (or it is cleared using no rollback-
location) and a rollback save is attempted, the rollback save will fail and return an error message.
• On the 7210 SAS-R6 and 7210 SAS-R12, the entire set of rollback checkpoint files can be copied
from the active CPM CF to the inactive CPM CF. This synchronization is done through the following
command:
admin>redundancy# rollback-sync
• The operator can enable automatic synchronization of rollback checkpoint files between the active CPM
and inactive CPM. When this automatic synchronization is enabled, a rollback save will cause the new
checkpoint file to be saved to both the active and standby. The suffixes of the old checkpoint files on
both active and standby CPMs are increased.
Note:
The automatic synchronize only causes the one new checkpoint file to be copied to both CFs
(the other 9 checkpoints are not automatically copied from active to standby, but that can be
done manually using the admin>redundancy>rollback-sync command).
config>redundancy# [no] rollback-sync
• config>redundancy>synchronize {boot-env|config} and admin>redundancy>synchronize
{boot-env|config}” do not apply to rollback checkpoint files. These commands do not manually or
automatically synchronize rollback checkpoint files. The dedicated rollback-sync commands must be
used to sync rollback checkpoint files.
• Rollback files can be deleted using a dedicated rollback checkpoint deletion command:
admin>rollback# delete {latest-rb | checkpoint-id}
– Deleting a rollback checkpoint causes the suffixes to be adjusted (decremented) for all checkpoints
older than the one that was deleted (to close the ‟hole” in the list of checkpoint files and create room
to create another checkpoint).
– If configure>redundancy>rollback-sync is enabled, a rollback delete will also delete the
equivalent checkpoint on the standby CF and shuffle the suffixes on the standby CF.
– If an operator manually deletes a rollback checkpoint file using file delete, the suffixes of the
checkpoint files are not shuffled, nor is the equivalent checkpoint file deleted from the standby CF.
This manual deletion creates a ‟hole” in the checkpoint file list until enough new checkpoints have
been created to roll the ‟hole” off the end of the list.
• As shown in the following figure, support for rolling back to a previous configuration (a saved rollback
checkpoint) with minimal impact on services. The previous configuration will be loaded and take
operational effect:
3HE 18197 AAAB TQZZA
© 2022 Nokia.
Use subject to Terms available at: www.nokia.com/terms/.
45
SPACER TEXT
To Next Page
Loading...