交换机配置丢了怎么办：Oxidized 网络配置备份实战指南

【免费下载链接】oxidizedOxidized is a network device configuration backup tool. It's a RANCID replacement!项目地址: https://gitcode.com/GitHub_Trending/ox/oxidized

上周三凌晨，值班同事一次误操作把核心交换机的 ACL 清了一半。想回滚时发现，这台设备的配置"只存在于设备本身上"，上一次有人手工抄的备份还是半年前的。事后审计追问"谁在什么时候改了什么"，没人答得上来。这类痛点的根源只有一个：网络配置没有版本控制。我后来在团队里把备份统一切到 Oxidized，做的就是网络配置备份加 Git 版本控制这件事，跑了两年没再出过这种事故。

五分钟跑通：安装、最小配置、第一次备份

先装。Debian/Ubuntu 上装完 Ruby 依赖后一条命令搞定，从源码构建则先克隆仓库：

git clone https://gitcode.com/GitHub_Trending/ox/oxidized cd oxidized rake install

然后生成一份能跑的默认配置。首次运行会自动在~/.config/oxidized/下铺开 config 和 router.db，直接打开改：

username: backup password: S3cr3tx interval: 3600 input: default: ssh output: default: file file: path: ~/oxidized-backup source: default: csv csv: file: ~/.config/oxidized/router.db map: name: 0 model: 1 username: 2 password: 3

router.db 里给每台设备加一行主机名:模型:用户名:密码，比如core-sw1:ios:backup:S3cr3tx。启动后看日志确认第一份配置落盘：

oxidized ls ~/oxidized-backup # 应该看到 core-sw1.cfg

看到.cfg文件出现，备份链路就通了。

它是怎么工作的：一条配置的完整旅程

跑通之后，你可能想搞清楚它背后到底在干嘛。Oxidized 里有一条清晰的数据流水线，一台设备的配置从被抓下来到入库，要经过四步：

router.db (CSV 设备清单) │ source 模块逐行读出：主机名 + 模型 + 凭据 ▼ input 模块（ssh/telnet/http...）按模型登录设备、执行命令 │ 原始输出 ▼ model 解析：:all 清洗 → :secret 脱敏 → 追加 show version 等注释 │ 结构化配置文本 ▼ output 模块（git / gitcrypt / file / http）写仓库、提交 commit

这里的模型值得单独说。模型定义就像给设备配的方言词典：告诉 Oxidized 对这台设备该喊哪句暗号（show running-config还是show configuration）、登录提示长什么样、哪些行算密码要涂掉。词典在lib/oxidized/model/下，内置一百多种 OS 类型，这就是它能"开箱即用"的原因。

四个实战场景

场景 A｜团队协作：Git 仓库配好，变更审计有据可查

第一次备份用 file 输出只是热身，日常建议直接切 git。这样每份配置是一个 commit，每次设备变更都是可追溯的历史。配置示例（单仓库存所有设备）：

output: default: git clean_obsolete_nodes: true git: single_repo: true repo: "/var/lib/oxidized/devices.git"

注意 commit 作者是 config 里的 user/email，所以把output.git.user写成Oxidized这类可识别的名字，日后git blame才好看。如果设备分了组（router.db 里按 group 划分），默认会生成default.git、<组名>.git多个仓库；加single_repo: true则全部压进一个仓库、按组分子目录。

审计时直接用 Git 命令即可。追某台交换机的变更历史：

cd /var/lib/oxidized git --git-dir=devices.git log --oneline -- core-sw1.cfg

看上一次改了什么：

git --git-dir=devices.git diff HEAD~1 HEAD -- core-sw1.cfg

git blame core-sw1.cfg能精确到每一行是哪次提交引入的。如果接了 syslog 事件（Oxidized 支持 IOS/Junos 把配置变更事件连同操作用户名报上来），commit 里会带上"谁改的"，审计时连登录设备查的麻烦都省了。

场景 B｜敏感配置落地：Git-Crypt 加密怎么接

明文配置躺进 git 仓库，仓库一旦泄露就是事故。Oxidized 内置 gitcrypt 输出，底层用 git-crypt 对文件内容做对称加密，解密权限按 GPG 公钥发放。完整配置长这样：

output: default: gitcrypt gitcrypt: single_repo: true repo: "/var/lib/oxidized/devices" user: Oxidized email: oxidized@example.com users: - "0x0123456789ABCDEF" - "alice@example.com"

要点有三。第一，users列的是 GPG 用户标识，可以是密钥 ID、完整指纹或邮箱，哪个能唯一定位公钥都行。第二，Oxidized 首次创建仓库时写入一次 user 列表，之后加人不生效，要先手动git-crypt add-user或重建。第三，git-crypt 需要装在运行 Oxidized 的机器上，密钥对要提前分发：Oxidized 账号私钥负责提交，团队各人私钥负责解密查看。

场景 C｜新设备接入：自定义模型怎么写

新买的设备查遍 docs/Supported-OS-Types.md 没模型？自己写一个比想象中短。模型文件放~/.config/oxidized/model/，文件名即模型名（router.db 里引用的名字），类名与文件名一致并继承Oxidized::Model。以给某台自研设备加模型为例：

class MySwitch < Oxidized::Model prompt /^\S+[>#] / comment '# ' cmd 'show running-config' do |cfg| cfg.gsub! /^timestamp:.*/, '' cfg end cmd :secret do |cfg| cfg.gsub! /^(password).*/, '\1 <secret hidden>' cfg end cfg :ssh do exec true post_login 'terminal length 0' end end

对照内置的lib/oxidized/model/ios.rb读一遍会更直观：prompt是判断"设备说完了"的正则；每个cmd块是一条要执行的命令加一段清洗逻辑；:secret是特殊钩子，配合全局vars: remove_secret: true就能在入库前把密码类行替换成占位符。junos.rb 的写法也类似，只是命令换成show configuration | display omit，并额外抓show version、show chassis hardware存成注释。

场景 D｜大规模环境：并发、超时与告警

设备上千台时，默认参数不够看。核心是四个旋钮（单位：秒/条数）：

interval: 3600 # 一轮全量备份的周期 threads: 30 # 最大并发抓取数 timeout: 20 # 单步操作超时 timelimit: 300 # 单台设备整个抓取任务的总时限

经验值：threads 别盲目拉满，先设 20~30 观察设备侧 CPU 和 Oxidized 日志；timelimit是硬保险，慢设备卡死不会拖垮整轮任务。运行状态可以用 stats 跟踪，stats.history_size控制保留多少条状态记录。

告警走 hooks 更省心。任何事件（node_fail、post_store、node_success等）都能挂命令，比如失败即发邮件：

hooks: fail_alert: type: exec events: [node_fail] cmd: 'echo "Backup failed: $OX_NODE_NAME ($OX_ERR_REASON)" | msmtp noc@corp.example'

配置变更推送同理，内置 slackdiff hook 会在post_store时把彩色 diff 发到 Slack 频道，token 和 channel 两个参数配好即可，详见 docs/Hooks.md。

排坑速查

症状：git 仓库权限报错（permission denied / 无法创建仓库）排查：ls -la /var/lib/oxidized/看属主和权限。 解决：仓库目录属主必须是运行 Oxidized 的用户，目录 750 即可，不要用 root 跑进程。

症状：设备连接失败（timeout / authentication failed）排查：ssh -v user@host手工连一遍，确认网络通、账号对、设备侧没限制管理平面。 解决：检查 router.db 凭据与input.ssh配置；老设备只走 telnet 时把input.default加回ssh, telnet。

症状：抓下来的配置是空的或解析报错排查：开debug: true后观察日志里登录提示与模型prompt是否对得上。 解决：多半是模型 prompt 正则不匹配或设备有额外 enable 密码，补vars: enable: xxx或参考 docs/Troubleshooting.md 调整 expect 块。

下一步

想继续深挖，官方文档都在 docs/ 下：docs/Creating-Models.md 讲模型开发与单测，docs/Ruby-API.md 讲二次开发接口。上手写第一个模型后，可以把补丁回馈给社区——新设备支持主要就靠这条路。进阶方向：用 exec hook 把备份事件接入自己的 CMDB，或叠加 file 加 git 双输出做异地留档。回到开头那个凌晨的事故：现在再发生一次，你只需要git revert那台交换机的上一个 commit，然后回答审计的那句话也变成了git log的输出。

【免费下载链接】oxidizedOxidized is a network device configuration backup tool. It's a RANCID replacement!项目地址: https://gitcode.com/GitHub_Trending/ox/oxidized