Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

header-navigation
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents

Back Up and Recover the Configuration

date_range 20-Dec-24

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:

  1. Edit the configuration file on the device to reflect the configuration you wish to save.

  2. In the CLI operational mode, save this edited configuration as the rescue configuration file:

    content_copy zoom_out_map
    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:

Issue the test configuration filename operational mode command.
content_copy zoom_out_map
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

  1. Log in to the device through the console.
  2. Issue the rollback rescue command from the configuration mode of the CLI.
    content_copy zoom_out_map
    user@host# rollback rescue
    load complete
    
  3. Commit the configuration.
    content_copy zoom_out_map
    user@host# commit
    
  4. Fix the failed 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:

  1. Log into the device through the management interface, or the console port (if permitted).
  2. Load the failed configuration.
    content_copy zoom_out_map
    [edit]
    user@host# rollback 1
  3. Make corrections to the configuration.
  4. Use the check option on the commit configuration mode command.
    The check option points out errors in the candidate configuration, giving you the opportunity to fix the errors. If the configuration contains syntax errors, a message indicates the location of the error and the system does not activate the configuration.
    content_copy zoom_out_map
    [edit]
    user@host# commit check
  5. If you have other corrections to make, make them. Keep using the commit check configuration mode command until the system does not find any more errors.
  6. Issue the commit configuration mode command to commit the configuration.
    content_copy zoom_out_map
    [edit]
    user@host# commit
    commit complete
After fixing the failed configuration, we recommend that you back up this configuration either by saving it as a rescue configuration or by saving it to a remote server or other off-box location. See Save a Rescue Configuration or Copy either the Configuration File or the Rescue Configuration to a Remote Server.

Delete the Rescue Configuration

To delete the existing rescue configuration:

Issue the request system configuration rescue delete command:
content_copy zoom_out_map
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:

  1. Log into the device through the management interface, or the console port (if permitted).
  2. Start the device shell.
    content_copy zoom_out_map
    user@host> start shell
    
  3. Go to the /config directory and list the configuration files.

    The currently running configuration file is juniper.conf.gz and the rescue configuration file is rescue.conf.gz.

    content_copy zoom_out_map
    user@host-re0:~# cd /config
    user@host-re0:~# ls /config
    commit-sync-status juniper.conf.2.gz juniper.conf.gz
    juniper.conf.1.gz juniper.conf.3.gz license rescue.conf.gz
  4. FTP the configuration file to the remote host.
    content_copy zoom_out_map
    user@host-re0:~# ftp host2
    Name: user2
    Password: password
    User user2 logged in.
    ftp> cd /var/tmp
    ftp> lcd /config
    ftp> bin
    ftp> put rescue.conf.gz
    local: rescue.conf.gz remote: rescue.conf.gz
     
    Transfer complete.
    ftp> put juniper.conf.gz
    local: juniper.conf.gz remote: juniper.conf.gz
     
    Transfer complete.
    ftp> bye
    Goodbye.

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:

  1. Issue the rollback number configuration mode command.

    The rollback configuration becomes the candidate configuration.

    content_copy zoom_out_map
    {edit]
    user@host# rollback 1
    load complete
  2. To activate the candidate configuration, issue the commit configuration mode command.
    content_copy zoom_out_map
    [edit]
    user@host# commit

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:

content_copy zoom_out_map
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:

  1. Connect to the device through the console port.
  2. Power on the device and wait for it to boot.

    Junos OS Evolved boots automatically. When the boot process is complete, you'll see the login: prompt on the console.

  3. Log in as the user root.

    You won't need a password for the root user account, because the device is using the factory-default configuration. The device prompt root@# indicates that you are the root user. You must configure the management interface address and the password for the root user account before you are able to copy a configuration file to the device.

  4. Issue the cli command to start the Junos OS Evolved CLI.
  5. Issue the configure command to access configuration mode.
  6. Configure the interfaces statement at the [edit] hierarchy level to configure the IP address and prefix length for the management address on RE0.
    content_copy zoom_out_map
    [edit]
    root@# set interfaces re0:mgmt-number unit 0 family inet address address/prefix-length
  7. Configure the root password. Use the password that you would usually configure for the root user account.

    Enter a plain-text password that the system will encrypt, an already-encrypted password, or an SSH public key string. Configure the system root-authentication statement at the [edit] hierarchy level, and type or paste in the password or string when prompted.

    • To enter a plain-text password:
      content_copy zoom_out_map
      [edit]
      root@# set system root-authentication plain-text-password
      New password: password
      Retype new password: password
    • To enter an already-encrypted password, paste the password into the command after the encrypted-password option:
      content_copy zoom_out_map
      [edit]
      root@# set system root-authentication encrypted-password encrypted-password
    • To enter an SSH public key string, paste the key string into the command after the ssh-rsa option:
      content_copy zoom_out_map
      [edit]
      root@# set system root-authentication ssh-rsa key
  8. Commit the configuration.
    content_copy zoom_out_map
    [edit]
    root@# commit
    
    commit complete
  9. Exit configuration mode.
    content_copy zoom_out_map
    root@# exit
    root@>
  10. To copy the configuration file onto the router, use the file copy command.

    Place the file in the /var/tmp directory.

    content_copy zoom_out_map
    root@> file copy scp://filename var/tmp/filename   
    
  11. Start configuration mode.
    content_copy zoom_out_map
    root@# configure
    Entering configuration mode
        
    [edit]
    root@# 
  12. Load the file into the current configuration and override the existing file.
    content_copy zoom_out_map
    root@# load override /var/tmp/filename
    load complete
  13. Commit the configuration.
    content_copy zoom_out_map
    root@# commit
    commit complete
  14. Exit configuration mode.
    content_copy zoom_out_map
    root@host# exit
    root@host>
  15. After you are satisfied that the new configuration is successfully running, issue the request system snapshot operational mode command to back up the system. We also recommend that you create a rescue configuration; for more information, see Save a Rescue Configuration.

    If you do not issue the request system snapshot command, the configuration on the secondary solid-state drive (SSD) will be out of sync with the configuration on the primary SSD.

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, for devices that support this feature, 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.

Starting in Junos OS Evolved 24.4R1, for devices that support this feature, if the disks in the Routing Engine support the SATA standard, this command sanitizes the disks using the PURGE NIST media sanitization level, according to the NIST 800-88 standard. The PURGE level is comprised of both the CRYPTO_SCRAMBLE (if supported by the SATA SSD controller) and the BLOCK_ERASE mechanisms. The CRYPTO_ERASE mechanism (if supported by the SATA SSD controller) is followed by the BLOCK_ERASE mechanism in all cases of sanitization. Whenever the CRYPTO_SCRAMBLE mechanism is not supported, only the BLOCK_ERASE mechanism is run. When the disk sanitization is complete, the system copies the current running OS from RAMDISK to the SATA disk. Once the current running OS is installed, the system reboots and comes back to the factory default configuration.

CAUTION:

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:

  1. Issue the request system zeroize operational mode command.
    content_copy zoom_out_map
    user@host> request system zeroize
    warning: System will be rebooted and may not boot without configuration
    Erase all data, including configuration and log files? In case of Dual RE system, both Routing Engines will be zeroized. [yes,no] (yes)
  2. Type yes to sanitize the device and revert to the factory default configuration.
  3. Complete the initial configuration of the device. See either the hardware guide for your product or the Initial Configuration page in the Junos OS Evolved Day One + Guide. You can also copy a configuration file from a remote server or other off-box location to the device. See Restore the Configuration from a Backup Copy after a USB Software Installation.
footer-navigation