如何安全备份路由器和交换机配置
采集权威的 running 或 startup 范围，验证完整性，并在加密历史中保留原始证据。
直接回答
可靠的网络设备备份不只是保存命令输出。先确认具体设备与配置权威，再使用固定的只读 SSH CLI 或 NETCONF 计划，验证请求范围是否完整，最后把配置及其采集证据作为同一份快照加密保存。ConfigVault 不会把部分采集当成干净基线。
适用场景
- 在计划网络变更前保留可追溯的配置证据。
- 按计划采集路由器、交换机、无线控制器或受管 AP 域。
- 区分权威的在线采集与手动导入的文本文件。
分步骤复核
定义配置权威
选择目标平台真实存在的 running、startup、candidate、控制器策略或其他明确范围。
选择精确 Profile
把设备绑定到网络 OS 家族、角色、采集方式、部署模式与管理平面，而不是只选择厂商 Logo。
核验端点身份
通过另一条可信渠道比对 SSH 主机密钥指纹后再固定；只扫描密钥本身不能建立信任。
执行有界只读计划
使用固定 SSH CLI 或 NETCONF 操作采集身份事实与配置，并限制输出范围。
建立基线前检查完整性
在接受加密快照前，复核提示符返回、字节与行数、请求范围、解析覆盖、警告和缺失证据。
这里的网络配置机制
Running 与 startup 是两个问题
有些平台分别保存活动配置与启动配置；完整策略需要明确必须采集哪些范围。
采集证据与快照一起保存
采集方式、命令、设备指纹、输出边界、完整性、解析器版本和限制，让备份日后可以复核。
有计划任务不等于成功
认证、权限、网络可达性、分页、提示符与固件行为仍可能让定时采集不完整。
ConfigVault 的备份数据从哪里来
| 来源 | 能够证明什么 | 重要边界 |
|---|---|---|
| SSH CLI | 设备事实与明确配置命令的输出 | 只对具体命令、范围和完整会话成立 |
| NETCONF | 设备返回的指定数据存储或子树 | 在设备特定模型验证前只做 opaque 结构解释 |
| 手动导入 | 操作员提供的文本 | 无法证明端点身份、采集方式、时效或采集完整性 |
| REST | ConfigVault 当前没有内置 Profile 暴露该方式 | 库级 Runner 不等于经过验证的设备支持声明 |
风险与不应执行的操作
不要使用无限制管理员凭据
创建能够读取所需事实与配置范围的最小权限只读账号。
不要自动信任首次看到的密钥
在接受为设备身份前，通过带外渠道核对指纹。
不要把导入文件标成在线采集
导入文本可以作为证据，但没有在线采集方式与完整性证明。
Omuuz 产品能做什么、不能做什么
能够做到
ConfigVault 可以执行固定的只读 SSH CLI 或 NETCONF 计划、记录采集证据，并加密保存通过检查的快照。
不能做到
它不能根据厂商名称保证支持，不能证明未经核验的主机密钥，不能读取账号无权访问的范围，也不会下发配置。
产品证据
