Are your network config backups actually working? Oxidized + Zabbix

Oxidized is the de facto open-source tool for backing up network device configurations. It logs into switches, routers and firewalls — Cisco, Juniper, MikroTik, Fortinet, HPE/Aruba and dozens of others — downloads the running config and stores every version in Git. When a device dies or someone breaks the config, you have the last known good version and a diff of what changed.

At least, that’s the theory. In practice backups fail quietly: a password gets rotated, a device is replaced with a new IP, SSH is restricted by an ACL, a firmware update changes the prompt. Oxidized marks the node as failed and moves on. You find out when you need the backup — which is the worst possible moment.

Template: custom-zabbix-templates/oxidized — Zabbix 7.0 and newer, no external scripts.

What it does

The template reads Oxidized’s REST API (/nodes.json, provided by oxidized-web) and for every node creates:

And two triggers per node:

The second trigger is surprisingly useful. Oxidized only stores a new version when the config actually differs, so the trigger means someone changed this device. Planned changes show up as expected events; unplanned ones — at 3 a.m., on a core switch — deserve a look at the diff in Oxidized.

How it works

An HTTP agent discovery rule requests {$OXIDIZED.BASE_URL}/nodes.json once per hour. Each node becomes a discovered entity, and its status and modification time are turned into items. New devices added to Oxidized appear in Zabbix automatically, no manual work per device.

Because the data comes from discovery, the values refresh at the discovery interval (1 hour by default). That’s appropriate for backups, which typically run every few hours anyway. If you want faster detection of config changes, lower the discovery interval on the template.

Setup

1. Make sure oxidized-web is enabled and reachable from the Zabbix server or proxy:

   curl -s -u zabbix:secret https://oxidized.example.local/nodes.json | head
   

   Oxidized’s web UI has no authentication of its own, so it is usually published behind Nginx or Traefik with basic auth — the template supports that.

2. Import the template (Data collection → Templates → Import, oxidized.yaml).

3. Create a host for Oxidized itself (no interface needed — it’s an HTTP agent) and link the template.

4. Set the macros:

   Macro	Example	Meaning
   {$OXIDIZED.BASE_URL}	https://oxidized.example.local	Oxidized web URL
   {$OXIDIZED.USERNAME}	zabbix	Basic auth user (if used)
   {$OXIDIZED.PASSWORD}	(secret macro)	Basic auth password
   {$OXIDIZED.NAME.MATCHES}	`^(core	fw)-`
   {$OXIDIZED.NAME.NOT_MATCHES}	^lab-	Skip matching nodes

   The name filters are regular expressions — handy to leave out lab gear or devices that are switched off on purpose.

Typical reasons for failed backups

When “No successful backups found” fires, the usual suspects are:

• Credentials changed on the device or in your password vault, but not in Oxidized.
• Device replaced or re-addressed — the inventory (router.db or the source Oxidized reads from) still points to the old IP.
• Access restricted — a new ACL, a management VRF or a firewall rule blocks SSH from the Oxidized host.
• Firmware update changed the CLI prompt or output and the Oxidized model needs an update.

All of these are easy to fix — once you know about them.

Summary

• Oxidized backs up configs; Zabbix makes sure it keeps doing so.
• Every node is discovered automatically, with backup status and last change time.
• Alerts for failed backups and for configuration changes — your lightweight change audit.
• Filter nodes by name and protect the API with basic auth.

Need help with network device backups, Fortinet or switch management? Contact us.