railwaysystem/docs/iot/ROUND5V3_SERVER_BACKUP.md

# Round 5V-3 — SSH接管、原生备份完成，独立恢复仍待解阻

历史记录保持原状。后续 Round 5V-4 已另获新建隔离恢复容器授权，实际恢复、005演练/回滚及源QA迁移均已完成；
当前结论见 [Round 5V-4 软件验收](ROUND5V4_SOFTWARE_QA.md)，下文的“尚未恢复/未迁移”仅指当时状态。

日期：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工作树外。备份含敏感业务数据，
  不提交、不打印、不上传公共服务；保留原始备份和清单，不自动清理。

实际过程：

1. 在目标QA库开启`REPEATABLE READ READ ONLY`事务，设置会话局部5分钟空闲事务、
   30秒语句及5秒锁超时，导出快照；事务在备份及清单完成前保持有效。
2. 匹配版本sys_dump使用custom格式、压缩等级1、5秒锁等待和**同一个导出快照**，
   显式`-d railwaysystem_fusion_qa_20261013`。未使用--create/--clean，未导出其他库。
3. 原生sys_restore读取TOC，并用`--exit-on-error --file=/dev/null`完整解码归档。
   两步exit0；dump、TOC读取、完整读取的stderr均0字节。
4. 清单来自相同快照：63张表均有唯一schema-qualified名称及行数，归档含63个TABLE
   和63个TABLE DATA对象。授权/命令的整表排序指纹与备份前、备份后保持一致。
5. 同步到本机独立副本后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/部署。