RANCiD vs Oxidized: Network Config Backup Compared

Every network team eventually needs an answer to "what did this box look like before the change?". RANCiD has been the default answer since the 1990s, while Oxidized has become the modern replacement for most multi-vendor estates. The two tools solve the same problem with very different mechanics, and the choice affects how much work configuration diffs and audit trails become. This comparison covers device coverage, storage and versioning, the inventory model, and the operational patterns that actually differ once both are running.

What both tools do

Log in to each device on a schedule, run the vendor's show-configuration command, normalise the output, store a new revision only when the content changes, and emit a diff that can be mailed, pushed to Git, or queried by an IPAM/NMS.

Where they differ

Inventory models

RANCiD expects a CSV with a group name and device type, plus per-group credentials:

# router.db
core-sw1;cisco;up
core-sw2;cisco;up
fw-edge1;juniper;up
lab-sw1;cisco;down

Oxidized keeps a compatible CSV but can pull the list from a database or URL, which matters when your source of truth is NetBox or Nautobot:

# /etc/oxidized/config
source:
  default: csv
  csv:
    file: /etc/oxidized/router.db
    delimiter: !ruby/regexp /:/
    map:
      name: 0
      model: 1
      username: 2
      password: 3
model_map:
  cisco: ios
  juniper: junos
  huawei: vrp

Storage and diff quality

Oxidized's default Git output gives you the audit trail for free, including who changed what when the change came through automation:

output:
  default: git
  git:
    user: oxidized
    email: netops@example.net
    repo: /var/lib/oxidized/configs.git

# Inspect history outside the tool
git -C /var/lib/oxidized/configs.git log --oneline -- core-sw1
git -C /var/lib/oxidized/configs.git diff HEAD~1 HEAD -- core-sw1

With RANCiD, the equivalent commands depend on the Subversion or CVS layout, and per-device history is less convenient to script.

Operating either tool

# Oxidized
systemctl enable --now oxidized
curl -s http://127.0.0.1:8888/node/core-sw1 | jq .
curl -s http://127.0.0.1:8888/node/core-sw1/version

# RANCiD (cron-driven)
rancid-run -r core-sw1
cat /var/log/rancid/core-sw1.<date>

Two failure modes dominate in practice: devices whose configuration output includes volatile lines (uptime counters, timestamps, certificate serials) which create a diff on every run, and devices that stop answering SSH after a password rotation. Oxidized users usually fix the former with per-model remove_secret/filter settings; RANCiD users patch the vendor module. Both need an alert when the last successful backup exceeds the expected age.

Choosing

• New deployment, mixed vendors, wants API and Git: Oxidized.
• Existing RANCiD estate with custom Perl modules and a working escalation process: keep it; migrate only when a vendor becomes unsupported.
• Compliance that requires signed artefacts and retention policies: either tool plus an external archive (object storage, immutable bucket) rather than trusting the tool's own history.

Related reading: Network configuration backup with Oxidized, NetBox IPAM: prefixes, VLANs and IP addresses, and Ansible Jinja2 network configuration templating.

原文链接：https://www.rconfig.com/blog/oxidized-vs-rancid-a-feature-comparison