Back Up and Recover the Configuration
SUMMARY During a successful upgrade, the upgrade package completely re-installs the existing operating system. It retains the juniper.conf, rescue.conf, SNMP ifIndexes, /var/home, /config/scripts, SSH files, and other filesystem files. Other information is removed. Therefore, you should back up your current configuration in case you need to return to the current software installation after running the installation program.
Save a Rescue Configuration
In the event of software failure, having a rescue configuration helps to load a known working configuration. No need to remember or look up the rollback number; if you save a rescue configuration, you can use it anytime.
A rescue configuration file is helpful if 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 to which you can roll back at any time. You can restore the device to this rescue configuration to bring the device back online. If you save this file off the device, you can use the rescue configuration to restore your device in the event of a software failure.
To save a current device configuration as a rescue configuration file:
-
Edit the configuration file on the device to reflect the configuration you wish to save.
-
In the CLI operational mode, save this edited configuration as the rescue configuration file:
user@host> request system configuration rescue save
The system automatically saves rescue configuration file in the /config directory as rescue.conf.gz. If the device has redundant Routing Engines, the system saves the rescue configuration file on both Routing Engines.
Validate a 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
operational mode command.user@host> test configuration /config/rescue.conf.gz configuration check succeeds
If the configuration contains any syntax or commit check errors, a message displays to indicate the line number and column number in which the error was found. This command only accepts text files.
Roll Back to a Rescue Configuration
Fix the Failed Configuration
Your rescue configuration might not be the configuration you want or need on your system. Therefore, you need to fix the failed configuration and re-commit it.
To fix the failed configuration:
Delete the Rescue Configuration
To delete the existing rescue configuration:
request system configuration rescue delete
command: user@host> request system configuration rescue delete
Copy either the Configuration File or the Rescue Configuration to a Remote Server
This task is optional but recommended.
To copy either the currently running configuration or the rescue configuration file to a remote server:
Roll Back to a Prior Configuration
To return to a configuration prior to the most recently committed one, include
the configuration number, 0 through 49, in the rollback
configuration mode command. The most recently saved configuration is number 0
(the default configuration to which the system returns), and the oldest saved
configuration is number 49. To display a list of the previously committed
configurations, including the rollback number, date, time, the name of the user
who committed changes, and the method of commit, use the rollback
?
configuration mode command.
To rollback to a prior configuration:
Synchronize the Rescue Configuration to the Secondary Routing Engine after the Current Configuration Is Synchronized
When the system boots up, if the system finds the current configuration file to be incompatible with the software, then the system fails to commit the configuration file (/config/juniper.conf.gz). If you previously saved a rescue configuration on the system, the system then commits the rescue configuration and saves it as the current configuration file /config/juniper.conf.gz.
For a dual-Routing Engine system, when the secondary Routing Engine boots with a
different current image than the primary Routing Engine's current image and you
have configured the auto-sw-sync enable
statement, the primary
Routing Engine synchronizes the current image to the secondary Routing Engine.
The primary Routing Engine also synchronizes the rollback software image and the
other images to the secondary Routing Engine. If the current configuration file
(juniper.conf.gz) from the primary Routing Engine
matches the current configuration file on the secondary Routing Engine, then the
primary Routing Engine does not synchronize the rescue configuration
(rescue.conf.gz) to the secondary Routing Engine.
To synchronize the rescue configuration from the primary Routing Engine to the
secondary Routing Engine, issue the file copy
command on the
primary Routing Engine:
user@host-re0> file copy /config/rescue.conf.gz re1:/config/
Restore the Configuration from a Backup Copy after a USB Software Installation
If you install Junos OS Evolved from a USB drive onto a single-Routing Engine
device, the installation process deletes the configuration files. Therefore, you
need to re-configure the device. Also, if you have used the request
system zeroize
command to reset the device to the factory defaults,
you also need to re-configure the device. If you have already saved a
configuration file on a remote server or another off-box location, you can copy
that configuration file onto the device to save time when re-configuring the
device.
To restore the configuration from a backup copy:
Revert to the Default Factory Configuration
The
request system zeroize
command is an operational mode
command that
reverts the
system to the factory-default configuration. Prior to Junos OS Evolved Release
21.3R1, this command removes all configuration information and
resets all key values. The operation unlinks all user-created data files,
including the configuration and log files, from their directories. The device
then reboots and reverts to the factory-default
configuration.
Starting in Junos OS Evolved Release 21.3R1, if the disks in the Routing Engine
support the ATA standard, this command sanitizes the disks on the Routing Engine
using the ATA secure erase
command to overwrite the data. The
ATA secure erase
command overwrites the contents of LBA 0
through the greater of either READ NATIVE MAX or READ NATIVE MAX EXT, and
replaces the contents with 0s or 1s. If the disks do not support the ATA
standard (for example, they support the SCSI standard), they are sanitized using
the older method described above. The secure erase capability is classified
under the CLEAR NIST media sanitization level, according to the NIST 800-88
standard. When the secure erase is complete, the system copies the current
running OS from RAMDISK to the ATA disk. Once the current running OS is
installed, the system reboots and comes back to the factory default
configuration.
Before issuing the request system zeroize
operational mode
command, use the request system snapshot
operational mode
command to back up the files currently used to run the device to the
secondary SSD.
To revert to the factory-default configuration by using the request
system zeroize
command: