备份基础:全量、增量与差异,以及策略设计

各位同学,今天咱们聊聊备份的“基本功”。说实话,我在金融行业摸爬滚打十几年,见过太多因为备份没做好而翻车的案例。有一次,某交易系统凌晨2点挂了,DBA发现上周的全量备份文件损坏,增量备份又因为日志链断裂无法恢复……嗯,那场面,真是“一地鸡毛”。

所以,这一章咱们把备份类型、策略设计、窗口与RPO这些核心概念彻底讲透。你想想看,如果连这些基础都不扎实,后面谈什么容灾?

1. 备份类型:全量、增量、差异

先问个问题:你平时备份数据库,是每次都把整个库拷一遍,还是只拷变化的部分?

答案取决于你的业务容忍度。我个人的习惯是:全量备份是“压舱石”,增量备份是“日常饭”,差异备份是“应急药”

1.1 全量备份

全量备份,说白了就是把整个数据库完整地复制一份。优点很明显:恢复时一步到位,不需要依赖其他备份文件。缺点也很要命:数据量大、耗时长、占用存储空间多。

我在项目中遇到过一家券商,每天凌晨做全量备份,结果备份窗口长达6小时,直接影响了白天的交易系统性能。后来我们改成了“每周全量+每日增量”,窗口压缩到了40分钟。

核心要点:全量备份适合低频执行(比如每周一次),用于构建恢复的“基准点”。

1.2 增量备份

增量备份只备份自上次备份(无论是全量还是增量)以来发生变化的数据。它的优点是快、小、省空间。但恢复时,你需要从最近一次全量开始,然后按顺序应用所有增量备份。

举个例子:假设周一全量,周二、周三、周四各做一次增量。周四恢复时,顺序是:周一全量 → 周二增量 → 周三增量 → 周四增量。一旦中间某个增量文件损坏,后面的数据就全丢了。

避坑指南:我曾经因为增量备份链断裂,导致某支付系统丢失了3小时交易数据。从那以后,我强制要求所有增量备份必须做“完整性校验”,并且定期做“增量合并”。

1.3 差异备份

差异备份和增量备份很像,但区别在于:差异备份备份的是自上次全量备份以来所有变化的数据。也就是说,每次差异备份都会越变越大,因为它包含了之前所有差异的内容。

恢复时,你只需要:全量备份 + 最后一次差异备份。简单吧?但代价是,差异备份文件会随着时间推移越来越大,备份窗口也会逐渐拉长。

备份类型 备份内容 恢复依赖 存储空间 恢复速度
全量 全部数据 最快
增量 自上次备份的变化 全量+所有增量 最慢
差异 自上次全量的变化 全量+最后一次差异 中等 中等

2. 备份策略设计:3-2-1原则

说到备份策略,金融圈有个铁律叫“3-2-1原则”。什么意思?

  • 3:至少保留3份数据副本(1份生产数据 + 2份备份)
  • 2:使用2种不同的存储介质(比如磁盘 + 磁带,或者本地 + 云)
  • 1:至少1份备份存放在异地(防止机房级灾难)

我个人习惯再加一条:定期做恢复演练。你想想看,备份文件放在那里,三年没碰过,真到恢复时发现文件损坏,那才叫欲哭无泪。

实战建议:我在某银行做架构时,要求每个季度做一次“全量恢复演练”,并且记录恢复时间。如果恢复时间超过RTO(恢复时间目标),就要调整备份策略。

下面这张图展示了3-2-1原则的典型架构:

3-2-1 备份策略架构图 生产数据库 备份副本1(本地磁盘) 备份副本2(磁带库) 备份副本3(异地机房) 介质1:SSD/NVMe 介质2:LTO磁带 介质3:云存储/远程 3份副本 | 2种介质 | 1份异地 满足金融监管要求,抵御单点故障与区域性灾难

3. 备份窗口与恢复点目标

这两个概念,我建议你刻在脑子里:

  • 备份窗口(Backup Window):允许执行备份操作的时间段。比如凌晨1点到5点,业务低峰期。
  • 恢复点目标(RPO):允许丢失多少数据。比如RPO=1小时,意味着最多丢失1小时的数据。

为什么要把它们放在一起讲?因为两者是“跷跷板”关系。你想想看,如果RPO要求是5分钟,那备份窗口就得非常短,甚至需要实时同步。如果RPO是24小时,那备份窗口可以拉长到几小时。

金融行业典型要求:
  • 核心交易系统:RPO ≤ 15分钟,备份窗口 ≤ 30分钟
  • 风控/清算系统:RPO ≤ 1小时,备份窗口 ≤ 2小时
  • 历史归档数据:RPO ≤ 24小时,备份窗口无严格限制

我在某支付公司遇到过一个问题:业务要求RPO=10分钟,但全量备份需要4小时。怎么办?我们采用了“全量+实时日志同步”的方案:全量备份每周一次,日志实时传输到备库,这样RPO可以控制在秒级,而备份窗口只占用每周一次的4小时。

注意:备份窗口不是越长越好。我曾经见过一个团队,把备份窗口设成8小时,结果白天业务高峰期还在跑备份,导致数据库响应慢了3倍。记住:备份窗口必须避开业务高峰,并且要预留缓冲时间。

4. 实战策略设计示例

说了这么多,咱们来一个具体的策略设计。假设你管理一个金融交易库,数据量2TB,每天增量变化约50GB。

# 备份策略配置示例(伪代码)
# 全量备份:每周日凌晨2:00
0 2 * * 0 /usr/bin/xtrabackup --backup --target-dir=/backup/full/$(date +%Y%m%d)

# 增量备份:周一至周六凌晨2:00
0 2 * * 1-6 /usr/bin/xtrabackup --backup --incremental-basedir=/backup/full/latest --target-dir=/backup/incr/$(date +%Y%m%d)

# 差异备份:每4小时一次(用于快速恢复)
0 */4 * * * /usr/bin/xtrabackup --backup --incremental-basedir=/backup/full/latest --target-dir=/backup/diff/$(date +%Y%m%d_%H)

# 备份验证:每天8:00检查备份完整性
0 8 * * * /usr/bin/xtrabackup --verify --target-dir=/backup/full/latest

这个策略的RPO是多少?增量备份每天一次,所以最多丢失24小时数据。如果你觉得不够,可以把增量改成每4小时一次,RPO就变成4小时。但代价是备份文件数量增加,恢复时应用更多增量。

我的习惯:对于金融核心系统,我通常采用“全量+实时归档日志”的组合。全量每周一次,归档日志每5分钟传输到备份服务器。这样RPO可以做到5分钟以内,而且恢复时只需要全量+最后一段归档日志,速度很快。

好了,这一章的内容就到这里。备份类型、3-2-1原则、窗口与RPO,这三个概念是后续所有容灾方案的基础。你想想看,如果连备份都做不好,容灾就是空中楼阁。


专注资料整理