Persistence, Changes, and Recovery

Define the change and the way back

The example below is a paper exercise for an isolated lab port. It assumes Ethernet0 is verified unused, initially administratively up, outside management access and forwarding dependencies, and reserved for this exercise. On a real target, choose a verified spare port and check its VLAN, LAG, routing, ACL, mirroring, and other dependencies first.

Have console or independent management access, a maintenance window if service can be affected, and an owner for recovery. Record both intended and observed before state. Do not use a reboot as a shortcut to undo a small change: unsaved work elsewhere may be lost.

1. Preserve startup and running state separately

For the single-ASIC baseline, use a new root-only backup directory. Stop if the chosen directory already exists; choose a fresh name rather than overwrite an earlier recovery point. Configuration exports can contain credentials.

sudo mkdir -m 700 /var/backups/sonic-review
sudo cp -p /etc/sonic/config_db.json /var/backups/sonic-review/startup-before.json
sudo config save /var/backups/sonic-review/running-before.json

Controlled backup examples: create files on a lab device only after planning. Retain and review the overwrite confirmation; no automatic yes flag is used. Illustrative only; not executed on a SONiC device.

The copy preserves the existing startup file. The named config save exports current CONFIG_DB to a separate file; it does not replace the default startup file. Freeze concurrent changes while recording the baseline. This is a configuration snapshot, not a backup of the OS, vendor files, or every daemon’s independent state.

sudo python3 -m json.tool /var/backups/sonic-review/running-before.json > /dev/null

Read-only syntax check of the exported file. Illustrative only; not executed on a SONiC device.

A successful JSON parse checks syntax, not YANG validity, hardware compatibility, or recoverability. Match the image’s validation and restore procedure. Multi-ASIC systems need the supported per-instance or combined-file workflow, not this single-ASIC assumption.

Read further: 202505 configuration CLI implementation · 202505 configuration CLI tests.

2. Apply one change and use its inverse

show runningconfiguration ports Ethernet0
show interfaces status Ethernet0
sudo config interface shutdown Ethernet0
show runningconfiguration ports Ethernet0
show interfaces status Ethernet0

Controlled lab-only sequence. This would disable the chosen port; it is not executed by this page. Illustrative only; not executed on a SONiC device.

Expect administrative intent to become down and inspect whether the operational view follows. The initial operational state may already have been down on an unconnected spare port; that is why the before record matters. Unexpected impact is a reason to stop and restore.

sudo config interface startup Ethernet0
show runningconfiguration ports Ethernet0
show interfaces status Ethernet0

Explicit inverse for this example’s initial administrative-up baseline. Illustrative only; not executed on a SONiC device.

Verify restored administrative intent and compare observed state with the before record. “Startup” here brings an interface administratively up; it does not mean “save startup configuration.” If the original state was down, this inverse would be wrong. Recheck dependencies and relevant traffic evidence before closing the change.

Read further: 202505 configuration CLI implementation · 202505 interface inspection implementation.

3. Save only an accepted final state

sudo config save

Persistence action, shown separately. It overwrites the default startup configuration after confirmation. Illustrative only; not executed on a SONiC device.

This saves current CONFIG_DB, including unrelated unsaved changes; it is not a selective commit of one port. For the exercise, restore the initial state and leave the existing startup file alone unless an approved final change should persist. After an approved save, inspect the saved fields as well as running intent and operational evidence.

Read further: 202505 configuration CLI implementation · 202505 command reference (pinned).

If targeted recovery is not enough

Prefer the verified inverse for this bounded port exercise. A bulk restore is a separate maintenance operation requiring a valid, compatible baseline, console access, impact approval, and a plan to verify services, interfaces, routes, and reachability afterward.

config reload --help
# Separate maintenance recovery example; not part of the port exercise:
sudo config reload /var/backups/sonic-review/running-before.json

The first command is help only. The second is disruptive recovery, not a dry run. Illustrative only; not executed on a SONiC device.

Do not bypass confirmation, readiness checks, or service handling with force flags in a teaching recovery. A successful reload is not proof that every dependent service or packet path recovered. It also does not automatically make the chosen snapshot the default startup file. Reconcile persistence only after validation and approval.

Read further: 202505 configuration CLI implementation · 202505 command reference (pinned).

Check your understanding

Six questions, four choices each. Check each answer, review the explanation and score, and retry.