Skip to content

[1.5.2 Patch][P1] MySQL 备份记录持久化:增加 backup manifest 与完整性校验 #78

Description

@weidonglang

背景

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": "..."
}

修复要求

  1. Data 备份完成后写入 manifest 文件。
  2. manifest 存放在 DevEnv Manager config 或 logs 的 MySQL backup records 目录。
  3. 高危修复前读取并校验近 24 小时内备份 manifest。
  4. 校验目标目录仍存在、文件数和大小大致匹配。
  5. manifest 损坏或备份目录不存在时拒绝修复。
  6. UI 显示最近备份时间、目录、文件数、大小、关键文件状态。
  7. 不保存数据库密码,不读取业务表内容。

#67 / #74 的关系

测试要求

  • 备份完成后生成 manifest。
  • 重启软件后仍能读取 manifest。
  • manifest 过期后拒绝用于系统库修复。
  • 备份目录被删除后拒绝修复。
  • manifest 文件损坏后拒绝修复。
  • 修复前能展示备份摘要。
  • 不保存敏感凭据。

验收标准

  • MySQL 高危修复不再只依赖内存备份记录。
  • 备份可审计、可回查、可验证。
  • cargo test --all-targets 通过。
  • npm run build 通过。
  • docs/release-v1.5.2.md 记录该修复。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions