CliDeck
PlatformLog in
Workspace

Junos Rescue Configuration: Save, Review, and Restore a Known Baseline

Runbooks
#junos#operational-evidence#runbooks#remote-operations#Runbooks#network-operations
← Back to Blog

Short answer

Save a Junos rescue configuration only when the latest committed configuration is a reviewed working baseline. Inspect the existing rescue before replacing it. During recovery, rollback rescue loads the rescue into the candidate configuration; it becomes active only after a successful commit. Keep the save, load, review, and activation steps separate.

What the rescue baseline should contain

This procedure applies to authorized Junos OS CLI work on devices supporting rescue configuration. Record the exact model, software release, routing-engine arrangement, and local commit policy. Check feature support before using the workflow on a different Junos platform.

A rescue configuration is a saved recovery baseline, not a complete backup of software images, licenses, files, and every operational artifact. Keep the broader backup and device recovery plan available.

Define the baseline with the service owner. Include the management and access dependencies required for the intended recovery state. An old configuration can be valid syntax and still contain obsolete addressing, credentials, interface mappings, or routing assumptions.

Record when the baseline was accepted, who owns it, and which checks established its usefulness. These are operational decisions; a file named rescue does not supply them automatically.

Inspect before saving

From operational mode, identify the device and review the current commit history and rescue:

show version
show system commit
show system configuration rescue

If no rescue configuration exists, record that state. If one already exists, capture it in the approved private record and confirm that replacement is authorized. Saving a rescue overwrites the existing saved rescue; it is not a way to create another numbered archive entry.

Verify the latest committed configuration through fresh management access and the required service checks. Candidate edits that have not been committed are not the configuration selected by the rescue save operation.

After the baseline is approved, save from operational mode:

request system configuration rescue save
show system configuration rescue

Inspect the saved content and the command result. Protect configuration captures as sensitive records. Record the baseline's model, build, collection time, and intended recovery purpose.

Do not overwrite the rescue as an automatic closing step after every emergency change. A temporary workaround may be useful now and still be the wrong long-term recovery baseline.

Load and review during an approved recovery

Arrange independent console access before activating a baseline that changes management, routing, or authentication. Coordinate shared candidate edits; recovery must not silently discard another operator's unfinished work.

Enter configuration mode and inspect the starting candidate:

configure
show | compare

Resolve unexpected edits before loading the rescue. Then load and inspect:

rollback rescue
show | compare

Read the load response. If the rescue is absent or not a complete viable configuration, stop and use the approved alternate recovery path. Repeating the same command does not repair a missing baseline.

Review all changes in the diff, especially the access path needed for the next login. The rescue is still a candidate at this point; a successful load does not establish that the running service has recovered.

Verification note: load, commit, and service recovery are different results

Before activation, validate the reviewed candidate:

commit check

Handle errors before committing. Also check whether a confirmed commit is already pending: commit check can confirm that transaction, so coordinate its decision owner before using validation commands during such a window.

When activation is approved and validation passes, commit with an appropriate change comment:

commit comment "CHG-EXAMPLE approved rescue activation"
run show system commit

Commit comment requirements vary by release and policy; Junos OS 24.2R1 requires comments. Handle local commit scripts and multi-engine procedures using the site's established runbook.

StageRequired evidence
SavedReviewed committed baseline and rescue contents
LoadedSuccessful load and approved candidate diff
ActivatedSuccessful commit and updated history
RecoveredFresh login and required service checks

If commit fails, preserve the error and inspect the actual candidate and active state before another attempt. If service checks fail after activation, use the approved recovery path rather than declaring success from commit history alone.

Keep the rescue inventory and activation evidence in CliDeck Workspace. For temporary change protection, use the separate Junos confirmed-commit runbook; a saved rescue does not create its rollback deadline.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on approved network devices inside a planned change or lab scope.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides