> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/switch-infrastructure/config-manager/llms.txt.
> For full documentation content, see https://docs.nvidia.com/switch-infrastructure/config-manager/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/switch-infrastructure/config-manager/_mcp/server.

# Configuration Backup

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](/switch-infrastructure/config-manager/services/config-store/overview). 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.

## Prerequisites

Before running a backup, confirm the following are in place:

* **Device exists in Nautobot** with a primary IPv4, platform, and any required config contexts. The workflow looks the device up by Nautobot UUID before doing anything else.
* **Device is reachable** from Config Manager over the management network, and credentials for the device are present in the secrets store. The workflow uses NVUE to pull the running configuration on Cumulus Linux devices.
* **Intended configuration is available** for the device — that is, the [Render Service](/switch-infrastructure/config-manager/services/render/overview) has produced a rendered config in the Config Store. Drift detection compares the running config against this rendered output. If no intended config exists yet, drift detection will fail.
* **Backup path is configured** on the device record. The workflow writes the snapshot to the `backup_path` field on the device's Nautobot data; without it, the persist stage cannot record where the backup landed.
* **User attribution is present.** Backups invoked through the API carry the requesting user automatically; backups invoked from another workflow forward the originating user. The workflow rejects requests with no user attached.

## Running the workflow

1. Navigate to the Config Manager URL for your environment.
2. Click the **+** in the top right and select **BackupWorkflow**.
3. Fill in the form using the field reference below and submit.

The workflow form takes the following inputs:

| Field      | Description                                                                           | Required |
| :--------- | :------------------------------------------------------------------------------------ | :------- |
| **Site**   | The site whose device you want to back up. Drives the device list below.              | Yes      |
| **Tenant** | Optional Nautobot tenant filter to narrow the device list.                            | No       |
| **Status** | Optional device-status filter to narrow the device list (for example, `Provisioned`). | No       |
| **Device** | The target device. The list is filtered by the selections above.                      | Yes      |

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.

## Execution stages

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.

1. **`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.

2. **`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.

3. **`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 detection behavior

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.

## Verifying outcomes

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](#common-issues) below.

## Common issues

**"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:

* A template or config-context change has been merged and re-rendered, but the device has not been re-deployed yet. Run the [Configuration Deploy](/switch-infrastructure/config-manager/user-guides/configuration-deploy/configuration-deploy) workflow against the device to bring it back into sync.
* An operator made a change directly on the device. Either back-port the change into Nautobot/templates, or re-deploy to overwrite it.
* The Render Service is producing a different config than expected. Open the device's render in the [Config Store](/switch-infrastructure/config-manager/services/config-store/overview) and compare it to the device's running config; see [Render Service](/switch-infrastructure/config-manager/services/render/overview) for how renders are produced.

**`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](/switch-infrastructure/config-manager/services/render/overview). 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.

## Related guides

* [New Site Bringup](/switch-infrastructure/config-manager/user-guides/new-site-bringup) — full bringup procedure; a backup is taken at the end of each device's ZTP via Reprovision.
* [Configuration Deploy](/switch-infrastructure/config-manager/user-guides/configuration-deploy/configuration-deploy) — pushes intended config to a device and runs a backup as a child workflow.
* [Multi-Deploy](/switch-infrastructure/config-manager/user-guides/configuration-deploy/multi-device-deploy) — deploys to many devices in one workflow; each child deploy ends in a backup.
* [Config Store](/switch-infrastructure/config-manager/services/config-store/overview) — where backup commits are persisted.
* [Render Service](/switch-infrastructure/config-manager/services/render/overview) — produces the intended configuration that drift detection compares against.