Pair Zabbix with rConfig. Back up every device configuration. Prove compliance on demand.

Open the Zabbix forum and search “config backup”. You’ll find a decade of threads from network teams stitching together bash scripts, SNMP writes, TFTP servers and cron jobs. Some of them are elegant. Most are running in production with nobody sure who last touched them.

Zabbix was never built to pull running-config from your Cisco, Juniper, Arista or Fortinet devices. That’s not a flaw. It’s a scope decision, and the Zabbix team has been pretty upfront about it. Network configuration management is its own discipline, and it lives in its own tooling category.

That’s rConfig. Vendor-agnostic. 200+ device profiles out of the box. Installed on-prem or in your private cloud. Your Zabbix hosts become rConfig devices over the Zabbix API, and every configuration on every one of them lives in rConfig’s versioned archive from that point forward.

rConfig doesn’t poll interfaces, doesn’t graph throughput, doesn’t ingest SNMP traps. That’s Zabbix’s job, and after twenty years of open-source development Zabbix does it better than almost anything else in the category.

What rConfig does is what Zabbix doesn’t: capture configuration, track how it changes, and prove what it looked like when someone needs to know. Self-hosted on-prem, VM or bare metal, in your private cloud, or alongside your Zabbix proxy estate. Vendor-agnostic. Multi-tenant capable. Your ops team is running it inside 30 minutes on V8 Pro or Vector.

If you’re in scope for NIS2 or DORA, you need two different pieces of evidence. You need to prove the network was available, and you need to prove it was configured correctly. Zabbix produces the availability evidence. rConfig produces the configuration evidence. Neither tool alone satisfies both halves of the audit.

Run both and your compliance team stops asking the NOC for screenshots at 4pm on a Friday. Policy checks run automatically, every day, against every device Zabbix knows about. When the auditor asks, the report is already waiting. If you’re running rConfig alongside Zabbix already, you likely have 80 percent of what you need to respond to a DORA operational-resilience request without pulling an engineer off on-call.

The Opensource ICT Solutions post on blog.zabbix.com is the best public write-up of a Zabbix plus Oxidized integration. It’s the right reference if you’re going that route, and for shops with a dedicated automation engineer it works.

What Oxidized doesn’t give you: a web UI your NOC can operate on day one, pre-built multi-vendor compliance policies, commercial support with SLAs, role-based access control, SAML SSO, approval workflows, managed upgrades, and NIS2 or DORA reporting that doesn’t need a Python developer to generate.

What a home-grown script using SNMP writes doesn’t give you: any of the above, plus it’s the single point of failure nobody on the team wants to be responsible for. When the engineer who wrote it leaves, the knowledge leaves with them.

Most teams move to rConfig after they outgrow the operational cost of the open-source path. If your audit exposure has caught up with you, or if your ops manager is one departure away from losing the only person who understands how the script stack was held together, that’s usually the tipping point. Other monitoring and source-of-truth integrations (Statseeker, NetBox) follow the same pattern if your stack extends further.