About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Junos gives you two ideas that are easy to mix up. commit confirmed activates a candidate configuration and, if you do not confirm it in time, returns the device to the previous configuration on its own. The rescue configuration is a named copy of a committed configuration that you chose to save. It does not update itself when you commit. If you save it after a bad commit, the rescue is the bad commit.
A third action, the platform snapshot operation, is neither of those. The commit guide says to use it only after you are satisfied the new configuration is running, and it warns that once you have taken the snapshot you cannot return to the previous software, because the running and backup copies are then the same.
This article is a recovery plan for those three mechanisms. It is not a command sequence to type on a production router. Neither page was executed, and neither page prints a Junos release number.
Why it matters
A change that locks the operator out is the ordinary failure. The device is fine. The path to it is not. commit confirmed is the control Juniper documents for that case: you commit, you test, and if you cannot confirm, the device returns by itself.
A corrupted active configuration is a different failure. The rescue page says that if the active configuration is corrupted, the device automatically loads the rescue configuration as the active configuration. The page does not define corrupted. This article does not invent a test for that sentence. What the page does define is how the rescue file is created, and that definition is the part operators get wrong.
A dual Routing Engine, or a multichassis system, adds a third failure: one engine has the new configuration and the other does not, because a lock stopped the synchronisation. Forcing the lock is a documented override. It is not evidence that the configuration being forced is the one you want to keep.
What a commit stores
Junos edits a candidate configuration. The commit guide says commit checks that candidate for syntax errors and, if it finds none, saves it as juniper.conf.gz and activates it. The configuration that was active becomes the first rollback file. Older rollback files shift by one. The device keeps at most 49 rollback configurations, numbered 1 through 49.
The same paragraph then disagrees with itself about the file names. It first calls the newest rollback juniper.conf.1.gz, and the next juniper.conf.2.gz. It then says the current file and the first three rollback files, which it names juniper.conf.gz.1, juniper.conf.gz.2 and juniper.conf.gz.3, are in /config, and that files 4 through 49 are in /var/db/config. Both spellings are on the page. This article does not decide which name is on disk. A recovery plan that opens files by a guessed name is guessing. Use the operation the documentation names, on a release you have read, rather than copying a filename out of a paragraph that contains two.
If rescue.conf.gz exists, the commit guide places it in /config as well. Factory default files are in /etc/config. Those are not the rescue file and they are not rollback 1. Returning to the factory default is not what either page describes as recovery of your configuration.
The practical consequence of the two directories is smaller than the filename argument and more useful. A copy of /config alone, if the page's placement is what your release does, holds the active configuration, the rescue file, and only the first three rollbacks. Rollbacks 4 through 49 are in a different directory. Backing up one directory is not backing up the history.
Commit confirmed
The commit guide's section "Activate a Device Configuration with Confirmation" is the control for a change that might cut you off. You commit the candidate with commit confirmed. The page says the commit will be rolled back in 10 minutes unless confirmed. The configuration is checked for syntax, and if it is valid it is activated temporarily, 10 minutes by default, and starts running.
If you do not confirm in that time, the operating system rolls back to the previous configuration and sends a broadcast message to logged-in users. The page calls this automatic rollback. The reason it gives is the one operators care about: if the change prevents access or causes other errors, the device returns to the previous configuration and restores access after the timeout.
The guide describes a configurable confirmation interval and a read-only commit-history view that reports a pending rollback. This article supplies no timer-setting or confirmation sequence. The exact release’s command reference and controlled verification must establish the accepted interval and what action ends the pending rollback before an operator relies on it.
One detail is especially consequential: the page describes a configuration-check action as capable of confirming the pending change. It must therefore not be treated as a harmless syntax check during that window. This review does not recommend using that action to confirm a production change; it records the risk so the approved release-specific procedure can distinguish inspection from permanent acceptance.
The confirmed-commit feature also exists in private edit mode. A private edit is still a commit. It is not a sandbox that skips the timer.
commit at is a different feature on the same page. It activates the candidate at a future time, or at reboot. The time is interpreted in the router's clock and time zone. A scheduled commit is not a confirmation timeout. This source does not establish that the scheduling and confirmation forms can be combined; do not infer that syntax or behaviour. Do not treat a scheduled commit as the safety net.
Our recommendation is to require a tested, release-specific method for changes that could remove management access, with independent console access and an explicit acceptance decision. A timer is useful only when its behaviour, confirmation action and limits are understood. Do not confirm by habit while testing the changed path.
The rescue configuration
The rescue page, independently reopened live on 13 November 2026, says a rescue configuration is the known working configuration. It also says you save it yourself. The command it names is the explicit rescue-save operation, and it says that command saves the most recently committed configuration so you can return to it without remembering a rollback number. It can be a last resort if the device configuration and the backup configuration files are damaged beyond repair.
Those two statements have to be held together. The file is "known working" only if the configuration you saved was known working. The command does not search for a good one. It stores the latest commit. Saving the rescue after a bad commit, or during the window when a commit confirmed change is the latest commit, stores that change. The automatic load the page describes, if the active configuration is corrupted, would then load the bad one.
Returning has two separate state transitions: loading the rescue into the candidate and explicitly activating the candidate. Loading alone is not activation. The production command sequence is intentionally omitted here. If the rescue configuration does not exist, or is not a complete, viable configuration, rollback fails, an error is shown, and the current configuration stays active. A missing rescue file does not wipe the device. It also does not save you.
The rescue-delete operation removes the saved rescue configuration. Deleting it because it is old, without saving a new one from a commit you have accepted, leaves you with the failure mode the page just described: rollback fails and the current configuration remains.
The commit guide and the rescue page were not compared on a device. One says the file is rescue.conf.gz in /config when it exists. The other describes the commands. A plan should name the release and should not assume every platform keeps that path. What both pages support is the operational rule: the rescue file is a deliberate save of a committed configuration, and loading it does not activate it until a commit.
Snapshot is a copy forward
The historical storage-layout discussion describes a platform snapshot as copying accepted software to alternate boot media; it is not an instruction to perform that operation during this recovery. For the storage layout described on that page, the operation copies the root file system to /altroot and /config to /altconfig. Those historical paths and device media must not be assumed for every Junos platform. Root and /config are on the flash drive. The alternate file systems are on the hard disk if the router has one.
The warning is the recovery point. After the snapshot, you cannot return to the previous version of the software, because the running and backup copies are identical. A snapshot taken to "be safe" before you know the commit is good copies the unproven configuration onto the alternate media and, on this page's wording, throws away the previous software copy. It is a promotion, not an undo.
Our recommendation, not an extra Juniper rule: do not snapshot during a commit confirmed window, and do not snapshot in order to keep a way back. Any decision to replace alternate boot media needs the platform-specific procedure, an accepted configuration and a preserved recovery copy; this article supplies no snapshot execution step.
Two Routing Engines
The commit guide describes two ways a configuration moves beyond the engine you are typing on.
Synchronisation copies a configuration from one Routing Engine to the other in the same chassis. The command is commit synchronize. If one engine is locked, synchronisation fails. The forced synchronisation option overrides that lock and synchronises the files. Force does not mean "keep the good configuration". It means the lock does not stop the copy. If the configuration you are forcing is the bad one, both engines have it.
Distribution, on a multichassis device, happens automatically. There is no command to control it. If a configuration is locked, that locked configuration does not receive the distributed file, and synchronisation fails. The lock owner and configuration state must be understood before an authorised resynchronisation procedure is chosen. The page adds that the forced synchronisation option on a multichassis platform does not push past a lock on a remote device. The remote synchronisation still fails until that lock is cleared and the synchronisation is issued again.
A recovery plan for a dual-engine or multichassis system has to say which engine is being changed, whether the other engine is supposed to stay on the previous configuration until the change is confirmed, and who is allowed to clear a lock. Forcing a lock during an incident, because the engines differ, can erase the engine that still has the working configuration. The page tells you what force does. It does not tell you to use it as a repair.
What to decide
Before a change affecting reachability, the operator needs an approved release-specific change and rollback procedure. It must identify the timer behaviour, which inspection actions are safe, and which explicit acceptance action makes a pending change permanent. Someone who can reach the device without the path under change is named. This article does not describe console cabling.
The rescue configuration is saved from a commit that has been accepted, and it is not saved again until the next accepted commit. It is not refreshed by a timer. If the last save is months old, that age is the recovery point for the corruption case the rescue page describes. Say the age. Do not call the file current.
Numbered rollback files are history, up to 49 commits, split across two directories on the page we read. The command to load rollback number 1 was not on either page opened for this article. Do not invent it from the rescue command. rollback rescue is the return command the rescue page actually states, and it still needs commit.
the platform snapshot operation waits until the configuration and the software are the ones you intend to keep. It is not the way back to this morning.
On a dual Routing Engine, synchronisation is a decision. Force is a lock override. A lock protects a configuration editing operation; it is not a substitute for a separately preserved known-good checkpoint.
Risks and limits
The live Juniper commit and rescue pages were both independently accessible on 13 November 2026. Their publication dates and a single applicable Junos release are not stated. Archived copies provide historical context, not current platform validation.
The filename contradiction, juniper.conf.1.gz beside juniper.conf.gz.1, is left as a contradiction. The commit check confirmation sentence is reported as written. It was not tested. The automatic load of a rescue file when the active configuration is corrupted is reported as written. The page does not define the condition, and it was not tested.
No commit, rollback, rescue save, snapshot or lock override was performed. Cisco IOS XE replace is a different model, aimed at a complete saved file, and it is not evidence for these commands.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No equipment was configured, no article commands were executed and no lab behaviour is claimed. This is educational source research, not an approved production recovery procedure.
Sources
- Juniper Networks, Commit the Configuration, Junos OS. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html — commit model, rollback file retention and directories, rescue.conf.gz path, factory defaults path, commit confirmed including the 10-minute default and confirmation by commit or commit check, commit at, commit synchronize and forced synchronisation risks and platform snapshot limits. Live official page independently reopened 13 November 2026; the earlier draft used an archive capture.
- Juniper Networks, Rescue Configuration, Junos OS. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-rescue-configuration.html — rescue as a known working configuration, automatic load if the active configuration is corrupted, request system configuration rescue save of the most recently committed configuration, separate candidate-loading and activation states, failure if the rescue file is missing or not viable, saved-rescue removal behaviour. Live official page independently reopened 13 November 2026; the earlier draft used an archive capture.
This article was originally published on .