Cisco Catalyst Configuration Restore: Copy Merge vs configure replace
Short answer
On Catalyst 9300 with IOS XE, copying a saved configuration into running-config merges commands into the current state. configure replace instead reconciles the running configuration against a complete replacement file, including removing eligible commands absent from that file. Choose the operation from the required end state, and verify the result before saving it for the next boot.
Identify the restoration target
This guide covers authorized configuration recovery using the Catalyst 9300 IOS XE 17.12.x workflow. Check the installed release and command help before adapting it to another Catalyst family. It does not describe factory reset, software installation, or erasing customer storage.
Decide which baseline should be restored: a pre-change capture, the approved production configuration, or another reviewed checkpoint. A file named “latest” is not enough evidence. Associate it with the correct switch, release, hardware layout, and collection time.
From privileged EXEC mode, collect identity and current state:
show version
show running-config
show startup-config
show archive
Keep these captures in an approved private record. Configurations can expose passwords, addresses, certificates, and operational relationships. Do not paste an unsanitized backup into a public ticket or blog comment.
Choose merge or replacement deliberately
Use a merge when the approved task is to add a small set of commands and retain the existing configuration. Do not expect omitted lines in the source to disappear. This is why restoring an older file with a copy operation can leave newer settings behind.
Use replacement when the approved task requires matching a complete known baseline. Check file integrity, readable storage, available memory, and compatibility with the current hardware. A command fragment or a diff is not a complete replacement configuration.
| Goal | Candidate approach | Required review |
|---|---|---|
| Add selected approved settings | Merge | Existing settings that remain |
| Return to a complete baseline | Replace | Commands added and removed |
| Reset for resale | Separate processing workflow | Sanitization and ownership scope |
Arrange an independent console before restoring management interfaces, access lists, or authentication settings. A correct file for a different device can remove the very path used to administer this switch.
Review the file before changing running state
The following uses a synthetic local filename. Substitute an existing reviewed file on the supported filesystem; do not copy the placeholder as if it were already present.
dir flash:
show archive config differences system:running-config flash:approved-baseline.cfg
Have a second reviewer check the planned removals and management dependencies. When the file must be restored through the configuration archive, inspect the archive setup first. archive config requires a configured archive path; configure replace itself can use a suitable complete saved file without requiring archive-based file management.
For an approved replacement from privileged EXEC mode:
configure replace flash:approved-baseline.cfg
Read and handle the device's confirmation prompt. Do not add force to a reusable script just to make prompts disappear. Keep parser messages and the operation result in the transcript. Any timer or confirmed-change options need their own release-specific procedure and must not be inferred from this basic command.
Verification note: completion is not exact equivalence
Some configuration lines tied to physical hardware cannot be removed or created through replacement, and certain changes can require a reload. A parser failure must therefore be treated as an exception requiring review, even if other lines applied successfully.
Compare the resulting configuration with the approved file again. Test a fresh management login, affected forwarding paths, and required services. Investigate every residual difference; do not repeatedly apply the same file while hoping the exception will vanish.
After the running state passes all checks and persistence is authorized:
copy running-config startup-config
Record the save result separately. If recovery fails, use the independent access path and the approved fallback baseline; a save or reload is not a substitute for diagnosing partial replacement.
Store the chosen operation, file identity, diff review, parser result, service tests, and final persistence decision. CliDeck Workspace can organize the console transcript, while the remote-change preparation guide helps keep recovery ownership explicit.
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
Quick decision table
| Situation | Better fit | Why |
|---|---|---|
| One authorized engineer needs a quick low-risk task | Traditional local workflow | It keeps the workflow simple when no shared context, batch work, or durable evidence is required. |
| The work needs verification, handoff, or documentation | CliDeck or browser workspace workflow | It creates a clearer path for notes, logs, stop conditions, and final checks. |
| Multiple people or devices are involved | CliDeck or browser workspace workflow | Structured workflows reduce ambiguity and make it easier to prove what happened. |
When option A is enough
The simpler option is usually enough when one authorized engineer is doing a low-risk task locally, the device state is known, and the work does not require shared context, batch processing, or durable evidence.
When option B is better
The more structured option is better when the work needs repeatability, collaboration, verification, logging, asset linkage, or a safer handoff between people or teams.
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
- Aruba CX checkpoint auto: A Recovery Window for Remote Configuration Changes - Use AOS-CX 10.13 auto checkpoints on a CX 6200, test within the recovery window, confirm deliberately, and save startup separately.
- Arista EOS Configuration Sessions: Review, Timed Commit, and Confirmation - Stage an EOS configuration session, review changes, apply a timed commit, confirm the correct transaction, and decide persistence.
- Junos commit confirmed: A Remote Change Runbook That Keeps Rollback Available - A scoped Junos runbook for a confirmed commit, independent acceptance tests, timer inspection, and recovery decisions.
- What to Check Before Restarting a Network Service Over SSH - A practical pre-restart checklist for network services over SSH, including scope, impact, rollback, verification, and safe terminal workflow.
- Runbooks for Real Incidents: What to Write Before Something Breaks - A practical guide to writing incident runbooks before outages happen: define symptoms, checks, commands, owners, rollback steps, escalation paths, and recovery notes.