Incus 脚本审阅与验收 · 第 8 / 8 篇
一个可信的结尾，不是六张绿色截图，而是别人能根据记录复查：创建了什么、改了什么、坏过什么、如何恢复、还有什么没有验证。本系列的终点是一套交付标准，而不是给现有脚本盖一个超出证据的“完美”印章。
已完成与未完成的结果分开列
原始文件的 SHA-256、静态检查与离线复现程序随本系列归档。这样以后修改脚本时，可以明确比较的是哪一版，而不是反复使用一个叫“最终版”的文件名。
第一阶段，先让一台容器完成闭环
记录宿主 OS、内核、Incus 客户端与服务端版本、镜像指纹、存储驱动、网桥网段、出口接口和防火墙后端。在独立测试环境完成创建，然后分别验证实例状态、根盘配置、容器内 SSH、外部真实登录、出站软件源访问和一个应用服务。
公网 SSH 必须从宿主机以外的网络测试，并确认登录后确实是目标容器。本机端口处于 LISTEN，只能证明监听存在；一个成功的空 TCP 连接，也不能代替 SSH 鉴权和目标身份核对。
根盘验证同样分两步：结构化配置正确，再在可丢弃实例里验证实际写入边界和池余量。不要因为代码搜索到 size: 3GiB 就声称完成存储隔离测试。
第二阶段，证明操作只影响目标实例
给每个测试容器放置不同的标记文件，并部署不同的低风险测试服务。添加或删除 vps3 的业务端口前后，检查其余实例的设备、SSH 与服务响应。准备重装演练时，先给目标做一致性备份，记录设备与业务清单，再核对确认对象。
重装后，预期目标根盘标记消失、系统重新初始化；未选中的实例标记与业务保持不变。代理设备如果保留，还需要重新安装并启动目标业务，外部协议请求成功才是服务恢复。额外挂载卷应按事先写明的策略单独核验。
第三阶段，故障演练比重复成功更有价值
这些演练应在独立宿主机或明确可丢弃的实例进行，尤其不能为了模拟掉线而直接清空正式宿主机防火墙。演练使用的配置变更、恢复步骤与预期影响，都应事先写清。
备份恢复为什么还要防止端口争抢
把实例备份导入同一宿主机，可能带回原有 proxy 设备。即使换了实例名，监听端口仍可能与在线实例冲突。更稳妥的是在隔离测试宿主机或隔离项目中恢复，并在启动前检查监听设备和挂载卷；项目隔离也不能自动解决宿主机同地址同端口冲突。
实例导出不自动覆盖所有外部挂载卷、宿主路径与外部数据库；备份清单应明确哪些数据在包里、哪些另行保护。对数据库业务，要额外说明一致性方式，不能把一个运行中快照无条件称为应用一致性备份。
最后再扩到三台、六台
扩展时保留同样验收项，并增加并发更新、磁盘增长、空闲与峰值内存、业务延迟和持续运行观察。六个实例都设为一个 CPU 上限，不会使宿主机突然多出六个独占核；六份 3GiB 上限也不会把 12GiB 池变成 18GiB 可用空间。
测试报告至少记录时间、版本、负载、持续时长、观测方法和失败项。没有这些条件，单个“稳定运行”描述不能被下一位读者复现。
可以对外宣布完成的标准
当单实例闭环、非目标实例保护、重跑、重启、监控和备份恢复都通过，并且修复后的脚本与对应报告一一匹配时，才可以发布“这套指定环境已经完成验收”。它仍然不是对所有硬件、网络和未来版本的无限保证。
这批材料目前最诚实的结论是：部署与管理思路已形成，语法和部分离线逻辑已核对，发现了需要修复的幂等与比较问题，完整实机验收还缺证据。把问题讲明白、把验证路径交给读者，才是这个系列应当留下的结果。
参考：Incus 备份、export 命令、import 命令。具体参数以目标版本的 --help 为准。