Running configuration vs startup configuration: what should you back up?
Understand active state, boot-time state, NETCONF datastore capabilities, and why one vendor-neutral backup rule cannot fit every device.
Direct answer
Back up every configuration authority needed to answer your recovery and audit questions. On platforms that separate them, running configuration represents the active state and startup configuration represents what is intended to load after reboot; capture both and compare drift. NETCONF always defines a running datastore, while startup and candidate depend on advertised capabilities, so verify the actual device instead of assuming all platforms behave like Cisco IOS.
When this guide applies
- Detect an active change that has not been saved for the next reboot.
- Prepare a recovery record that matches the device's real boot behavior.
- Map CLI configuration names to NETCONF datastores without making a false cross-vendor equivalence.
Step-by-step review
Identify the platform model
Confirm whether the device exposes distinct running, startup, candidate, controller, or cloud configuration authorities.
Read advertised capabilities
For NETCONF, use the server capability list to determine whether startup or candidate datastores exist.
Set the required scope policy
Specify which authorities must succeed for a complete backup instead of silently accepting whichever command returned data.
Capture scopes separately
Store each authority with its own source, timestamp, completeness, and evidence so one cannot overwrite the meaning of another.
Compare drift deliberately
Review running-to-startup differences when the platform separates active and boot-time state, and preserve the direction of comparison.
How network configuration works here
Cisco documents an explicit save step
On IOS XE, copying the running configuration to startup configuration preserves it for initialization; that behavior is platform-specific evidence, not a universal rule.
NETCONF advertises datastore capability
RFC 6241 defines running as required and startup or candidate through capabilities, allowing the client to discover rather than guess.
Managed wireless adds another authority
An AP may inherit configuration from a controller or cloud service, so a local device view may not contain the complete desired state.
Configuration authorities are not interchangeable
| Authority | Typical meaning | Verification needed |
|---|---|---|
| Running | The configuration currently active on the device | Whether the returned scope is complete and authoritative for the role |
| Startup | Configuration intended for initialization after reboot | Whether a separate startup store exists and how it is written |
| Candidate | A proposed configuration before commit | Whether the NETCONF candidate capability is advertised |
| Controller or cloud | Desired state for managed infrastructure | Whether this authority or the managed device owns the relevant setting |
Risks and actions to avoid
Do not assume the startup store exists
Check the platform documentation and advertised capabilities before requiring or reporting it.
Do not merge authority labels
A running-to-startup difference has direction and operational meaning that disappears if both are called simply 'the config'.
Do not push a save operation
ConfigVault's current product scope is read-only; saving or committing configuration remains an operator action outside the tool.
What the Omuuz product can—and cannot—do
What it can do
ConfigVault can capture configured authorities separately, record completeness, and compare running and startup drift when the verified profile supports both.
What it cannot do
It cannot make every vendor expose the same datastores or save, commit, or push an unsaved running configuration.
Product evidence
