The Configuration Backup workflow pulls the running configuration off a network device, compares it against the intended configuration that Config Manager would deploy, and persists the snapshot to the Config Store. It is the canonical way to capture a known-good record of what a device is actually running, and the primary mechanism Config Manager uses to detect configuration drift between the device and Nautobot.
The workflow runs directly from the Config Manager UI for ad-hoc backups, on a schedule for routine snapshots, and as a child workflow at the end of Reprovision and Deploy runs.
Before running a backup, confirm the following are in place:
backup_path field on the device’s Nautobot data; without it, the persist stage cannot record where the backup landed.The workflow form takes the following inputs:
After submission, a status page appears showing each stage as it runs. A typical backup completes in under a minute against a healthy, reachable device.
The workflow defines three stages. The first two run in parallel; the third depends on both and runs once they finish. None of the stages require manual approval.
load_running_configuration — Pull the running config from the device.
Fetches the device record from Nautobot, attaches device search attributes to the workflow for observability, and then calls the load_running_configuration activity to read the device’s running configuration. The activity has a 5-minute start-to-close timeout and retries up to 3 times on transient errors.
The full running configuration is included in the stage output so it is visible on the workflow status page.
check_drift — Compare running vs. intended configuration.
If the caller already supplied an intended_config_commit_id, the stage short-circuits and reports no drift — this is the path Deploy workflows take, because they just applied the intended config and do not want their own change flagged.
Otherwise, the stage loads the intended configuration for the device from the Config Store and runs perform_candidate_diff to compare it against what is on the device. The diff output is included in the stage display, and the commit ID of the intended configuration is recorded so the persist stage can mark the backup as matching that commit. The diff activities have a 1-minute timeout and retry up to 3 times.
persist_backup — Write the snapshot to the Config Store and record it on the device.
Persists the running configuration to the Config Store with a commit message of the form Backup trigger: <TRIGGER> User: <user>, then records the backup against the device via the Config Manager plugin. The plugin record links the backup to the originating workflow ID, the Config Store commit ID, the device’s backup_path, and (when known) the deployed intended-config commit ID, so the device’s history can show “this is the running config as of commit X, while the deployed intended config was commit Y.”
The stage returns a changed flag indicating whether the new backup differs from the previous one on record. Each activity has a 1-minute timeout and retries up to 3 times.
After all three stages complete, the workflow archives its results and returns the changed flag from the persist stage.
Drift is detected by diffing the device’s running configuration against the intended configuration the Render Service most recently produced for that device. Behavior depends on how the workflow was invoked:
Direct invocation (API or scheduled). intended_config_commit_id is empty, so the workflow loads the latest intended config from the Config Store, diffs it against the running config, and sets has_drift based on whether the diff is non-empty. When drift is detected, a Slack message is posted alerting that drift was found on the device and linking to the workflow run.
Child of a Deploy or Multi-Deploy workflow. The parent passes its intended_config_commit_id so the backup knows exactly what it just applied. The check_drift stage skips the diff entirely and records that commit as the deployed configuration. This prevents the post-deploy snapshot from being reported as drift against itself.
Child of a Reprovision workflow. No intended_config_commit_id is supplied, so drift detection runs normally. Immediately after ZTP, the device should be on the latest rendered config and the diff is expected to be empty; a non-empty diff here points to a render-vs-device mismatch worth investigating.
If drift detection finds no diff and the call was direct, the workflow updates the recorded deployed commit ID to the current intended config commit so the device history stays in sync with the latest known-good render.
Confirm the backup succeeded by checking the following:
Workflow status shows all three stages green on the Config Manager run page. The load stage display contains the running configuration; the drift stage display either reports no drift or includes the diff in a fenced code block; the persist stage display links to the Config Store commit.
Config Store commit is present at the device’s backup_path with a commit message of Backup trigger: <TRIGGER> User: <user>. Open the commit in the Config Store to confirm it matches what the device is running.
Backup record is visible on the device’s Config Manager Info tab in Nautobot, with the new commit ID and a timestamp matching the workflow run. The changed flag tells you whether this backup differs from the previous record.
No spurious drift alert. Drift posts a Slack message when detected outside of a Deploy run. If the alert fires and you expect the device to be in sync, treat it as a real drift event — see Common issues below.
“Missing user for backup attribution” message in the workflow log.
The workflow was invoked without a user. API calls populate this automatically; if you are calling the workflow programmatically, make sure the caller forwards the user (and optional user domain) on the input.
Drift alert fired but the device is supposed to be in sync.
The running config and the rendered intended config differ. The diff in the check_drift stage shows exactly what changed. Common causes:
load_running_configuration fails to reach the device.
The device is unreachable or credentials are wrong. Confirm the management IP is correct in Nautobot, that the device is reachable from the Config Manager cell, and that the secrets store has current credentials for the site. If the device was just reprovisioned, allow ZTP to finish before re-running the backup.
Drift stage fails loading the intended configuration.
No rendered config exists for the device. Trigger a render by making a no-op change to the device’s config context in Nautobot, or call the render service API directly; see Render Service. Once a render lands in the Config Store, re-run the backup.
persist_backup fails to write to the Config Store.
Usually a Config Store auth or path issue. Confirm the device’s backup_path is populated in Nautobot and that the Config Store credentials in the Config Manager cell are current.