数据库有效备份策略完整规划

套完备的备份策略核心目标：数据不丢失、可恢复、可验证、可落地、满足 RPO/RTO。

RPO：可接受最大数据丢失时间；RTO：故障后业务恢复耗时。所有备份动作都围绕这两个指标设计。

一、先明确业务约束（策略输入）

1. 业务 RPO/RTO

• 核心交易库：RPO≈0（尽量不丢数据），RTO 分钟级；需要全量 + 增量 + 日志归档

• 普通业务库：RPO 小时级，RTO 小时级；全量 + 增量即可

• 统计、离线库：RPO 天级，允许丢失部分当日数据，定时全量备份即可

2. 数据库类型差异

• MySQL：mysqldump、xtrabackup、binlog 二进制日志

• PostgreSQL：pg_dump、pg_basebackup + WAL 归档

• openGauss：gs_dump、gs_basebackup + WAL

• MongoDB：mongodump/mongobackup

• TiDB：br 备份工具

3. 约束条件

• 备份窗口：业务低峰，不能压垮数据库 CPU/IO

• 存储预算：备份文件占用空间、保留周期

• 合规要求：等保、数据安全法，备份异地留存要求

二、备份类型组合（不能只做单一备份）

✅最佳实践组合：全量备份 + 增量 / 差异备份 + 事务日志归档

❌只做 mysqldump 逻辑全量，不保存 binlog/WAL，一旦故障会丢失两次备份之间全部数据。

逻辑备份 vs 物理备份

1. 逻辑备份（dump 导出 SQL）

• 工具：mysqldump、pg_dump、gs_dump

• 优点：跨版本、跨平台，可单表恢复，便于迁移

• 缺点：大库慢，消耗数据库资源，不能做 PITR，只适合小库、结构迁移

2. 物理备份（数据文件快照）

• 工具：xtrabackup、pg_basebackup、gs_basebackup、TiDB BR

• 优点：速度快，适合 TB 级大库，配合日志实现时间点恢复

• 缺点：版本强绑定，不能单表细粒度恢复

生产建议：物理备份做主备份，逻辑 dump 作为辅助补充。

三、备份周期规划（示例）

示例 1：核心生产库（交易、支付类）

• 每周日凌晨：全量物理备份

• 周一～周六凌晨：增量备份

• 实时持续归档 binlog/WAL 事务日志，日志每 15min 切分，同步到备份存储

• 保留策略：

  • 全量备份保留 4 周；增量跟随对应全量；归档日志保留 30 天

• RPO：最多丢失 15 分钟数据；RTO：几十分钟级别

示例 2：普通业务库（后台管理）

• 每周 2 次全量备份；不开启实时日志归档，定时 binlog 每小时归档

• 备份保留 2 周

示例 3：测试 / 统计库

• 每日逻辑全量 dump，保留 7 天，不需要增量与日志

四、备份存储架构：3‑2‑1 备份原则（行业标准）

3 份数据副本，2 种不同介质，1 份异地存放

1. 3 份副本：原始数据库 + 本地备份 + 异地备份

2. 2 种介质：磁盘对象存储（MinIO/OSS）+ 离线磁盘（可选）

3. 1 份异地：不能和数据库同一机房，避免机房断电、火灾灾难全部丢失

⚠️禁止：备份文件和数据库实例放在同一块磁盘，磁盘损坏会业务 + 备份一起丢失。

存储选型：

• 本地：高速磁盘做临时备份中转

• 持久存储：对象存储 OSS/MinIO，支持生命周期自动清理过期备份

• 异地：跨机房同步备份文件（rsync、rclone、mc 工具）

五、备份自动化

1. 定时调度

• Linux：crontab；生产建议 systemd‑timer，避免 crontab 漏执行

• 大型环境：备份调度平台、定时脚本 + 告警

2. 备份后校验

• 备份文件完整性校验：md5sum /sha256sum，每次备份生成校验码

• 备份完成后发送告警：成功 / 失败通知钉钉 / 邮件，备份失败必须告警

很多事故：备份脚本静默失败，业务不知道，等到故障才发现备份全部损坏。

脚本关键流程伪代码：

plaintext

1.执行备份
2.判断备份返回码，非0直接告警退出
3.生成备份文件md5校验值
4.上传本地备份到对象存储/异地存储
5.清理本地过期备份
6.推送备份结果告警

六、最重要环节：备份恢复演练（绝大多数企业缺失）

没有经过恢复验证的备份等于没有备份

• 频率：至少每月做一次恢复演练

• 演练内容：

1. 将备份恢复到独立测试实例

2. 校验库表数量、业务数据行数

3. 测试时间点恢复 PITR，模拟故障丢失部分数据，恢复到故障前时间

4. 记录恢复耗时，核对实际 RTO 是否满足业务指标

• 禁止直接在生产实例做恢复测试，使用独立测试环境。

七、灾难恢复场景覆盖

1. 单表误删数据：利用逻辑备份 + 事务日志恢复单表

2. 实例损坏：物理全量 + 增量 + 日志 PITR 恢复整个实例

3. 机房整体故障：拉取异地备份，重建数据库

4. 勒索病毒：异地离线备份不被病毒加密，作为最后防线

八、常见踩坑点

1. 只做逻辑 dump，没有事务日志，两次备份中间的数据完全丢失

2. 备份和数据库同盘，磁盘损坏全部丢失

3. 备份脚本只看文件是否生成，不校验返回码，备份失败无告警

4. 备份只保存几天，无法回溯历史误操作（比如半个月前误删表）

5. 从不做恢复演练，备份文件损坏、版本不兼容，真正故障无法恢复

6. 备份任务放在业务高峰，造成数据库 IO 打满业务卡顿

九、输出一份可落地的备份策略文档模板

1. 数据库实例清单，每个实例 RPO/RTO

2. 备份工具选型（物理 / 逻辑）

3. 备份周期：全量、增量、日志归档频率

4. 存储位置、异地策略、备份文件保留周期

5. 告警机制：备份成功 / 失败通知渠道

6. 恢复演练计划：每月演练、演练步骤

7. 恢复操作手册：全量恢复、PITR 时间点恢复、单表恢复操作步骤

8. 责任人

本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。

原文链接 https://www.yijunzhao.cn/archives/database-effective-backup-strategy-planning-guide

欢迎访问 小易撩挨踢