Restore onto the same appliance — load saved, verify, commit, save

A same-appliance restore is the recovery procedure for a configuration that was lost or corrupted on a router that is otherwise operational. The router boots; the operator copies a saved configuration onto the router; the operator verifies the configuration is correct; the operator commits and saves.

The procedure is straightforward but error-prone. A configuration that is loaded without verification may contain the very error that the operator is trying to recover from. A configuration that is committed without save may be lost on the next reboot. The defensive idiom is the four-step procedure: load, verify, commit, save.

This lesson covers the four steps, the verification discipline, and the production failure modes where a same-appliance restore goes wrong.

The four-step procedure

The same-appliance restore is a four-step procedure:

# Step 1: Load the saved configuration into the candidate
configure
load /config/config.boot

# Step 2: Verify the loaded configuration
compare
show configuration

# Step 3: Commit the loaded configuration
commit

# Step 4: Save the loaded configuration
save
exit

The four steps are: load, verify, commit, save. Each step is required; skipping a step introduces a failure mode.

flowchart LR
  LOAD[Step 1: load] --> VERIFY[Step 2: verify\ncompare\nshow config]
  VERIFY --> COMMIT[Step 3: commit]
  COMMIT --> SAVE[Step 4: save]
  SAVE --> DONE[Restore complete]

The diagram shows the four-step procedure. Each step is a gate; the operator cannot proceed without verifying the previous step succeeded.

Step 1: load

The load command replaces the candidate configuration with the contents of a file. The file can be /config/config.boot (the current saved configuration) or any other configuration file the operator has transferred to the router.

configure
load /config/config.boot

The candidate configuration is replaced with the contents of the file. The active (running) configuration is unchanged.

The load command also accepts a URL (e.g. scp://, http://, ftp://) for loading a configuration from a remote location:

configure
load scp://backup@backup.internal/srv/configs/edge-01-config.boot

The URL form is useful when the operator wants to load a specific historical revision (e.g. the configuration as it was 30 days ago, before a problematic change).

Step 2: verify

The verify step is the operator’s defence against a configuration that is loaded but contains errors. The verification has two parts:

• compare — show the diff between the loaded candidate and the current active configuration.
• show configuration — show the loaded candidate configuration as a tree.

# Show the diff between candidate and active
compare

# Show the loaded candidate configuration
show configuration

The compare output is the operator’s primary verification. A configuration that matches the operator’s intent produces a diff that shows only the intended changes. A configuration that contains unexpected changes (e.g. a leftover from a previous debugging session) produces a diff that shows the unexpected changes — which the operator can investigate before committing.

Step 3: commit

The commit command applies the candidate configuration to the running configuration:

commit

The commit engine runs the validators; if the validators pass, the configuration is applied; if the validators fail, the commit is rejected and the candidate is unchanged.

The commit is the point at which the loaded configuration takes effect. The operator must be ready for the change: the routing protocols will reconverge, the firewall rules will be applied, the interfaces will be configured.

For remote changes, the operator uses commit-confirm with a rollback timer:

commit-confirm 5

The commit is applied; if the operator does not confirm within 5 minutes, the router auto-reverts to the previous configuration.

Step 4: save

The save command writes the running configuration to /config/config.boot:

save

The saved configuration survives reboot. Without save, the change is in the running configuration but is lost on the next reboot.

The defensive idiom: commit followed immediately by save is one operation. A change without save is a change that the next reboot will revert.

Failure modes

Configuration loaded without verification

The operator loads a configuration and commits without running compare. The configuration contains an unexpected change (e.g. a leftover from a previous debugging session). The unexpected change is applied.

Diagnostic: monitoring detects the unexpected change; the operator investigates.

Fix: roll back to the previous configuration (rollback N and commit); load the correct configuration; verify with compare; commit and save.

Commit fails

The loaded configuration has a syntactic error that the load command did not catch (e.g. an invalid IP address that is valid syntax but semantically wrong). The commit fails; the candidate is unchanged.

Diagnostic: the commit log shows the validator error.

Fix: correct the configuration; re-load; verify; commit.

Configuration loaded but not saved

The operator loads, verifies, commits, but forgets to save. The change is in the running configuration; on reboot, the change is lost.

Diagnostic: after reboot, the running configuration does not include the change.

Fix: re-load, verify, commit, save.

URL form fails

The load scp://... command fails because the SSH host key is not in the router’s known_hosts. The candidate configuration is unchanged.

Diagnostic: the load command reports an SSH error.

Fix: SSH to the remote host manually; accept the key; re- run the load command.

Rollback

A same-appliance restore is itself a rollback mechanism. The rollback N command reverts to a previous configuration revision (the VyOS internal commit history). The load command replaces the candidate with a file (the off-box file server or the Git repository).

The VyOS commit history is the router’s local rollback; the Git repository is the off-box rollback. Both should be in place.

Production discipline

Cross-course references

• LV-VyOS-Backup (vyos-lv-01-saved-configuration, vyos-lv-02-remote-backup) cover the saved configuration and remote backup that the restore uses.
• VI-VyOS-CommitRollback (vyos-vi-04-rollback) covers the rollback mechanism that the restore procedure complements.
• V-VyOS-ConfigModel (vyos-v-02-candidate-active-saved) covers the three-configuration model that the restore procedure operates on.

Quiz