华为交换机「配置丢失」故障排查：手把手教你把「优先级」这个坑踩明白（2026 Q4 实操版·适配 VRP V200R022）

一、故障现象：哪些”症状”算配置丢失？

先把现场常见的几种”配置丢失”摆出来，免得你对着错误的方向排查：

• 重启即丢：交换机断电重启后，所有配置（VLAN、接口、路由、ACL）全部归零；
• 部分丢失：只有少数命令回到出厂状态，其余配置完好；
• 启动慢 / 卡在 “Press Ctrl+B”：说明启动文件指向了一个不存在的 .cfg 文件；
• display startup 显示路径和实际运行配置对不上：当前生效的是 startup.cfg，但你明明手动指定过 backup.cfg；
• 换板/换主控后配置漂移：堆叠或集群场景下，从交换机配置被主交换机覆盖。

如果以上症状命中两条以上，大概率就是启动文件优先级那条线出了问题。下面我们直接进正题。

二、踩坑实录：一个真实的「配置消失」现场

2026 年给客户部署一台 S5731-S24P4X 做接入层改造，三层架构跑得稳稳的——这型号是华为 S 系列里当下出货量很大的一款。结果某天园区断电恢复后，VLAN 配置全没了，IP 也没了，业务直接瘫了一片。

到场一看：

• display startup 显示启动文件是 flash:/startup.cfg，存在；
• dir flash:/ 里同时有 startup.cfg 和 backup.cfg；
• 但 display current-configuration 是空的。

问题在哪？原来上一任工程师做过一次手工切换，把 startup 指向了 backup.cfg，然后 save force 了一下。但是中间又手动编辑过 startup.cfg（没保存），结果重启时 VRP 按优先级逻辑读到了过时的那份。这事儿说白了，就是配置文件优先级 + 双备份机制这套玩法没彻底摸透。

下面把完整排查步骤拆给你看。

三、优先级机制到底是怎么算的？先把原理搞清楚

在说怎么排之前，得先讲清楚 VRP 在启动时到底怎么挑配置文件。搞不懂这个，后面所有命令都是盲人摸象。

3.1 启动顺序的三个关键参数

华为交换机启动时，加载哪个 .cfg 文件由三个东西决定：

3.2 优先级判断逻辑（简化版）

启动时 VRP 加载顺序：
1. 读 startup saved-configuration 指定的文件
2. 如果该文件存在且可解析 → 加载该文件
3. 如果该文件不存在或损坏 → 进入空配置启动（不会自动去读 backup.cfg）
4. backup.cfg 不参与自动启动回退，是工程师手工维护的冗余备份

注意：这里一定要先破一个常见误解——backup.cfg 不会在 startup 文件丢失时自动顶上，更不会覆盖当前配置。它就是一份放在 flash 里的”手动存档”，恢复的时候需要工程师自己手动操作（具体方法见第四节）。把这点搞反，是排障时绕远路的根本原因。

3.3 为什么改了 startup 之后还会丢配置？

这是最多人踩的坑：改了 startup saved-configuration 路径但没保存，或者保存了但被后续操作覆盖。VRP 里 save 命令的优先级是这样的：

• save：保存当前配置到 startup 指向的文件（覆盖原文件）
• save <文件名>：保存当前配置到指定文件（注意是「另存」，不会修改 startup 指向的那份）
• startup saved-configuration flash:/xxx.cfg：修改下次启动路径，该命令本身会持久化到启动配置，重启后生效
• save force：强制保存，会覆盖现有 startup 文件

关键点：startup saved-configuration 命令本身就会把下次启动路径写进启动配置，不需要再 save 才生效；但当前运行配置的修改，必须通过 save 才会写入配置文件。很多工程师把「保存当前配置」和「修改启动路径」混为一谈，结果重启后加载的还是旧配置。

四、完整排查流程（按这个顺序走，基本不会翻车）

第一步：先看”启动配置”，别上来就乱 save

很多人一看配置丢了，第一反应就是 save，但这其实是最坑的操作——你可能把错误的当前配置直接固化到启动文件里，再重启就更回不去了。

先看两条命令：

<HUAWEI> display startup

这条命令会告诉你：

• MainBoard startup saved-configuration：主控板下次启动加载的配置文件路径
• SlaveBoard startup saved-configuration：备板（如果有）的启动路径
• Next startup saved-configuration：下一次启动要用的文件

再确认一下 VRP 版本和文件系统：

<HUAWEI> display version
<HUAWEI> dir flash:/

第二步：对比 running-config 和 startup-config

这两份不一致，往往就是问题的根源：

<HUAWEI> display current-configuration
<HUAWEI> display saved-configuration

VRP 自带差分命令，可以直接看两份配置哪里不一样：

<HUAWEI> compare configuration

小贴士：把两份输出导出到本地，用文本对比工具（如 Beyond Compare、WinMerge）diff 一下，哪里被覆盖、哪里被回退一目了然。

第三步：检查 startup 路径是否指向了正确文件

<HUAWEI> display startup

重点看 Next startup saved-configuration 这一行。如果这里指向的是 backup.cfg 而你期望的是 startup.cfg，那重启后加载的就是旧内容。

第四步：按现场情况选恢复方法（实战常用的四种）

这是最关键的一步——根据你手里的 startup.cfg 和 backup.cfg 哪个是新的，选不同打法：

方式一：startup.cfg 是新的，直接固化路径

<HUAWEI> startup saved-configuration flash:/startup.cfg
<HUAWEI> save

执行后再次 display startup 确认路径已经更新到 Next startup。注意：save 会把当前运行配置写入 startup 指向的文件，操作前确认当前配置是你想要的。

方式二：current-configuration 还在，直接保存回 startup

<HUAWEI> save

这条命令会把内存里的当前配置写回 startup 指向的那个文件，覆盖旧内容。

方式三：startup.cfg 是旧的，但 backup.cfg 是新的——切启动路径到 backup.cfg

<HUAWEI> startup saved-configuration flash:/backup.cfg

验证一下 display startup 路径已经指向 backup.cfg，再找维护窗口重启。如果当前运行配置也需要保存，再执行 save，但注意别把 backup.cfg 覆盖成当前配置。

方式四：backup.cfg 是新的，但你想统一管理文件名——copy 覆盖回 startup.cfg

<HUAWEI> copy backup.cfg startup.cfg
<HUAWEI> startup saved-configuration flash:/startup.cfg

这样既保留了最新配置，又把 startup 路径指回标准的 startup.cfg，避免后续维护混乱。同样，如果当前运行配置需要保存，再执行 save。

第五步：交叉验证 saved-configuration 文件完整性

恢复配置后，可以检查一下保存下来的配置文件能不能被正确解析：

<HUAWEI> display saved-configuration

把这份输出和 display current-configuration 再做一次 diff，确保两份一致。如果有部分命令报”Invalid”或解析失败，说明文件可能损坏，需要从完好的 backup.cfg 重新覆盖。如果怀疑文件本身不完整，也可以用 disassemble 命令检查配置文件完整性（具体参数以对应版本手册为准）。

第六步：观察一段时间再重启

在确认业务不受影响的前提下，找一个维护窗口做断电重启测试，验证配置是否成功保留。

五、不同型号的优先级差异（S5700 / S5731 / S6700 / CloudEngine）

华为不同系列的交换机，启动配置加载机制大体一致，但细节上可能因型号和版本而异。这里挑几个主力型号说：

六、堆叠 / 集群场景下的优先级问题

堆叠（iStack）和集群（CSS）场景下，配置优先级问题更复杂，因为涉及多台设备协同：

6.1 堆叠场景

• 主交换机负责整个堆叠系统的配置管理
• 从交换机的 startup 文件在堆叠状态下一般不生效
• 如果主备切换，新主交换机的配置会和原主不一致

[HUAWEI] display stack
# 查看堆叠状态和角色

6.2 CSS 集群场景

• 集群模式下，两台交换机的配置会自动同步
• 如果某台设备的 startup 文件被单独修改，集群同步时会被覆盖
• 不建议在集群成员上单独执行 save 等配置变更操作，统一在主设备上操作，避免配置不同步

七、save 命令与 autosave 的时序冲突

这是很多资深工程师都栽过跟头的点。VRP 里 save 和自动保存类功能的优先级是：

1. 手动 save：立即执行，优先级最高
2. 自动保存触发：到时间间隔自动执行
3. 断电前：依赖设备自身是否有掉电保护机制

典型翻车场景：

避坑建议：

• 做大改动前确认自动保存状态，必要时暂时关闭（具体命令以对应版本手册为准）
• 改完路径后立即 save，并 display startup 确认
• 确认无误后再恢复自动保存

八、配置恢复后的验证清单

恢复完成后，建议按这个清单逐项过一遍：

• display startup 确认下次启动路径正确
• display saved-configuration 和 display current-configuration 内容一致
• compare configuration 差分无差异
• 重启测试（在维护窗口内执行）
• 业务流量验证（ping、tracert、业务系统访问）
• 监控自动保存类功能是否正常工作
• 记录变更（变更单、工单系统留痕）

九、常见 FAQ（搜索长尾问题覆盖）

Q1：配置恢复后多久需要再次 save？

A：没有固定周期。正常情况下，每次手动改完配置就 save 一次即可。自动保存可以作为兜底，但不能完全依赖。建议养成”改完即存”的习惯。

Q2：优先级冲突是否会影响业务流量？

A：在重启之前不会影响——当前运行的是 current-configuration，和 startup 指向无关。只有在断电、重启、主备切换等场景下，启动配置才会被加载，此时如果路径指向错误的文件，配置就会”消失”。

Q3：backup.cfg 可以直接拿来用吗？

A：可以，但要注意 backup.cfg 的生成时间。如果它比 startup.cfg 旧，替换后反而会丢更新。所以替换前一定要 display saved-configuration 看下时间戳。

Q4：堆叠情况下从交换机需要单独配置 startup 吗？

A：不需要。堆叠状态下，从交换机的配置由主设备同步，startup 文件基本不生效。单独配置反而会造成同步冲突。

Q5：CloudEngine 系列支持配置回滚点吗？

A：CloudEngine 系列（数据中心交换机）有快照类功能，可以在运行时保存多份配置快照用于故障回滚。但快照通常只在运行时生效，重启后回到 startup 文件状态。具体支持的命令以对应产品手册为准。

Q6：display startup 显示的路径和实际不符怎么办？

A：以 display startup 为准。如果它显示的路径不是你想用的，就用 startup saved-configuration flash:/xxx.cfg 重新指定，然后 save 固化。

Q7：save 之后配置还是丢了，可能是什么原因？

A：除了优先级问题，还有几个常见原因：

• flash 空间不足，保存失败
• 文件系统损坏（需要 fixdisk flash:/ 修复）
• 双主控情况下只保存了一边
• VRP 版本本身的 bug（遇到可疑问题建议查对应版本的 Release Notes，不要盲目追新）

十、避坑指南（工程师必看）

最后总结几条实战中总结的避坑要点：

1. 不要在业务高峰期做 startup 路径切换
2. 改完路径立刻 save，不要拖
3. 大改动前先备份当前 startup.cfg 到 TFTP/FTP
4. 堆叠/集群场景下，配置管理以主设备为准
5. 定期检查 display startup 输出，和工单系统留档对得上
6. 遇到配置丢失先 diff，别急着 save，否则可能把错误固化
7. 怀疑文件系统异常时，可用 fixdisk flash:/ 修复，但操作前务必确认风险
8. 怀疑配置文件损坏时，可用 disassemble 检查完整性
9. 改文件前先用 TFTP/SFTP 把当前配置备份到本地
10. 执行 save force 前先核对设备时间，避免时间戳混乱
11. CF 卡扩容后，记得重新指定启动路径
12. 升级 VRP 前，必做 backup