The following points provide some operational guidance on the usage of rollback:
Both admin save and rollback save should be done periodically:
Do an admin save to back up a complete configuration file that can be used during router reboot:
Used with a reboot as a last resort.
Do an admin save after any major hardware changes or major service changes.
Should be done after any software upgrade.
Do a rollback save to create a rollback checkpoint:
used for intermediate checkpoints that can be recovered with minimal impacts to services
should be done each time that a moderate amount of configuration changes have been made
should be done after any hardware changes
should be done after any software upgrade
can also be scheduled with CRON (for example, once every 1 or 2 weeks)
A new rescue save must be created when hardware is changed.
Rollback checkpoint files are not editable nor compatible/interchangeable with configuration files (generated with admin save).
Avoid repeatedly executing rollback save without also occasionally executing admin save. If you really get into a bad situation, you may have to use one of your admin save configurations as the primary configuration for an admin reboot.
After a software upgrade has occurred and the system is operating as expected, it is recommended to create a rollback checkpoint file using the admin>rollback>save command and to save the configuration using admin>save. This ensures that a good checkpoint fully compatible with the new release is available shortly after the upgrade.
A set of rollback checkpoints can be created to support busy/quiet days or weekend/weekdays and CRON can be used to shift between them.
It is recommended to create a rollback checkpoint before a rollback revert is initiated (especially if there have been significant configuration changes since the last checkpoint was created). If the rollback is especially significant (a lot of major changes) it is also a good practice to do an admin save just in case a full reboot is required to recover from an issue.
A rollback failure may occur in some limited cases where the node needs a long time to complete one of the resulting configuration changes. If a rollback fails during execution, it should be attempted again. The second attempt will typically complete the remaining configuration changes required to fully revert to the desired checkpoint.
On the 7210 SAS-R6 and 7210 SAS-R12, when a new backup CPM is commissioned, the user should issue the admin>redundancy>rollback-sync to copy the entire set of rollback files from the active CPM checkpoint file (CF) to the new standby CPM CF. If the operator needs the system to automatically copy new rollback checkpoints to both CFs whenever a new checkpoint is created, the config>redundancy>rollback-sync should be configured.
On the 7210 SAS-R6 and 7210 SAS-R12, a high availability CPM switchover during a rollback revert will cause the rollback operation to abort. The newly active CPM will have an indeterminate configuration. A log event is created and the operator is advised to repeat the rollback revert operation to the same checkpoint.
A rollback checkpoint file stores the rollback location and the local and remote maximum checkpoint values, and as such a rollback revert operation can change those values. If an operator changes the local and remote maximum checkpoint values, it is recommended to delete all the existing checkpoints otherwise a subsequent rollback revert could change the max values back to a previous value.
If a warning prompt (y/n) is displayed when a rollback revert
is initiated, it is highly suggested to respond ‛no’ to the warning prompt
the first time, save a rollback checkpoint before attempting this rollback revert, and
execute the rollback>revert again and respond ‛yes’.
If the rollback encounters problems, a revert to the saved checkpoint can be used to
return to the initial configuration state.