Rescue and Recovery of Configuration File (Junos OS)
In the event of software failure, a rescue configuration helps to load a known working configuration. No need to remember the rollback number; if you saved a configuration, you can use it anytime when needed.
Saving and Reverting a Rescue Configuration File
Saving a Rescue Configuration File
A rescue configuration file is helpful in the event that your device’s configuration file has been misconfigured. A rescue configuration allows you to define a known working configuration or a configuration with a known state that you can roll back to at any time. This alleviates the necessity of having to remember the rollback number with the rollback command. You can restore the device to this rescue configuration to bring the device back online. If you save this file off the device, the rescue configuration can also be used to restore your device in the event of a software failure.
As of Junos OS Release 16.1, for devices running Junos OS with upgraded FreeBSD, provided you have saved a rescue configuration on the device, there is an automatic device recovery mode that goes into action should the system fail to activate the current configuration (amnesiac mode).
To determine which platforms run Junos OS with upgraded FreeBSD, see Feature Explorer, enter freebsd
, and select
Junos kernel upgrade to FreeBSD 10+
.
You can identify that the device has recovered automatically from amnesiac mode by the following:
-
The syslog
UI_DEVICE_IN_RECOVERY_MODE
is generated, which indicates that there was a problem in the normal boot time commit and that Junos OS has activated the rescue configuration as the device's configuration. -
The CLI displays the banner
Device is running in Recovery Mode
in both operational and configuration modes.
Starting in Junos OS Release 23.4R1 for MX Series routers, you can also prevent the
device from reaching an amnesiac state post-reboot by configuring the dual-phase-bootup
feature before the reboot. When a device has a scaled configuration or has a lot of
constraints to be validated, upon reboot it may take more than 45 minutes to finish.
This lengthy reboot time exceeds the limit set for the watchdog timer. The watchdog
timer going off can cause the device to reach an amnesiac state. To avoid reaching an
amnesiac state during a future reboot, configure the dual-phase-bootup
statement.
If you have configured the dual-phase-bootup
statement before the
reboot, the device picks up the rescue configuration from the next reboot. Post-reboot,
the device’s operational state is active and the device automatically loads the
last-configured user configuration (juniper.conf file), thus
preventing the device from reaching an amnesiac state.
To be able to commit the configuration for the dual-phase-bootup
statement, you must already have created a rescue configuration
(rescue.conf file). We recommend that you have a minimal rescue
configuration.
This topic covers the following procedures:
- Saving a Rescue Configuration
- Validating the Rescue Configuration
- Copying the Configuration to a Remote Server
- Rolling Back to Troubleshoot the Failed Configuration
- Rolling Back to the Rescue Configuration
- Deleting an Existing Rescue Configuration
Saving a Rescue Configuration
To save a current device configuration as a rescue configuration file:
Edit the configuration file on the device to reflect the base configuration you wish to use.
In the CLI operational mode, save this edited base configuration as the rescue configuration file:
user@host> request system configuration rescue save
The rescue configuration file is automatically saved under /config directory as rescue.conf.gz.
Validating the Rescue Configuration
You can verify that the syntax of a configuration file is correct
and check for commit check errors by using the test configuration filename
command.
To verify if a rescue configuration file is correct:
test configuration filename
command from the CLI operational mode.user@host> test configuration /config/rescue.conf.gz configuration check succeeds
If the configuration contains any syntax or commit check errors, a message is displayed to indicate the line number and column number in which the error was found. This command only accepts text files.
Copying the Configuration to a Remote Server
This task is optional but recommended.
To copy the rescue configuration to a remote server:
Rolling Back to Troubleshoot the Failed Configuration
Your rescue configuration is probably not exactly the configuration you want or need on your system. Therefore, you will want to examine the failures that occurred when you tried to activate the current configuration and make corrective actions.
To correct the failed configuration:
Rolling Back to the Rescue Configuration
Not all platforms run Junos OS with updated FreeBSD. Those that do not or are releases earlier than Junos OS Release 16.1, do not have the automatic recovery mode. You will need to rollback to rescue configuration manually to bring the device back to normal running mode.
To roll back to the rescue configuration:
Deleting an Existing Rescue Configuration
To delete an existing rescue configuration:
request system configuration rescue delete
command: user@host> request system configuration rescue delete
Reverting to the Rescue Configuration
If someone inadvertently commits a configuration that denies management access to a device and the console port is not accessible, you can overwrite the invalid configuration and replace it with the rescue configuration. The rescue configuration is a previously committed, valid configuration.
To revert the switch to the rescue configuration:
Copy Backup Configurations and Restore Saved Configurations
Copy Backup Configurations to the Router
To copy backup configurations to the router, follow these steps:
To copy the existing configuration and any backup configurations back onto the router, use the
file copy
command. Place the files in the /var/tmp directory.user@host> file copy var/tmp/filename
Load and activate the desired configuration:
user@host> configure [edit] user@host# load merge/config/
filename
or load replace/config/filename
[edit] user@host# commit
Restoring a Saved Configuration
To restore a saved configuration, perform the following tasks:
Copy Saved Files to the Router
To copy the saved configuration to the router:
Log in to the console as
root
. There is no password.Escape character is '^]'. [Enter] router (ttyd0) login: root Password: [Enter]
Initially, access to the router is limited to the console port after a recovery installation. Access through the management ports and interfaces is set in the configuration. For information about accessing the router through the console port, see the administration guide for your particular router.
Start the CLI:
# cli
Copy the configuration file on the remote server to the router’s /var/tmp directory:
root@host> ftp remote-server user: username password: password ftp> bin Type set to I. ftp> get /path/file ftp> bye Goodbye.
Loading and Committing the Configuration File
Once the saved configuration file is copied to the router, you load and commit the file:
Start the CLI configuration mode.
user@host> configure Entering configuration mode [edit] user@host#
Load the file into the current configuration. You should override the existing file.
user@host# load override /var/tmp/filename load complete
Commit the file.
user@host# commit commit complete
Exit the CLI configuration mode.
user@host# exit user@host>
Back up Junos OS.
After you have installed the software on the router, committed the configuration, and are satisfied that the new configuration is successfully running, issue the
request system snapshot
command to back up the new software to the /altconfig file system. If you do not issue therequest system snapshot
command, the configuration on the alternate boot drive will be out of sync with the configuration on the primary boot drive.The
request system snapshot
command causes the root file system to be backed up to /altroot, and /config to be backed up to /altconfig. The root and /config file systems are on the router’s CompactFlash card, and the /altroot and /altconfig file systems are on the router’s hard disk or solid-state drive (SSD).
Reverting to the Default Factory Configuration by Using the request system zeroize Command
The request system zeroize
command is a standard Junos OS operational
mode command that removes all configuration information and resets all key values. The
operation unlinks all user-created data files, including customized configuration and log
files, from their directories. The device then reboots and reverts to the factory-default
configuration.
To completely erase user-created data so that it is unrecoverable, use the
request system zeroize media
command.
Before issuing request system zeroize
, use the request system
snapshot
command to back up the files currently used to run the device to a
secondary device.
To revert to the factory-default configuration by using the request system
zeroize
command: