63 lines
2.7 KiB
Markdown
63 lines
2.7 KiB
Markdown
# 隔离恢复演练记录（2026-07-27）
|
||
|
||
## 结论
|
||
|
||
状态：**通过**
|
||
|
||
PostgreSQL 与 MinIO 已在独立 Docker Compose 项目中完成一致性备份、破坏和恢复。恢复后，
|
||
工单、附件元数据与对象内容均可读取，Django 系统检查通过。演练没有复用或修改现有开发
|
||
容器、网络和数据卷。
|
||
|
||
## 演练环境
|
||
|
||
- Docker Engine：29.6.1
|
||
- Docker Compose：5.3.0
|
||
- PostgreSQL：`pgvector/pgvector:pg16`
|
||
- MinIO：`minio/minio:latest`
|
||
- 归档辅助镜像：`alpine:3.21`
|
||
- 隔离 Compose 项目：`ai-ticket-restore-drill-5124`
|
||
- 备份编号：`20260727T092235Z`
|
||
- 总耗时：106.57 秒
|
||
|
||
## 执行步骤与证据
|
||
|
||
1. 启动独立 PostgreSQL 与 MinIO 数据卷，构建当前后端镜像。
|
||
2. 执行所有 Django 迁移与治理基线初始化。
|
||
3. 创建工单 `RESTORE-DRILL-001`、关联附件元数据和 MinIO 标记对象。
|
||
4. 生成 PostgreSQL custom-format dump、结构清单、MinIO 数据归档及 SHA-256 清单。
|
||
5. 删除演练工单与 MinIO 对象，确认进入破坏后状态。
|
||
6. 校验备份哈希，重建数据库并恢复对象存储数据。
|
||
7. 通过 Django ORM 验证工单及附件关系，通过 `mc cat` 验证对象内容。
|
||
8. 执行 `python manage.py check`，结果为 0 个问题。
|
||
9. 销毁本次演练的容器、网络、数据卷和临时后端镜像。
|
||
|
||
最终自动化结果：
|
||
|
||
```json
|
||
{
|
||
"status": "passed",
|
||
"backup_id": "20260727T092235Z",
|
||
"duration_seconds": 106.57,
|
||
"database_smoke": "ticket_and_attachment_restored",
|
||
"object_storage_smoke": "marker_restored",
|
||
"django_check": "passed"
|
||
}
|
||
```
|
||
|
||
## 演练中发现并修复的问题
|
||
|
||
- Windows PowerShell 缺少 `sh`，已增加与 Linux 脚本等价的备份、校验和恢复入口。
|
||
- Windows 原生命令参数可能改变多行脚本编码或引号，隔离演练改用无引号 UTF-8 字节表达式。
|
||
- 当前 MinIO 镜像不包含 `tar`，对象归档与恢复改由固定辅助容器挂载同一数据卷完成。
|
||
- 生产备份默认冻结当时正在运行的 backend、worker 与 beat，并在退出时恢复原运行集合，
|
||
避免 PostgreSQL 和 MinIO 分别快照期间继续发生跨存储写入。
|
||
- 对象卷归档和覆盖期间显式停止 MinIO，只有 MinIO 重新通过健康检查后才恢复业务服务，
|
||
避免从活跃数据卷读取或在运行进程下替换存储文件。
|
||
- Linux 恢复脚本增加跳过应用服务启停的隔离演练开关，避免演练误启动业务进程。
|
||
|
||
## 仍需生产执行
|
||
|
||
本记录证明当前代码和脚本能够恢复一致的数据库与对象数据，不替代生产环境的定期演练。
|
||
上线前仍需使用真实加密异地备份、正式告警接收方和业务账号执行完整登录、渠道、Agent
|
||
与附件下载冒烟，并记录生产 RTO/RPO。
|