7.0 KiB
Round 5V-3 — SSH接管、原生备份完成，独立恢复仍待解阻
历史记录保持原状。后续 Round 5V-4 已另获新建隔离恢复容器授权，实际恢复、005演练/回滚及源QA迁移均已完成； 当前结论见 Round 5V-4 软件验收，下文的“尚未恢复/未迁移”仅指当时状态。
日期：2026-10-14；工作分支 fix/iot-safety-hardening；开始提交
b94ac7f05aef80e092fddcf3d6ff3ac0a1a890b3。本轮没有重新运行H2或源码安全审计。
凭据仅用于SSH认证输入，未写入工程、命令行参数、报告或凭据文件。
1. 实际服务器和共机边界
- 实际登录
root@192.168.139.218:22，hostname为localhost.localdomain， NFSChina Server4.0，Linux4.19.113-72.nfs4.x86_64，UID0。 - 4321由docker-proxy映射至现有
kingbase容器54321。 镜像kingbase_v009r003c018b0003_single_x86:v1，现有容器用户kingbase。 - 同机GitLab、MySQL、MongoDB及其他应用持续运行。Kingbase和GitLab的启动时间 均保持2026-10-06，未重启、改配置、改端口、改防火墙或安装软件。
- 根分区约余535–536GiB；可用内存约372000MiB；备份前load约0.56/0.66/0.71。 原生备份单进程、低压缩等级1，无并发dump，无新容器或数据库。
2. Kingbase及权限实际核验
- 工具目录：容器
/home/kingbase/install/kingbase/bin/。sys_dump --version、sys_restore --version、ksql --version均为V009R003C018。 - 数据目录：容器
/home/kingbase/userdata/data；宿主机bind源/opt/kingbase-docker/data，配置文件为数据目录内kingbase.conf。 - 使用现有OS用户kingbase的容器本地连接，实际数据库角色kingbase、rolsuper=true。 没有新建管理账号或给fusion_qa_app授予额外权限；没有复用SSH口令猜测数据库口令。
- 数据库显式限定
railwaysystem_fusion_qa_20261013，数据库大小23005379字节。 App账号只读核验也成功：public54表、iotlocks9表；学员47、参训57、住宿34、 授权10、命令15。5S执行元数据仍缺失，005没有执行。 - 宿主机root和容器kingbase用户crontab未发现sys_dump/sys_rman相关条目； 这不等于已排除外部备份平台或其他调度策略，不能宣称原先存在可靠恢复保障。
3. 已完成的原生一致性备份（不是恢复演练）
主备份：
- 服务器目录：
/opt/railway-fusion-qa-backup-20261014.YLjmJ0/ - 本机独立副本：
/Users/wzb/railway-fusion-qa-backup-20261014.6cgPn7/ - 主文件：
fusion-qa-pre005-v2.dump，380907字节。 - SHA256：
caa62bc985bd433b5d428b36e34d684b557c82576b69e5e5d9d348edfdf316b4。 - 两端目录0700、备份及清单文件0600，均在Git工作树外。备份含敏感业务数据， 不提交、不打印、不上传公共服务；保留原始备份和清单，不自动清理。
实际过程：
- 在目标QA库开启
REPEATABLE READ READ ONLY事务，设置会话局部5分钟空闲事务、 30秒语句及5秒锁超时，导出快照；事务在备份及清单完成前保持有效。 - 匹配版本sys_dump使用custom格式、压缩等级1、5秒锁等待和同一个导出快照，
显式
-d railwaysystem_fusion_qa_20261013。未使用--create/--clean，未导出其他库。 - 原生sys_restore读取TOC，并用
--exit-on-error --file=/dev/null完整解码归档。 两步exit0；dump、TOC读取、完整读取的stderr均0字节。 - 清单来自相同快照：63张表均有唯一schema-qualified名称及行数，归档含63个TABLE 和63个TABLE DATA对象。授权/命令的整表排序指纹与备份前、备份后保持一致。
- 同步到本机独立副本后SHA256一致。源只读快照事务均显式ROLLBACK并退出， 最终没有本任务遗留的idle-in-transaction连接。
辅助证据文件：archive-toc-v2.list、source-table-counts-v2.tsv；服务器另保留
dump-v2.stderr、toc-v2.stderr、archive-read-v2.stderr（均空）。
首次草稿的清单使用||拼接，在当前SQL兼容模式下生成了错误的布尔标签；已经
改用concat，并重新做整套同快照备份/清单。主证据明确采用v2，初稿保留但不用于
表名对账。这个普通SQL兼容问题未通过提权或修改数据库模式解决。
归档读取通过仅证明文件可读取，不是把数据真正恢复到独立Kingbase的证明。
4. 当前独立恢复门禁
- 运行中及停止容器清单只发现一个Kingbase V9容器，即正在承载共享业务的实例。 同实例的旧QA/备份数据库不是独立恢复实例，未连接它们执行业务查询或恢复。
- 宿主机存在
/opt/Kingbase/ES/V8/data旧目录；未确认其为可用、获准且兼容的 V9恢复环境，因此没有启动它、覆盖它或把它当作恢复证明。 - 本机Docker守护进程不可用；已有SSH别名wzbmatebook的主机MateBook14上， PATH未找到Kingbase/Docker工具，未报告Kingbase/Postgres进程或所检查安装根。 没有尝试在该主机安装软件或初始化实例。
- 没有取得其他已存在且获准写入的独立V9恢复目标及其受保护连接配置。
ISOLATED_RESTORE_VERIFIED=BLOCKED，所以005迁移、DDL失败回滚演练、实际Kingbase 业务事务、新Spring Boot启动及完整Chrome E2E全部保持BLOCKED。
5. 最小解阻方案（需用户选择/批准，不自动执行）
优先方案：提供已有且获准操作的独立V009R003C018恢复实例、预建空恢复库及 受保护连接配置。先确认不属于共享源实例、没有业务对象及活动业务写入，再恢复 本备份并对照63表结构/计数和授权命令指纹，检查完整恢复日志。不要在聊天中发口令。
如无现成环境，可单独批准以下新增操作：在当前服务器使用已有同版本授权镜像，
创建一个仅用于恢复演练的独立容器/实例和专用恢复数据库。建议资源上限2CPU、
2GiB内存，至少5GiB独立存储；不发布宿主机端口，network none，仅docker exec
访问。数据卷绝不复用/opt/kingbase-docker/data。先核实许可允许该验证实例，
认证信息用受保护方式注入。创建实例、数据库和容器均超出当前授权，现在没有做。
验证后保留证据和环境，删除/销毁也需明确批准，不自动清理。
获得恢复目标授权后：原生恢复使用错误即停及单事务策略，不使用--create/--clean， 不覆盖源库。恢复目标角色/ACL映射需审核，不自动创建角色或扩大权限。恢复和 DDL回滚验证都通过后，才按005已批准范围对目标QA执行16列和4索引，随后连续 完成真实Service/Mapper事务、Java21启动与Chrome软件联动，不重做整个架构。
本轮实际完成：SSH接管、原生工具/容量/身份确认、一致性备份及双端保护校验。 本轮未完成：真正独立恢复、迁移、Kingbase业务恢复测试、后端及浏览器完整验收。 真实设备写入仍false；未连接真实MQTT控制或人脸服务，未Push/Merge/部署。