5.3 备份与恢复策略

5.3 备份与恢复策略

本节摘要：备份是最后防线，没备份一切归零。本节讲清楚备份策略（全量/增量/PITR）、恢复流程、备份验证、性能考量，让备份可靠且不影响性能。

备份为什么重要

数据丢失场景：

• 误操作（DROP TABLE/DELETE 无 WHERE）。
• 硬件故障（磁盘损坏）。
• 软件故障（数据库崩溃、bug）。
• 灾难（机房故障、火灾）。
• 勒索/攻击。

没备份——数据永久丢失，业务可能倒闭。备份是保险——希望不用，但要有。

备份目标：

• RPO（恢复点目标）：可接受丢失多少数据（如 0 表示不丢，1 小时表示丢 1 小时内）。
• RTO（恢复时间目标）：可接受多长时间恢复（如 4 小时）。
• 按业务定 RPO/RTO，选备份策略。

备份类型

1. 全量备份（Full Backup）

• 完整备份所有数据。
• 恢复简单——直接还原。
• 耗时长、占空间大。
• 周期——如每周一次。

2. 增量备份（Incremental Backup）

• 备份上次备份后变化的数据。
• 快、省空间。
• 恢复复杂——需全量+所有增量依次还原。
• 周期——如每天一次。

3. 差异备份（Differential Backup）

• 备份上次全量后变化的数据。
• 介于全量和增量——比增量大比全量小。
• 恢复——全量+最近差异。
• 周期——如每天一次。

4. 日志备份（Binlog/WAL）

• 备份事务日志。
• 支持 PITR（Point-in-Time Recovery）——恢复到任意时间点。
• 高频——如每分钟/每 5 分钟。
• RPO 可接近 0。

MySQL 备份

mysqldump（逻辑备份）：

• 导出 SQL 语句。
• 优点：跨版本、可读、可选择性恢复。
• 缺点：慢、大表锁（--single-transaction InnoDB 一致性不锁）。
• 适合：中小库、迁移、特定表。

mysqlbackup/XtraBackup（物理备份）：

• 拷贝数据文件。
• XtraBackup（Percona，开源）：热备份 InnoDB，支持增量。
• MySQL Enterprise Backup：官方商业。
• 优点：快、支持增量、热备份。
• 缺点：跨版本差、不可读。
• 适合：大库、快速恢复。

Binlog 备份：

• 复制 binlog 到备份服务器。
• 支持 PITR。
• 定期轮转 + 备份。

备份策略：

• 每周全量 + 每天增量 + 持续 binlog。
• 或 XtraBackup 每周全量 + 每天增量 + binlog。

PostgreSQL 备份

pg_dump（逻辑备份）：

• 导出 SQL 或自定义格式。
• --format=custom 支持选择性恢复。
• 适合中小库。

pg_basebackup（物理备份）：

• 热物理备份（基于复制协议）。
• 支持全量+增量（PG 17 增量备份）。
• 适合大库、快速恢复、搭建备库。

WAL 归档：

• archive_mode=ON + archive_command 归档 WAL。
• 支持 PITR。
• 配合 pg_basebackup 全量 + WAL 归档。

备份策略：

• pg_basebackup 每周全量 + WAL 归档（PITR）。
• 或 pg_dump 定期全量。

恢复流程

1. 评估损失

• 什么丢失了（表/库/时间范围）。
• RPO/RTO 要求。
• 决定恢复策略（全量还原/PITR/特定表）。

2. 准备

• 停写（或切只读）——防止恢复期间新数据。
• 找备份——全量+增量+日志。
• 测试环境验证——避免生产直接恢复出错。

3. 执行恢复

• 还原全量备份。
• 应用增量备份（如有）。
• 应用日志到目标时间点（PITR）。
• 或导入逻辑备份（pg_dump/mysqldump）。

4. 验证

• 检查数据完整性——行数、关键表。
• 检查一致性——外键、约束。
• 测试应用——确认功能正常。

5. 恢复业务

• 开写。
• 监控——确认无异常。
• 复盘——改进备份策略。

备份验证与演练

验证：

• 备份能否恢复——定期测试恢复。
• 恢复时间——是否符合 RTO。
• 数据完整性——恢复后数据正确。

演练：

• 定期灾难演练——模拟故障恢复。
• 不同场景——误删表、库崩溃、机房故障。
• 记录流程——文档化，团队熟悉。

没验证的备份等于没备份——可能恢复失败或数据错。

备份性能考量

1. 备份时间窗口

• 低峰期备份——避免影响业务。
• 大库分片备份——并行。
• 增量备份——减少全量频率。

2. 备份对性能影响

• 物理备份读数据——IO 增加。
• 逻辑备份执行查询——CPU/IO。
• 限流——XtraBackup 有 throttle，pg_dump 限制并发。

3. 备份存储

• 压缩——省空间（XtraBackup/pg_dump 支持）。
• 异地——防机房故障（云存储/异地机房）。
• 保留策略——全量保留 N 份，增量保留 M 天。

4. 监控备份

• 备份成功/失败告警。
• 备份大小/耗时趋势——异常排查。
• 备份完整性校验——校验和。

⚠️ 常见误读：以为"备份了就安全"。没验证的备份可能恢复失败或数据错。要定期测试恢复 + 灾难演练，确认备份可用。

💡 关键直觉：备份是最后防线（误操作/硬件/软件/灾难/勒索），按 RPO（丢多少）/RTO（多久恢复）选策略。类型——全量（完整慢大，恢复简单）、增量（变化快省空间，恢复复杂全量+所有增量）、差异（全量后变化，恢复全量+最近差异）、日志（binlog/WAL 支持 PITR 任意时间点 RPO 接近 0）。MySQL（mysqldump 逻辑跨版本可读慢锁 --single-transaction、XtraBackup 物理热备增量快、binlog PITR）。PG（pg_dump 逻辑 custom 选择性、pg_basebackup 物理热备+增量 17、WAL 归档 archive_mode PITR）。恢复流程——评估损失→准备停写找备份测试环境→执行全量+增量+日志 PITR→验证完整性一致性→恢复业务监控复盘。验证演练——定期测试恢复（能否恢复/RTO/数据完整）、灾难演练（误删/崩溃/机房）、文档化。性能——低峰期备份、分片并行、增量减全量、限流 throttle、压缩异地、保留策略、监控成功失败/大小耗时/校验和。没验证的备份等于没备份。

本节要点回顾

• 备份重要性：数据丢失场景（误操作 DROP/DELETE、硬件故障、软件崩溃、灾难机房、勒索），没备份数据永久丢失业务可能倒闭。目标 RPO（可接受丢失多少，0 不丢/1 小时）RTO（多久恢复，4 小时），按业务定策略。
• 备份类型：全量（完整慢大恢复简单，每周）、增量（上次后变化快省空间恢复复杂全量+所有增量，每天）、差异（全量后变化恢复全量+最近差异，每天）、日志（binlog/WAL 支持 PITR 任意时间点 RPO 接近 0，每分钟/5 分钟）。
• MySQL 备份：mysqldump 逻辑（跨版本可读慢 --single-transaction InnoDB 一致性不锁，中小库迁移）、XtraBackup 物理（热备份 InnoDB 支持增量快，大库快速恢复）、binlog 备份（PITR）。策略：每周全量+每天增量+持续 binlog。
• PG 备份：pg_dump 逻辑（custom 格式选择性恢复，中小库）、pg_basebackup 物理（热备基于复制协议，17 增量，大库快速恢复搭建备库）、WAL 归档（archive_mode+archive_command，PITR）。策略：pg_basebackup 每周全量+WAL 归档 PITR。
• 恢复流程：评估损失（什么丢/RPO RTO/策略）→准备（停写防新数据/找备份全量+增量+日志/测试环境验证）→执行（还原全量+应用增量+应用日志 PITR/导入逻辑）→验证（行数/关键表/外键约束/应用功能）→恢复业务（开写/监控/复盘改进）。
• 验证演练：定期测试恢复（能否恢复/RTO 符合/数据完整）、灾难演练（误删表/库崩溃/机房故障不同场景）、文档化团队熟悉。没验证的备份等于没备份。
• 性能考量：低峰期备份（避免影响业务）、大库分片并行、增量减全量频率、限流（XtraBackup throttle/pg_dump 并发）、压缩省空间、异地防机房（云存储/异地）、保留策略（全量 N 份增量 M 天）、监控（成功失败告警/大小耗时趋势/校验和完整性）。

恢复演练的仪式与清单

备份策略的灵魂不在备份而在恢复，恢复演练要做成有仪式感的例行事件。演练的频率与层级：季度做一次文件级验证（备份集完整性、校验和、可挂载），半年做一次实例级恢复（在隔离环境完整拉起、跑数据校验查询），年度做一次全流程灾演（含切换应用、补齐增量、对账确认）。每次演练的固定清单：恢复用了多久（对照恢复时间目标）、过程中卡在哪一步（密码、路径、依赖服务的坑要当场记录）、恢复后的数据一致性怎么证明（关键表的行数与校验和比对）、演练产出的改进项归谁跟进。两个高频翻车点提前记住：其一，备份加密密钥没进备份体系——备份集完好但无人能解开，等于零备份；其二，全量有、增量缺——恢复点比预想的旧了好几天，恢复点目标的承诺破产。演练的意义用一句话说透：没演练过的备份是薛定谔的备份，打开灾难那天的盒子才知道里面是数据还是空气。

恢复目标的三方对齐

备份策略的最后一块拼图是恢复目标（时间点与时长）的三方对齐：业务方、DBA 团队、基础设施方。业务方给出的是需求语言："最多丢五分钟的数据、四小时内恢复服务"。DBA 团队翻译成技术语言：恢复点目标五分钟意味着近连续的日志归档（五分钟级），恢复时间目标四小时意味着全量加增量的恢复链路要演练验证过在这个时长内完成——翻译过程常暴露需求的错配（业务以为的"不丢数据"成本是全同步复制，性能代价不能接受），对齐会就是让代价显性化的谈判桌。基础设施方确认资源语言：备份存储的容量与保留期、恢复演练环境的资源配额、灾备链路的带宽——没有资源背书的恢复目标是空头支票。三方对齐的产出物是一页纸的"恢复承诺书"：什么场景丢多少、多久恢复、靠什么资源、谁负责验证——它同时是备份策略的验收标准与灾难时刻的行动地图。备份体系的成熟度，最终就体现在这页纸有没有、准不准、验没验过。

备份的经济学

备份章收官算一笔经济学账，帮团队在无限安全与有限预算间找点。成本侧：存储成本（全量加增量加异地三份的量）、备份窗口的计算与 IO 成本、恢复演练的人力。收益侧：按"数据资产价值乘以故障概率"估算——交易数据的丢失代价以业务停摆加赔偿计，日志类数据以合规罚款计。三个优化杠杆：增量与差异策略减少存储与窗口（全量周期拉长、增量链条控制深度）、重删压缩技术在备份存储上的应用（备份集的相似度极高，重删比常达五倍以上）、云对象存储做异地层（比自建异地机房便宜一个量级）。决策框架：恢复点与恢复时间目标每收紧一档，成本大约翻一档——业务方签字确认目标时应该同时看到价格，让他们为"更安全"付费或为省钱担责，而不是让 DBA 单方面猜。备份的经济学本质是保险的经济学：保额要足，但没人需要给一辆自行车上航天保险。

备份的日常三查

备份章收官给值班交接时的日常三查——一分钟版本的健康确认。一查昨晚：备份任务成功率与备份集大小（大小突降常意味着任务"成功"地备了个寂寞——比如备了空实例）、耗时是否在窗口内。二查链路：增量日志归档的连续性（断链意味着恢复点目标违约）、异地复制的延迟（灾备侧落后多少）。三查余量：备份存储的剩余空间按当前增长还能撑几天——备份集的增长是单边的（数据只增不减、保留期又在拉长），空间耗尽是备份体系最常见的"意外"。三查的哲学与全书一致：备份不是策略文档写完就安心的静态资产，是每天都要打卡的动态承诺——一分钟的打卡换灾难时刻的底气，这是全数据库领域性价比最高的一个习惯。