RouterOS 地址列表更新与 PVE 备份检查

RouterOS 的国内地址列表原来是下载第三方 RSC，清空旧列表，再导入执行。这次换了更新脚本，也检查了容器、供电和备份。

主体是10月16日的实施和备份检查。10月21日只读复核，mihomo内存仍为768MiB；DNS新增了独立的名单周更和后端watchdog，见下方补充。备份邮件、UPS接线和完整恢复没有新的完成证据，仍保留待办，不把旧检查当作今天重新验证。

国内地址列表的更新

RSC 是路由器脚本格式，直接导入会执行里面的命令。旧流程又先清空列表，后面的更新一旦失败，就可能留下空列表。

现在用固定解析器，只提取严格校验的 IPv4/CIDR 地址数据。格式、地址边界、数量、重复项，以及与当前列表的差异都会检查。下载内容不传给 import、:parse 或 :execute。

更新时用 CN 和 CN_ALT 两个槽。当前列表继续工作，在另一个槽里构建新列表；完整写好并通过检查后，再一次切换分流规则的引用。解析失败或候选只写了一部分，继续用原列表。

异常输入、部分写入和切换失败都先在独立测试里查过，再试人工更新和调度运行。10月16日几次成功更新后，读到的列表是8194条；数量和当前活动槽会随更新变化，不应固定要求永远是CN或8194条。网段是否确实属于国内，仍要依赖数据源，解析器只检查数据和更新过程。

两者不是同一份“国内名单”。DNS返回真实地址后，连接仍按原RouterOS和mihomo规则选路；更新DNS名单不会直接改出口节点。DNS的临时候选、后备接管和每120秒恢复检查，详见第七篇。

mihomo 容器的内存上限从 512 增到 768 MiB，在线生效，容器和代理进程都没重启。

旧 OpenWrt 留下的配置先查了依赖，归档了 11 个不用的对象。有些名字虽然旧，还被当前路由和健康检查引用，就继续保留。

10 月 16 日 14:59:35 最后一次普通业务检查时，核心虚拟机和容器都在运行，百度、Google、YouTube 的对应 HTTPS 请求和 TLS 校验通过，NAS Ping 为 3/3，PVE 两个物理口的错误和丢弃计数为零。

15:57:12 又只读核对了 NAS 容器清单。当天没有再跑双向满载，QoS 那篇的满载数据仍是 10 月 15 日测的。

两次 PVE 停止、启动的时间，与 UPS 转电池、恢复充电的记录高度对应。PVE 实际接在哪个插座、有没有受到 UPS 保护，还要沿供电线确认，具体哪个部件有问题尚未确定。

7 月发生过容器 OOM，但没有证据能把它和 10 月的宿主机重启联系起来。

10月16日的备份任务和NAS副本检查通过，Postfix里的通知邮件却仍积压。直连邮件服务时，初始SMTP握手失败，原因没查清，暂时不能判断是运营商封锁端口。这是当时确认的故障，10月21日没有重新清点邮件队列，也没有完成送达验收。

通知渠道还要处理，改完得实际确认能收到成功和失败的邮件。

副本哈希和压缩完整性查过，也离线提取了 RouterOS 磁盘和部分容器文件。还没有在隔离环境里启动恢复实例，数据库和应用恢复后能不能用，这次没测。

Docker应用主机也还没完成全量恢复验收。10月16日核验的凌晨备份不含当天下午全部修改；它更不能代表已经包含后来DNS双核心、watchdog及日志优化。恢复时先确认所选备份时间点，再按维护记录核对缺失增量，不机械照抄过期配置。