这项整改解决什么
备份策略整改的目标不是「有备份」，而是「能恢复且恢复得了」。推荐按 3-2-1 原则组织：至少 3 份副本、2 种不同介质、1 份放在异地。数据库备份要有校验值，文件同步要检查执行日志，恢复测试要定期做。这样即使遇到勒索软件、误删或硬件故障，都还有可用的退路。
数据库与文件备份示例
数据库与文件备份示例
# 逻辑备份并生成校验值（MySQL 示例）
mysqldump --single-transaction --routines --triggers app | gzip > /backup/db/app-$(date +%F).sql.gz
sha256sum /backup/db/app-$(date +%F).sql.gz > /backup/db/app-$(date +%F).sha256
# 同步到独立备份主机
rsync -a --delete /backup/ backup@10.9.0.20:/data/backup/app/
# 备份任务失败要触发告警，而不是静默失败保留与校验策略
保留与校验策略
# 保留组合（示例，按数据重要性调整）
本地：7 天日备份 + 4 周周备份 + 12 月月备份
异地：每日增量同步 + 每周全量同步
校验：每月随机抽取一份备份做恢复测试
台账：记录备份时间、大小、校验值、恢复测试结果基本信息
| 设计原则 | 3-2-1：3 份副本、2 种介质、1 份异地 |
|---|---|
| 备份类型 | 全量加增量，按恢复点目标确定频度 |
| 存储要求 | 独立备份存储，不与生产同主机、同存储 |
| 校验方式 | 校验值比对加定期恢复测试 |
| 权限要求 | 备份账号与业务账号分离 |
执行清单
- 明确重要数据范围：数据库、配置、代码、关键文档与日志
- 定义恢复点目标与恢复时间目标，据此确定备份频度与方式
- 备份任务加失败告警，避免长期静默失败
- 备份文件加密存放，密钥单独管理
- 定期做恢复测试并更新恢复手册
典型使用场景
- 测评整改：以完整的备份策略与恢复测试记录补齐条款证据
- 勒索软件防护：离线副本是最后一道防线
- 重大变更前：升级或迁移前强制做一次全量备份并验证
- 上云后数据保护：云备份仍需确认保留期与恢复流程
备份脚本要有日志：记录开始与结束时间、文件大小、校验值，一旦某天的备份文件明显偏小，通常意味着备份不完整。
备份文件不加密且权限过宽，等于把全量数据放到了没有门禁的抽屉里；备份存储的账号权限要与生产分离。