Running 配置与 Startup 配置：应该备份哪一个？
理解活动状态、启动状态、NETCONF 数据存储能力，以及为什么一条通用备份规则无法适配所有设备。
直接回答
备份能够回答恢复与审计问题的每个配置权威。在区分二者的平台上，running 配置代表当前活动状态，startup 配置代表重启后预期加载的状态；应同时采集并比较漂移。NETCONF 总是定义 running 数据存储，而 startup 与 candidate 取决于设备声明的能力，因此必须核验实际设备，不能假设所有平台都像 Cisco IOS。
适用场景
- 发现已经生效但尚未保存到下次启动的变化。
- 准备与设备真实启动行为一致的恢复记录。
- 把 CLI 配置名称映射到 NETCONF 数据存储，同时避免错误的跨厂商等价。
分步骤复核
确认平台模型
确认设备是否暴露不同的 running、startup、candidate、控制器或云端配置权威。
读取声明能力
对于 NETCONF，根据服务端 capability 列表判断 startup 或 candidate 数据存储是否存在。
设定必需范围策略
明确完整备份必须成功的权威范围，而不是静默接受任何返回数据的命令。
分别采集各范围
为每个权威单独保存来源、时间、完整性与证据，避免其中一个覆盖另一个的含义。
有方向地比较漂移
当平台区分活动与启动状态时，复核 running 到 startup 的差异，并保留比较方向。
这里的网络配置机制
Cisco 文档定义明确保存步骤
在 IOS XE 上，把 running 配置复制到 startup 配置可用于后续初始化；这是平台特定证据，不是通用规则。
NETCONF 通过 capability 声明数据存储
RFC 6241 规定 running 为必需，而 startup 或 candidate 通过 capability 提供，让客户端发现而不是猜测。
受管无线还有另一配置权威
AP 可能从控制器或云服务继承配置，因此本地设备视图未必包含完整期望状态。
不同配置权威不能互换
| 权威范围 | 典型含义 | 需要核验 |
|---|---|---|
| Running | 设备当前生效的配置 | 返回范围对该角色是否完整且权威 |
| Startup | 重启初始化时预期使用的配置 | 是否存在独立 startup 存储以及如何写入 |
| Candidate | 提交前的候选配置 | 是否声明 NETCONF candidate capability |
| 控制器或云端 | 受管基础设施的期望状态 | 相关设置由该权威还是受管设备拥有 |
风险与不应执行的操作
不要假设 startup 存储一定存在
要求或报告该范围前，应检查平台文档与声明 capability。
不要合并权威标签
Running 到 startup 的差异有方向和运维含义，把两者都叫“配置”会丢失这些信息。
不要下发保存操作
ConfigVault 当前产品范围是只读；保存或提交配置仍由操作员在工具之外完成。
Omuuz 产品能做什么、不能做什么
能够做到
当经过验证的 Profile 支持时，ConfigVault 可以分别采集配置权威、记录完整性，并比较 running 与 startup 漂移。
不能做到
它不能让所有厂商暴露相同数据存储，也不会保存、提交或下发尚未保存的 running 配置。
产品证据
