交换机里通常跑着两份配置：running-config 是内存里的当前生效配置，startup-config 是闪存里下次启动加载的配置。改配置改的是 running，保存才写进 startup。这个区分决定了回滚方式：
如果改动没有写入 startup，重启设备就能回到原配置——这是最省事的回滚。
如果已经保存，就必须用备份文件覆盖回来，或者依赖双配置区切换。
双配置区（两份 startup 存储区）和双镜像分区是工业交换机的常见设计：可以在一份配置上工作、另一份保留为可用基线，切换靠一条命令完成，不用重灌固件。选型时值得确认这两个特性是否存在，它们在现场故障时的价值远高于多两个端口。
| 通道 | 传输方式 | 适合规模 | 主要代价 |
|---|---|---|---|
| 手工 CLI 复制粘贴 | 串口/SSH 终端 | 单台排障、临时取证 | 无法批量，人工出错率高 |
| TFTP | UDP 69，无认证 | 内网小批量 | 无加密无认证，跨网段要放通 UDP |
| FTP / SFTP | TCP 20/21 或 TCP 22 | 批量定时备份 | FTP 明文传口令；SFTP 依赖 SSH 支持 |
| SNMP + 网管平台 | UDP 161/162 | 上百台规模 | 依赖厂商 MIB，配置文本格式各异 |
| 网管平台（厂商私有） | HTTPS / 私有协议 | 多厂商混合 | 平台本身的许可与维护成本 |
规模决定通道。十几台用 SFTP 加计划任务就够，上百台就要上平台，因为人工维护设备清单、校验备份完整性这些事，靠脚本到后期会失控。
加密这一点容易被忽略：备份文件里的口令通常是加密存储的，加密密钥与设备或平台绑定。把 A 设备的配置还原到 B 设备，往往在认证环节卡住；升级过固件版本的设备，配置里新增字段的默认值可能与旧备份不兼容。备份文件本身要按设备型号 + 版本号归档，不要只存一个文件名。
发现"某台设备和基线不一致"是变更管理的第一步，比对的局限要先知道：
文本比对能看出的：行级别的增删、VLAN 列表变化、ACL 规则顺序调整、接口描述变化、静态路由增删。
文本比对看不出意义的：同一台设备两次备份的差异里，最常出现的是时间戳、会话信息、动态生成的证书字段、统计计数的快照。这些行每次都不一样，会淹没真正的变更。做比对前先过滤掉这类行，否则一份配置能刷出几百行"差异"。
结构化比对能看出的：按配置块（接口、VLAN、ACL、路由）对齐后比较，能把差异定位到具体功能块，比逐行更实用。前提是配置文本可以被规则解析，各厂商语法不同，需要按平台维护解析规则。
比对看不出但会致命的两件事：一是"配置写法变了但语义相同"（同样的 ACL 用不同的匹配表达），二是"配置没变但环境变了"（对端设备换了、链路速率改了、上游 VLAN 调整了）。这两类问题靠 diff 无解，只能靠变更单和拓扑文档。
回滚机制有两种，都值得提前确认设备是否支持：
自动回滚：下发配置后设置一个确认窗口，例如 5 分钟。窗口内不执行确认命令，设备自动重启并加载回滚配置；确认了才把新配置写入 startup。这个机制把"忘记确认"这种人为失误的后果降为零。
双配置区切换：在保留基线的前提下改另一份配置，出问题切换回基线。适合变更幅度大、需要快速反复切换的场景。
窗口时长怎么定，取决于业务的验证方式。摄像头画面能立刻看到，5 分钟够；PLC 控制回路、跨设备路由变更需要更长的观察期，可以设 10~15 分钟。窗口越短，回滚越及时，但留给验证的时间也越少，实操中 5~10 分钟是常见区间。
另外一条硬约束：回滚不能保证业务不丢包。配置切换过程中接口会重新加载，业务侧的 TCP 连接、组播成员关系、ARP 表都要重建。把回滚当成"无损撤销"是常见的预期错位。
场景：一个园区 200 台管理型交换机，分布在 5 个片区，需要每周做一次全量配置备份，并通过 SFTP 存到一台备份服务器。单台配置文本平均 120 KB（含 VLAN、ACL、接口描述）。
第一步，算数据量。200 × 120 KB = 24 MB，压缩后（配置文本压缩比通常 4~6 倍）约 5 MB。容量完全不是问题。
第二步，算会话开销。真正耗时的是建立 SSH 会话和执行导出命令，而不是传文件。按每台设备的会话建立加命令执行加传输约 8 s 计：200 × 8 s = 1600 s ≈ 27 分钟（单线程串行）。
第三步，算并发后的时间。备份服务器对每秒新建 SSH 会话数有限制，工业交换机的管理面 CPU 也弱，并发过高会让设备 CLI 变慢甚至拒绝连接。按并发 10 台计算：1600 ÷ 10 = 160 s ≈ 3 分钟。这已经是保守值。
第四步，定窗口。把备份任务放在业务低谷时段，预留 30 分钟窗口（3 分钟执行 + 重试 + 少量设备超时重试）。如果并发降到 5 台，时间翻倍到 6 分钟，仍远小于窗口。真正需要担心的是串行执行加超时重试的脚本：一台设备连不上重试 3 次、每次超时 30 s，200 台里只要有 20 台异常，就会多耗 30 分钟。
第五步，加校验。备份完成后比对两件事：文件大小是否与前一次同量级（明显变小说明导出被截断），配置行数是否在合理区间。这两项校验能拦下大部分"备份文件存在但内容无效"的情况。
结论：200 台设备的每周备份，用 SFTP 加并发 10 的脚本就能在 3 分钟内完成，容量占用 5 MB 级。瓶颈从来不是带宽，而是会话建立速度和异常设备的超时重试。
| 根因 | 表现 | 规避方式 |
|---|---|---|
| 口令与账号不一致 | 部分设备认证失败，脚本中断 | 变更前先跑一次连通性验证；账号变更走统一流程 |
| 配置模板与设备版本不匹配 | 下发部分命令报错，配置处于半完成状态 | 按型号与固件版本分组下发，不混用模板 |
| 端口命名与拓扑差异 | 命令打在错误端口上，业务中断 | 模板变量来自设备清单，且先在一台上验证 |
第一类的可怕之处在于"半成功"：20 台里 15 台成功、5 台失败，如果没有记录哪些成功，后面补做时容易重复下发。规避方法很直接——脚本要输出逐台结果并落日志，重试时按失败清单执行。
以下为通用语法示意（不同平台命令不同，以实际 CLI 为准），用于说明顺序而非照抄：
; 示意：变更前导出与基线记录 show running-config > baseline-<设备名>-<日期>.txt ; 示意：应用变更后设置确认窗口 config revert timer 5 ; 5 分钟内未确认则自动回滚 <变更命令> ; 示意：确认保留新配置 config revert confirm
变更前导出配置，记下版本号与文件校验值，写进变更单。
变更按分组推进：先 1 台验证，再 10%，最后全量，每组之间留观察时间。
下发前确认设备支持自动回滚或双配置区，否则必须准备好手工恢复路径（含串口线）。
变更窗口内安排现场值班，回滚窗口结束前不要离场。
验证项要包含业务面：端口状态、链路聚合成员、路由邻居、组播成员表，而不只是"配置能保存"。
归档时把配置文件名与设备名、日期、固件版本绑定，避免还原时版本错配。
锐应科技的工业交换机与 PON 局端设备都提供配置导入导出与批量下发能力，8+4 口机型的接口与管理方式见 工业交换机方案页；同一套网管习惯也可以用在 PON 侧，mini GPON OLT L102P（2 口 GPON、2×GE + 1×SFP+ 10GE 上联、单口 1:128 分光）支持配置备份与恢复，相关方案见 PON 接入方案 与 关于锐应。
不绝对。不保存意味着重启后回到 startup 配置，但改动在运行期间仍然生效，业务可能已经被影响；而且设备异常掉电重启时，改动会突然消失，出现"配置回退导致业务再断一次"的情况。正确做法是改动前先导出基线，改完验证通过再保存，让配置状态始终明确。
配置里的口令一般用设备或平台绑定的密钥加密，密文与设备身份绑定。换台设备还原时，认证环节会失败。解决办法有两个：备份时把关键口令单独记录在密码管理系统里，还原后重新设置；或者用支持口令替换的网管平台，在还原时把密文替换为目标设备自己的密文。
不会。配置文本压缩后总量只有几兆字节，真正的开销在会话建立。按并发 10 台、每台 8 s 计算，全量约 3 分钟完成，占用的是一个低峰时段的带宽尖峰，量级远小于一次固件升级。需要控制的是并发数，管理面 CPU 较弱的设备并发过高会拒绝连接。
取决于验证方式。摄像头、显示类业务重启后画面立刻恢复，5 分钟足够；涉及路由邻居重建、PLC 控制回路切换的场景，建议 10~15 分钟。窗口越长，回滚越慢，但验证越充分，两者要对项目业务中断容忍度做一次明确的取舍并写进变更单。
先过滤掉时间戳、会话信息、统计快照这类每次都变的行，剩下的是真实差异。再按功能块分类：VLAN 与接口描述类差异通常无害，ACL、路由、生成树、聚合配置的差异要逐条核对变更单。找不到变更单对应的差异，一律按"来源不明"处理，先查清再继续。
配置备份的意义不是"存了文件"，而是"能拿回来"。四种通道按规模选、比对按功能块看、回滚按窗口设，三件事合起来才构成预案。200 台设备的例子说明备份本身只要 3 分钟，真正吃掉时间的是异常设备的超时重试和半成功状态，这两项要靠逐台日志和分组推进来兜住。
