备份压缩、并行度与 BCT 增量

一、问题的提出

备份恢复是数据库服务的最后一道防线，也是现场实施交付时必须跑通的环节。但在实际配置备份策略时，几个问题很少有人能直接给出有依据的答案。开启压缩后备份一定会变慢吗？并行度是不是拉满最好？压缩等级 LEVEL 1 和 LEVEL 3 的差距到底有多大？增量备份的 BCT 特性收益有多少？还有最关键的一个，备份命令执行成功，是否就等于这份备份真的能用来恢复？

二、实验环境与数据构造

表 1 实验环境

项目	配置
操作系统	Ubuntu 虚拟机，4 vCPU / 4GB 内存
数据库	DM8 V8.10.18.2 单实例，实例名 DM8EXP，端口 5235
实例状态	OPEN / NORMAL，归档模式开启
测试数据	PERF_DATA 表，表段约 31GB
表空间	TS_BAKTEST，4 个数据文件，初始 128MB，自动扩展步长 256MB，单文件上限约 9GB
存储	动态扩展 VMDK 虚拟磁盘

数据构造方式需要特别说明。PERF_DATA 表通过脚本分批插入，每批约 10 万行，PAYLOAD 字段使用 MD5 结果拼接填充，保证数据内容真实且可重复生成。为了避免用稀疏占位文件虚增体积，实验前通过数据字典确认表段实际占用约 31GB，数据库数据文件合计约 33GB。下图是实例状态、表段大小、数据文件和归档模式的真实查询输出。

图 1 实验环境与数据规模校验（PERF_DATA 表段 31GB，实例 OPEN，归档开启）

三、实验方法：让结论可以回溯

为了让数据有说服力，实验在方法上做了四项约束。

控制变量。完整备份固定在同一实例、同一存储路径上执行，只把压缩等级和并行度作为自变量，不同组交叉执行，减少缓存预热带来的偏差。

重复采样。完整备份设 6 组，每组重复 3 次共 18 次，传统增量和 BCT 增量各 3 次，统计时取组内中位数而不是最小值，避免单次抖动影响结论。

资源观测。备份期间用 vmstat 每秒采样一次，记录 CPU busy 和 I/O wait，耗时只说明现象，资源数据用来解释原因。

双重验收。每份备份集都通过 DMRMAN 的 SHOW BACKUPSET 和 CHECK BACKUPSET 校验，并实际执行还原，还原后检查实例状态、对象和关键 SQL。命令返回码为 0 且数据库可正常打开、查询通过，才算一次有效样本。

四、压缩会不会更慢

完整备份设三种压缩策略，分别是不压缩、COMPRESSED LEVEL 1、COMPRESSED LEVEL 3，每种策略在并行度 1 和 4 下各执行 3 次，取中位数汇总如下。

表 2 六组完整备份中位数（同一份 31GB 数据）

场景	中位耗时（秒）	备份集体积（GiB）
P1 不压缩	80.345	31.861
P4 不压缩	73.716	31.862
P1 LEVEL 1	46.992	0.646
P4 LEVEL 1	49.385	0.647
P1 LEVEL 3	49.406	0.644
P4 LEVEL 3	50.223	0.645

数据给出了一个和直觉相反的结果。在这套环境里，开启压缩后备份不但没有变慢，反而明显更快。以单并行度为例，不压缩中位耗时 80.345 秒，LEVEL 1 只要 46.992 秒，耗时下降约四成。原因是这份数据可压缩性极强，备份集从 31.86GiB 缩小到约 0.65GiB，体积降幅约 98%，压缩省下的磁盘写入时间超过了 CPU 压缩本身的开销。换句话说，这套环境的备份瓶颈在 I/O 而不在 CPU。

LEVEL 1 和 LEVEL 3 的对比同样值得记录。两者备份集体积分别是 0.646GiB 和 0.644GiB，LEVEL 3 只多省了不到 0.3% 的空间，耗时却还略高一点。对于这种高可压缩数据，LEVEL 3 投入更多 CPU 却几乎换不到额外收益，LEVEL 1 已经吃到了绝大部分压缩红利。

说明：

这个结论有明确的适用边界。它成立的前提是数据可压缩性强、I/O 是瓶颈、CPU 有余量。如果备份对象本身已是压缩格式，或者主机 CPU 长期打满，压缩的 CPU 开销可能反超 I/O 收益，结论会反转。任何参数都要在自己的环境里复测后再定。

五、并行度是不是越大越好

并行度的对比直接回答第二个问题。把表 2 中 P1 和 P4 的数据按压缩策略配对，再结合 vmstat 采样的资源均值一起看。

表 3 并行度 1 与 4 的耗时对比

场景	P1 中位耗时	P4 中位耗时	P4 相对 P1
不压缩	80.345s	73.716s	快约 8.3%
LEVEL 1	46.992s	49.385s	慢约 5.1%
LEVEL 3	49.406s	50.223s	慢约 1.7%

表 4 备份期间资源采样均值（vmstat）

代表组	CPU busy（%）	I/O wait（%）
P1 不压缩	52.4	6.1
P4 不压缩	73.8	18.3
P1 LEVEL 1	86.2	0.8
P4 LEVEL 1	90.2	0.0
P1 LEVEL 3	87.2	0.7
P4 LEVEL 3	90.3	0.0

两组数据放在一起，规律很清楚。不压缩时 CPU 只有 52% 左右的占用，存在余量，4 个并行通道把 I/O 调度起来后快了约 8.3%。开启压缩后 CPU busy 已经接近 90%，此时再把并行度从 1 提到 4，新增的压缩任务只能争抢已经紧张的 CPU，调度竞争抵消了并行收益，耗时反而回退。压缩组的 I/O wait 几乎为零也从侧面印证，此时系统已经不是 I/O 受限，加并行通道没有意义。

因此并行度没有通用最优值，正确做法是从 P1、P2、P4 逐步测试，同时观察 CPU busy、I/O wait 和备份耗时三条曲线。CPU 有余量、I/O wait 偏高时加并行才有收益，CPU 已经打满时加并行只会更慢。

六、BCT 增量备份的真实收益

BCT 全称 Block Change Tracking，即块变化跟踪。在 dm.ini 中设置 ENABLE_BCT=1 后，数据库会维护变化块位图文件，增量备份时不再扫描整个数据库判断哪些块发生变化，而是直接通过位图定位变化块，只读取这部分数据。它的价值在频繁增量的场景下才体现得出来。

实验在完整基线备份之后制造数据变更，分别用传统增量和 BCT 增量各执行 3 次。传统增量中位耗时 34.987 秒，BCT 增量中位耗时 6.986 秒，提速约 5 倍，耗时缩短约 80%。下图是参数生效、位图文件生成、备份集类型识别以及两组原始耗时的真实输出，SHOW BACKUPSET 明确显示 legacy incremental 为 FALSE、BCT incremental 为 TRUE。

图 2 BCT 启用与命中实证（ENABLE_BCT=1，位图文件生成，BCT incremental=TRUE）

表 5 传统增量与 BCT 增量对照（两组变更量相差约 10%）

模式	三次耗时（秒）	中位耗时（秒）	备份集体积
传统增量	35.548 / 34.267 / 34.987	34.987	约 29.4 MiB
BCT 增量	8.171 / 6.986 / 6.884	6.986	约 34.4 MiB

这里有两个容易误解的点。第一，BCT 优化的是扫描范围而不是备份集体积，表 5 中 BCT 备份集反而略大，一方面两组实验的变更量相差约 10%，另一方面位图本身也有开销，对比结论应以数量级差异为准，不纠结这几 MiB。第二，启用 BCT 后要确认参数真正生效、位图文件正常生成，并重新建立一次完整备份作为 BCT 增量的基线，否则增量仍然可能走传统路径。生产环境还应定期检查位图状态。

七、备份成功不等于可以恢复

整个实验中最重要的部分是还原验证。备份集只有在能成功恢复数据库时才有价值，命令返回成功只是第一步。DM8 的完整恢复链路包含备份集校验、还原、恢复、更新数据库魔数、启动实例和业务校验几个环节。

代码 1 备份集校验与恢复的关键命令

\-- DMRMAN 中校验备份集

CHECK BACKUPSET '/home/dmdba/dm8exp/backup/full\_p1\_c1';

\-- 还原与恢复（DMRMAN）

RESTORE DATABASE '/home/dmdba/dm8exp/data/DM8EXP/dm.ini' FROM BACKUPSET '...';

RECOVER DATABASE '/home/dmdba/dm8exp/data/DM8EXP/dm.ini' FROM BACKUPSET '...';

RECOVER DATABASE '/home/dmdba/dm8exp/data/DM8EXP/dm.ini' UPDATE DB\_MAGIC;

实验设计了三条还原路径，分别是不压缩备份集配合预分配数据文件、压缩备份集配合预分配、压缩备份集配合数据文件边扩展，三条路径全部恢复成功，返回码均为 0。

表 6 三条还原路径对照

还原路径	耗时（秒）	结果
不压缩 + 预分配	74.036	成功
压缩 + 预分配	62.317	成功
压缩 + 边扩展	60.251	成功

每次还原完成后都执行了相同的验收动作，确认实例状态为 OPEN、PERF_DATA 表段约 31GB、4 个数据文件齐全，并执行查询验证数据可用。下图是还原结果 CSV 和还原后校验的真实记录，可以看到三条路径的 exit_code 均为 0。

图 3 还原后校验（三条路径返回码均为 0，实例 OPEN，表段与数据文件齐全）

据此可以给出备份验收的明确标准，即返回码为 0、实例能够 OPEN、业务对象存在、关键 SQL 可以执行，四个条件同时满足才算通过。重要数据库必须按计划做实际恢复演练，只验证备份不验证恢复，等于没有验证。

八、写在最后

这轮实验跑完，我没有打算把任何一组参数当成标准答案。真正留下来的是一套可以复现的选型方法。

第一，用数据说话。压缩会不会变慢、并行度开多少，这类问题凭经验很容易答错，一次有控制变量和重复采样的实验比十次讨论更有效。

第二，参数没有脱离场景的最优值。同一台机器上，I/O 受限时压缩和并行都是加速手段，CPU 受限时它们反而成为负担，先判断瓶颈再选参数。

第三，恢复演练比备份成功更重要。备份交付给客户的东西表面上是一个备份集文件，真正要交付的是一份可恢复的确定性，CHECK、RESTORE、RECOVER、UPDATE DB_MAGIC 到业务校验的完整链路必须实际跑通。

以上实验数据来自笔者培训环境的真实记录，规模有限，vmstat 采样用于说明趋势方向，不能替代生产环境的正式压测。也欢迎大家在自己的环境里复测，用自己的数据修正这份清单。