Junos Rescue Configuration: Save and Recover Quickly

Every Junos administrator knows the feeling: a commit that looked harmless takes the device offline, and the rollback numbers have scrolled out of memory. The Junos rescue configuration solves this by giving you a permanent, named snapshot of a known-good configuration that survives across reboots and does not depend on remembering rollback numbers. If the active configuration becomes corrupted, a Junos device can even load the rescue configuration automatically at boot. This guide covers how to save, roll back to, verify, and delete the rescue configuration on Junos OS and Junos OS Evolved.

What the Rescue Configuration Does

The rescue configuration is a copy of a committed, known-working configuration stored as /config/rescue.conf.gz (on dual Routing Engine systems it is saved on both REs). Its main benefit is recovery: instead of hunting through show system rollback output for the right revision, you issue one command to load the rescue image of the configuration and commit it.

Three properties make the rescue configuration different from every other copy of the configuration on the box:

• It is named, not numbered. You never have to remember that rollback 7 was the good one - the rescue image is always "the configuration we agreed was safe".
• It survives reboots and software upgrades. The file lives in the /config partition, alongside the active configuration, and is not consumed by the rollback pool.
• It can be activated without a working configuration. Because Junos can load rescue.conf.gz when the normal configuration fails, the rescue file is the one recovery path that still works when the box is amnesiac (running with no usable configuration).

On a device with redundant Routing Engines, the same rescue file is written to both REs when you save it, so a Routing Engine switchover does not lose your escape hatch. On a Virtual Chassis or a multi-RE platform, run the save from the master Routing Engine.

Saving the Rescue Configuration

Save the most recently committed configuration as the rescue configuration from operational mode:

user@host> request system configuration rescue save

Best practice: save a fresh rescue after every major maintenance window or successful change, so it always reflects a state you trust rather than an ancient baseline.

A few mechanical details are worth knowing before you rely on this command in an outage:

• The command regenerates the rescue file from the most recently committed configuration, so issuing it again overwrites whatever rescue image was there before. There is no merge and no undo - if you save a rescue while the box is in a degraded state, you have just overwritten your good escape hatch.
• It is an operational-mode command and requires the appropriate permissions (a super-user class account).
• Saving does not commit anything. Your active configuration is untouched; only the rescue file changes.

Verify what you just saved, and confirm which commit it was taken from:

user@host> file list /config/rescue*
user@host> show system commit

The show system commit output lists the commit history with timestamps, which is the quickest way to confirm that the rescue image corresponds to the change you think it does. On a dual-RE chassis, check both Routing Engines if you want certainty that the file landed everywhere.

Rolling Back to the Rescue Configuration

To recover, load the rescue configuration from configuration mode and commit it:

[edit]
user@host# rollback rescue
load complete
user@host# commit

If no rescue configuration exists, or the rescue file is incomplete, the rollback fails with an error and your active configuration is left untouched - so verify that a rescue exists before you need it.

Two refinements turn this from a blind leap into a controlled operation. First, check the syntax before you commit, and preview the difference between the active configuration and the rescue image:

[edit]
user@host# rollback rescue
load complete
user@host# show | compare
user@host# commit check
configuration check succeeds
user@host# commit

Second, when the problem is that you cannot reach the box at all - a commit that denied management access is the classic case - the CLI itself may still be reachable from the console while SSH and the management interface are not. In that situation the documented fallback is to load the rescue file over the entire candidate configuration rather than merge it, so no fragment of the broken configuration survives:

[edit]
user@host# load override /config/rescue.conf.gz
load complete
user@host# commit

Because rollback rescue replaces the whole candidate configuration rather than merging into it, both of the paths above are all-or-nothing: everything not present in the rescue file is gone. That is exactly what you want during a recovery, and exactly why you should not use the rescue configuration as a day-to-day staging area.

Verifying and Testing the Rescue File

You can validate the syntax of the rescue configuration without committing it:

user@host> test configuration /config/rescue.conf.gz
configuration check succeeds

Run this test before an incident, not during one. A rescue file that was saved from a working box years ago can fail to load on a device that has since been upgraded or had hardware removed, and there is nothing more unpleasant than discovering that during an outage. Pair the syntax check with a quick inspection of the file contents:

user@host> file list /config/rescue.conf.gz
user@host> file show /config/rescue.conf.gz

Look for the parts of the configuration you actually care about - the management interface, the routing protocol sessions, the firewall filters that permit your management traffic. If those are missing, the rescue file is not a rescue file, it is a trap.

Automatic Recovery at Boot

On Junos OS releases built on upgraded FreeBSD, the rescue configuration stops being purely manual. If the system cannot activate the current configuration at boot, an automatic device recovery mode engages and the rescue configuration is loaded as the active configuration. Two signals tell you this has happened:

• The syslog message UI_DEVICE_IN_RECOVERY_MODE is generated, recording that the normal boot-time commit failed and the rescue configuration was activated.
• The CLI displays a Device is running in Recovery Mode banner in both operational and configuration mode.

There is also a related statement, dual-phase-bootup, which makes the device pick up the rescue configuration on the next reboot and then load the last user configuration, preventing the box from settling into an amnesiac state. It has a hard prerequisite: you must already have created a rescue configuration, because dual-phase-bootup cannot commit without one. A minimal, deliberately simple rescue configuration is recommended here.

On older releases, and on platforms that do not run upgraded FreeBSD (or any release earlier than the 16.1 family), this automatic recovery mode does not exist. On those systems the rescue configuration is loaded only when you run rollback rescue yourself - which is precisely why you should know where the console cable is.

Deleting and Copying the Rescue Configuration

To remove an existing rescue configuration (for example before repurposing the device):

user@host> request system configuration rescue delete

Off-box copies are a recommended extra safety net - copy the rescue file to a server so a total disk failure does not take your known-good state with it:

user@host> file copy /config/rescue.conf.gz scp://user@192.0.2.10/tftpboot/

The copy direction matters. Saving the file off-box costs nothing and gives you a path back if /config is destroyed. Restoring it is a two-step process: put the file back at /config/rescue.conf.gz, then run request system configuration rescue save from a healthy configuration so the device recognises the image as the official rescue configuration again. Treat the off-box copy as an archive, not as a live replacement for the on-box file.

On dual-root-partitioned devices there is a further layer of protection. The autostate feature backs up disk partitioning information, license keys and the rescue configuration, and checks the integrity of those copies on every boot up:

user@host> request system autorecovery state save

If any of the saved items are found to be corrupted during boot, the working copies are recovered automatically. Note the two conditions: the device must have dual-root partitioning for autorecovery to work, and the saved state is not updated automatically - after you add licenses or change the configuration you must run the save command again, or you will keep recovering an old baseline.

Rescue Configuration vs Rollback vs Commit Confirmed

The rescue configuration is one of three recovery primitives in Junos, and they are not interchangeable. Choosing the right one is most of the battle during an incident.

In practice the three work best together. Use commit confirmed for the change itself (see our guide to Junos commit confirmed and rollback), keep a rescue configuration as the fallback for when nobody remembers which rollback number was good, and treat rollback N as the fine-grained tool for stepping back one or two revisions. A rescue configuration is not a substitute for commit confirmed: it is too coarse to protect you from a single bad change, and commit confirmed is too transient to protect you from a corrupted configuration.

Rescue Configuration on Dual Routing Engines and Virtual Chassis

On a chassis with redundant Routing Engines, request system configuration rescue save writes the rescue file to both REs, so a switchover cannot leave you without it. Two operational habits keep this reliable:

• After a power-on or a long-running maintenance window, confirm the rescue file is present on the Routing Engine that is currently master, and not only on the backup.
• After a Routing Engine replacement, remember that the newly installed RE did not inherit the file until the save command runs from the master.

On a Virtual Chassis or a multi-member stack, the same command is run from the master, and the resulting rescue file reflects the committed configuration of the whole chassis rather than a single member. If you are using configuration groups to keep member-specific configuration separate - see Junos apply-groups and configuration groups - the rescue file contains the fully resolved configuration, so groups are inlined. That is a feature: it removes one more thing that can go wrong during recovery.

Automating Rescue Saves

The most common reason a rescue configuration fails to help is that it was never refreshed. Two low-effort automation patterns fix that:

1. Run the save after every change window. Add request system configuration rescue save to the end of your maintenance runbook, right after the verification steps.
2. Drive it from an external script. Because saving is a single operational-mode command, it is trivial to invoke over NETCONF - our PyEZ and ncclient automation guide covers the mechanics - or with a one-line SSH command from a jump host. Schedule it weekly so the rescue image can never drift more than a few days behind reality.

If you automate, automate the verification too: have the script run test configuration /config/rescue.conf.gz after saving and raise an alert if the check does not succeed. A silent failure here is invisible until you need it.

Best Practices and Operational Checklist

• Save a rescue configuration immediately after every successful maintenance window, and never save one from a device you are not sure about.
• Test it with test configuration after saving - an untested escape hatch is not an escape hatch.
• Keep an off-box copy of /config/rescue.conf.gz with the rest of your device backups.
• On dual-root devices, run request system autorecovery state save whenever licensing or the configuration state changes.
• Document the recovery sequence in your runbook so that the person on call at 03:00 does not have to read this article on a phone: save, rollback rescue, show | compare, commit.
• Keep the rescue configuration deliberately minimal. A small, well-understood configuration that restores management access is far more valuable than a full copy of a complex production configuration that may itself contain the fault.

Troubleshooting Common Rescue Configuration Problems

Rollback fails and nothing changes. This is the documented behaviour when the rescue configuration does not exist or is not a complete, viable configuration: the rollback errors out and the active configuration stays in place. Check that the file exists with file list /config/rescue* and that it passes test configuration.

The device comes up with almost no configuration. You are probably in amnesiac mode: Junos could not load the active configuration at boot. If automatic recovery is supported on your release, check the syslog for UI_DEVICE_IN_RECOVERY_MODE and the CLI banner; if it is not, log in over the console and run rollback rescue followed by commit.

The rescue save command is refused. You are almost certainly in the wrong login class - saving a rescue configuration requires an account with the permissions of a super-user. Confirm your class with show cli authorization or simply test with show system login.

You cannot log in at all. A corrupted configuration that denies management access is an authentication problem, not a rescue problem, and it is covered by the console-based procedures in our Junos password recovery guide.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-rescue-configuration.html

Additional reference: Autorecovery of Configuration, Licenses, and Disk Information