背景
MySQL 修复中心已经要求在系统库修复前必须先完成 Data 备份。但当前备份 receipt 如果只保存在进程内存中,重启软件后会丢失,且无法形成可审计的备份清单。
这会造成两个问题:
- 用户刚完成备份,重启软件后系统不再识别该备份。
- 软件无法长期证明某次修复前确实完成了备份。
风险
- 高危修复的可审计性不足。
- 备份目录被移动或损坏时,软件不能及时发现。
- 用户体验混乱:明明备份过,但重启后仍提示没有备份。
修复目标
MySQL 备份完成后生成持久化 manifest,并在执行高危修复前验证 manifest 和备份目录完整性。
manifest 建议字段
{
"backupId": "mysql-backup-...",
"createdAt": "...",
"datadir": "...",
"destination": "...",
"files": 1234,
"bytes": 123456789,
"ibdata1Exists": true,
"frmExists": true,
"businessSchemaDetected": true,
"businessSchemaCount": 3,
"systemSchemaDetected": true,
"sourceFingerprint": "...",
"manifestHash": "..."
}
修复要求
- Data 备份完成后写入 manifest 文件。
- manifest 存放在 DevEnv Manager config 或 logs 的 MySQL backup records 目录。
- 高危修复前读取并校验近 24 小时内备份 manifest。
- 校验目标目录仍存在、文件数和大小大致匹配。
- manifest 损坏或备份目录不存在时拒绝修复。
- UI 显示最近备份时间、目录、文件数、大小、关键文件状态。
- 不保存数据库密码,不读取业务表内容。
测试要求
- 备份完成后生成 manifest。
- 重启软件后仍能读取 manifest。
- manifest 过期后拒绝用于系统库修复。
- 备份目录被删除后拒绝修复。
- manifest 文件损坏后拒绝修复。
- 修复前能展示备份摘要。
- 不保存敏感凭据。
验收标准
- MySQL 高危修复不再只依赖内存备份记录。
- 备份可审计、可回查、可验证。
cargo test --all-targets 通过。
npm run build 通过。
docs/release-v1.5.2.md 记录该修复。
背景
MySQL 修复中心已经要求在系统库修复前必须先完成 Data 备份。但当前备份 receipt 如果只保存在进程内存中,重启软件后会丢失,且无法形成可审计的备份清单。
这会造成两个问题:
风险
修复目标
MySQL 备份完成后生成持久化 manifest,并在执行高危修复前验证 manifest 和备份目录完整性。
manifest 建议字段
{ "backupId": "mysql-backup-...", "createdAt": "...", "datadir": "...", "destination": "...", "files": 1234, "bytes": 123456789, "ibdata1Exists": true, "frmExists": true, "businessSchemaDetected": true, "businessSchemaCount": 3, "systemSchemaDetected": true, "sourceFingerprint": "...", "manifestHash": "..." }修复要求
与 #67 / #74 的关系
测试要求
验收标准
cargo test --all-targets通过。npm run build通过。docs/release-v1.5.2.md记录该修复。