save — making the configuration persist

Intermediate⏱ ~10 mincommitsavesave <path>compare savedloadls -la /config/config.boot

What you'll learn

Distinguish `save` (no argument) from `save <path>` and what each writes
Apply the `commit; save` workflow as the standard for every change
Verify the saved configuration with `compare saved`, and explain why a shell `diff` against `config.boot` cannot do it
Recognise the failure modes where a save does not persist

Prerequisites

Verified against VyOS 1.5.x LTS (circinus) · VyOS 1.4.x (sagitta) — legacy · FRRouting 10.x (VyOS 1.5) · Linux kernel 6.6 LTS (VyOS 1.5 base) · strongSwan 5.9.x (IPsec) · WireGuard 1.0.x (kernel module + userspace tooling)

save — making the configuration persist

save is the command that turns a live configuration into a persistent one. Without it, every change reverts on reboot. With it, the change survives. The discipline of commit; save after every change is the foundation of every other safety net — the operator who skips save will eventually lose work to a power event.

The basic usage

[edit]
vyos@vyos# set interfaces ethernet eth0 address '192.0.2.1/24'
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vyos# exit

save with no argument writes the running configuration to /config/config.boot. The boot process loads this file on every reboot; the running configuration after reboot is exactly what was saved.

What `save` writes, and in which syntax

save serialises the running configuration — not the candidate — into VyOS config-file syntax. That syntax is the braced, indented form you get from show configuration, not the flat set lines you get from show configuration commands. The distinction looks academic until you try to compare the two, which is the next section and the reason it is worth naming here.

/config/config.boot lives on the persistent partition, and it is an ordinary text file the operator can read:

vyos@vyos:~$ head -12 /config/config.boot
system {
    host-name router-core-01
    login {
        user vyos {
            authentication {
                encrypted-password "$6$rounds=656000$REDACTED"
            }
        }
    }
}

Note the node name. You typed authentication plaintext-password; what is on disk is encrypted-password with a hash, because the commit replaced the node. The cleartext you typed exists in your shell history and nowhere else, which is an argument for authentication public-keys rather than a password.

`save <path>` — backup snapshots

[edit]
vyos@vyos# save /config/backups/before-upgrade.boot
Saving configuration to '/config/backups/before-upgrade.boot'...
Done

save <path> writes to the given path. The /config directory is persistent, so snapshots stashed under /config/backups/<label>.boot survive a reboot — but the subdirectory itself is not created for you. Make it once, from the operator shell, before the first snapshot:

vyos@vyos:~$ mkdir -p /config/backups

save also takes a URL, which is how a snapshot gets off the box in the same keystroke:

[edit]
vyos@vyos# save scp://backup@10.99.0.100/srv/configs/edge-01-2026-08-19.boot

An on-box snapshot and an off-box copy protect against different things. The on-box one survives a bad change; it does not survive a failed disk, a reinstall, or an operator with delete system image in their hands. Anything you would need in order to rebuild the router belongs off the box.

Verifying the save

The verification runs in configure mode and is one command:

[edit]
vyos@vyos# compare saved

compare saved diffs the candidate against /config/config.boot. Empty output after a commit means candidate, running and saved all agree — the change is live and it will survive a reboot. Any output at all means save was skipped, and the change is already scheduled for deletion at the next boot.

The timestamp is a weaker but faster check from the operator shell:

vyos@vyos:~$ ls -la /config/config.boot
-rw-r--r-- 1 root root  4538 Aug 19 14:01 /config/config.boot

A modification time older than your commit is proof the save did not happen. A modification time newer than your commit proves only that something was saved, which is why compare saved is the check that belongs in the runbook.

You cannot `diff` config.boot against `show configuration commands`

This appears in a lot of hand-written checklists and it does not work. /config/config.boot is in the braced, indented config-file syntax; show configuration commands emits flat set lines. They describe the same configuration in two different notations, so diff reports every line of both files as changed whether or not anything differs. An operator who runs it once sees a wall of output, concludes the save failed, and saves again — which is harmless — or automates it and gets an alert that never clears.

If you want a shell-level comparison, compare like with like: show configuration commands against a file you produced the same way. For the question this section is actually asking — does the saved configuration match the running one — compare saved is the command, and it is the only one that understands both sides.

Backup before risky changes

[edit]
vyos@vyos# save /config/backups/before-bgp-upgrade.boot
Saving configuration to '/config/backups/before-bgp-upgrade.boot'...
Done
[edit]
vyos@vyos# set protocols bgp neighbor 192.0.2.9 remote-as '64513'
[edit]
vyos@vyos# commit-confirm 10
...

A backup snapshot before any risky change gives the operator a known-good state to fall back to, and it is independent of the commit archive, so it survives archive pruning and it survives someone else’s twenty commits pushing yours off the end of the list.

Two things to know about that fall-back. The snapshot is loaded with load, not with rollback — load fills the candidate and leaves you to compare and commit-confirm, which keeps the reversion under the same discipline as the change. And a snapshot taken at 22:00 reverts everything committed since 22:00, not only your change, so read the compare output before committing it rather than after.

How the result is validated

ls -la /config/config.boot
ls -la /config/backups/

and, in configure mode:

compare saved

The first confirms the modification timestamp, the second confirms the snapshot was written where you meant it, and compare saved is the one that actually answers the question — empty output means the running configuration and the boot file agree.

How it fails

The production failure modes the engineer must recognise:

commit without save. The change is live but not persistent. A reboot reverts.
save to the wrong path. save /config/backups/foo.boot writes to the backup, not to /config/config.boot. The boot image is unchanged.
/config on a tmpfs. Some image-builder flows put /config on tmpfs; the saved file vanishes on reboot. The operator must persist /config to a real disk.
Disk full. save fails with No space left on device. The running configuration is untouched — save reads it, it does not modify it — so the router keeps forwarding. What you must not assume is the state of /config/config.boot: check it with compare saved and ls -la before deciding the boot file is intact, because a save that ran out of space partway through is exactly the case where the reboot is the thing that tells you.
Operator saves with candidate not committed. save serialises the running configuration, and an uncommitted candidate is not the running configuration. The file on disk is correct for what the router is currently doing and missing what you were about to make it do. This one is silent: save reports Done, and compare saved shows the uncommitted delta, which is the only signal you get.
/config/backups does not exist. save /config/backups/foo.boot cannot write into a directory that is not there. Create it once; check the command’s output rather than assuming a snapshot exists.

Rollback

save does not change what the router is doing, so there is nothing to roll back from a save itself. What needs a recovery path is the configuration the save persisted.

Restore from a snapshot. load /config/backups/<label>.boot, then compare, then commit-confirm 15, then save. load only fills the candidate; nothing has taken effect until the commit, which is what makes compare worth reading.
Restore from the commit archive. load the archived file under /config/archive/ the same way. Prefer this to rollback N.
Recover from a rescue image. Boot the install ISO, mount the persistence partition, and edit /config/config.boot directly. This is the console path and it assumes physical or OOB access.

Production discipline

Cross-course references

The Linux course’s II-Linux-Install covers the underlying filesystem. The Ansible course’s XLII-Ansible-BeyondLinux covers how to drive save from automation. The Observability course’s XII-Observability-HostAgents covers how to alert on config.boot modification events.

Quiz

Knowledge check · 4 questions

Q1. Which command writes the running configuration to `/config/config.boot`?

`commit` `save` (no argument) `save /config/backups/file.boot` `write memory`
Q2. `save /config/backups/snapshot.boot` writes to that path only and leaves `/config/config.boot` unchanged.

True False
Q3. An operator commits a change, types `save /config/backups/backup.boot` (with the path argument), and walks away. The change is not persistent. What is the most likely cause?

The operator intended to save the change but used the argument form which wrote to the backup path. `/config/config.boot` was not updated.
Q4. An operator runs `save` and the command fails with 'No space left on device'. The running configuration is unchanged; the saved file is the previous state. What is the recovery?

The disk is full. `save` cannot write. The previous saved configuration is preserved.

Passing score: 75%. Answers are checked in this browser.

save — making the configuration persist

The basic usage

save <path> — backup snapshots

Verifying the save

Backup before risky changes

How the result is validated

How it fails

Rollback

Production discipline

Cross-course references

Quiz

`save <path>` — backup snapshots