Configuration Backups

GridNMS automatically backs up the configuration of your network devices over SSH, keeps a version history, and shows you exactly what changed between any two versions. When a config changes, the change is also recorded in your logs — so you can see “what changed on this device” right next to the events it may have caused, and even alert on config changes with a detection.

How it works

Once a day (by default), the collector connects to each SSH-enabled device and pulls its running configuration. GridNMS compares the result to the last stored version:

• Nothing changed — nothing is stored. Timestamps and other lines that churn on every pull (like “Last configuration change” comments) are ignored, so you don’t get phantom versions.
• The config changed — a new version is saved, and a log entry records the change with the number of lines added and removed.
• The pull failed — what came back is an error from the device, not a configuration. It’s stored and clearly marked as failed, never filed as a new version of your config. See When a capture fails.

GridNMS keeps the most recent 50 versions per device.

Prerequisites

Config backup uses the same SSH access as SSH monitoring:

1. Enable SSH on the device’s class (Configure → Device Classes → your class → SSH) and set the username/password GridNMS should log in with.
2. The device must actually expose SSH — GridNMS skips devices where port 22 isn’t open.

That’s it — the Config Backup collector ships enabled in the core network pack and starts pulling on its daily schedule.

Choosing the backup command

The default pull command is show running-config, which works on most Cisco-style CLIs (IOS, IOS-XE, Arista EOS, Aruba AOS-CX, and others). Some device classes ship with their own command already set — a UniFi Gateway, for example, is backed up with its own native config dump and needs no configuration from you.

If a device family needs a different command and doesn’t already have one, set it on its device class: Configure → Device Classes → your class → Settings → Config Backup → Class override command. Every device in that class and its subclasses uses it instead. The pack’s own default is shown above the field so you can see what you’re overriding. Examples:

Platform	Command
Cisco IOS / IOS-XE, Arista, Aruba	show running-config (default)
Juniper Junos	show configuration | display set
FortiGate	show full-configuration
MikroTik RouterOS	/export

A single device that needs something different from the rest of its class can be overridden on its own page instead — see Device overrides.

You can also change how often backups run: Configure → Monitoring Packs → Core Network → Config Backup collector interval.

Backing up on demand

You don’t have to wait for the daily schedule. Open the device, go to its Actions tab, and under Trigger Actions open the Core Network drop-down and choose Run Config Backup. The run is queued immediately and its result appears in the queue history on the same tab, usually within a minute — useful right after you’ve changed a backup command and want to know whether it works.

When a capture fails

If the backup command is wrong for the device, what comes back isn’t a configuration — it’s an error from the device’s shell, something like bash: line 1: show: command not found. GridNMS recognises that and stores it anyway, clearly marked, rather than filing it as a new version of your configuration:

• the version in the list carries a Failed badge, and
• selecting it shows a warning: “This capture failed — it is not a valid device configuration”, with what the device actually returned.

It’s stored rather than discarded on purpose — a device whose backup command is wrong should be visible as broken, not silently absent. A device that keeps failing the same way doesn’t pile up one failed version per day; you get a single marked entry until something changes. When you see one, fix the command for that device’s class (above), then use Run Config Backup to confirm the fix without waiting a day.

Viewing versions and diffs

Open any device and switch to its Config tab:

• The left column lists every stored version — when it was captured, its size, and a short fingerprint.
• Changes shows what changed between the selected version and the one before it: added lines in green, removed lines in red.
• Full config shows the complete configuration as it was captured.
• Download saves the selected version as a text file.

If backups stop after a firmware upgrade or device swap

The first time GridNMS connects to a device over SSH, it remembers the identity key the device presents — the same way your own SSH client asks “are you sure you want to continue connecting?” the first time you connect to a new server, then silently trusts it after that. This protects you from a spoofed or swapped-in device answering at the same address.

If that key ever changes, GridNMS refuses to connect rather than silently trust a different device — so backups for that device will stop, even though nothing else about it looks wrong. This is expected after:

• a firmware or OS upgrade that regenerates the device’s SSH host key, or
• physically replacing the device (a new device at the same IP address).

To let GridNMS trust the new key, open the device and switch to its Config tab, then select Reset SSH host key. Confirm the action, and the next backup connection will trust whatever key the device presents and remember that one going forward. Only do this if you know why the key changed — if you don’t recognize the reason, treat it as a signal to investigate the device before resetting.

Alerting on config changes

Every captured change writes a log entry (source type gridnms:config) with the device and the number of lines added/removed. To get notified when a config changes — on all devices or just critical ones — create a detection over those log entries and turn on its notifications.