4. 备份体系与恢复可用性评估

在生产库的应急恢复中,真正决定"能恢复到哪一刻"的,不是某一次备份是否成功,而是整条备份链是否完整、连续、可验证。SQL Server 提供了完整备份、差异备份、事务日志备份、文件与文件组备份四类手段,它们各自解决不同粒度的问题,组合起来才构成可用的恢复体系。本章围绕"备份类型—备份链—恢复点选择—验证"这条主线展开,帮助你在故障发生时快速判断:我手上这套备份,到底能恢复到什么程度。

四类备份的定位与适用场景

完整备份(Full Backup)是备份链的起点,它包含备份完成时刻数据库的全部数据页以及足够的日志,使数据库能够独立还原到一个一致状态。完整备份是差异备份和日志备份的基础,没有完整备份,后续备份都无法单独还原。它的代价是体积大、耗时长,因此通常按天或按周执行。

差异备份(Differential Backup)只记录自最近一次完整备份以来发生变化的区(extent)。它依赖完整备份作为"基准",体积和耗时都远小于完整备份,适合在两次完整备份之间增加恢复点密度。注意:差异备份的基准是"最近一次完整备份",而不是上一次差异备份,因此差异备份会随着时间推移逐渐变大。

事务日志备份(Transaction Log Backup)记录自上一次日志备份以来的所有日志记录,是实现"时间点恢复"的关键。它要求数据库处于完整恢复模式或大容量日志恢复模式。日志备份可以做到分钟级甚至更密的恢复点,是生产库降低 RPO 的核心手段。日志链一旦断裂(例如误切到简单恢复模式、日志备份长时间未执行导致日志被截断),时间点恢复能力就会丧失。

文件与文件组备份(File/Filegroup Backup)针对超大型数据库设计,允许只备份部分文件或文件组,配合日志备份实现分步还原。它适合数据量大、单次完整备份窗口不足的场景,但管理复杂度高,必须保证文件组与日志链的对应关系清晰。

备份链完整性:恢复可用性的真正基础

备份链可以理解为一条有向依赖链:完整备份 → 差异备份 → 日志备份序列。恢复时,SQL Server 要求这条链上的每个环节都能按顺序衔接。常见断裂点包括:

  • 完整备份之后直接还原差异备份,却缺少中间某次日志备份;
  • 日志备份序列中出现 LSN 断档,通常由恢复模式切换或日志截断引起;
  • 差异备份所依赖的完整备份已被删除或损坏;
  • 备份文件本身损坏,但从未做过还原验证。

因此,评估恢复可用性不能只看"备份任务是否成功",而要看"从某个完整备份出发,能否一路还原到目标时间点"。建议定期用 RESTORE HEADERONLY 和 RESTORE FILELISTONLY 检查备份集元数据,确认 LSN、备份类型、数据库名、恢复模式等关键字段连续一致。

备份链与恢复点选择示意 时间 → 完整备份 周一 02:00 差异备份 周三 02:00 日志1 周三 06:00 日志2 周三 10:00 日志3 周三 14:00 日志4 周三 18:00 故障点 18:20 恢复路径:完整 → 差异 → 日志1 → 日志2 → 日志3 → 日志4(STOPAT 18:20) 恢复点选择与验证要点 ① 确定目标时间点 RPO 决定日志备份频率 ② 检查链完整性 LSN 连续、无断档 ③ 还原验证 RESTORE VERIFYONLY 常见断裂:恢复模式切换 / 日志截断 / 完整备份被删 / 备份文件损坏 应对:定期做还原演练,保留完整备份至日志链末端之后

恢复点选择:从 RPO 反推备份策略

恢复点选择的核心问题是:业务能容忍丢失多少数据?这个容忍度就是 RPO(恢复点目标)。如果 RPO 是 15 分钟,那么日志备份间隔必须小于等于 15 分钟;如果 RPO 是 1 小时,日志备份可以每小时一次,但差异备份和完整备份的频率仍需保证恢复窗口可接受。

假设某生产库策略为:每周日 02:00 完整备份,每天 02:00 差异备份,每 4 小时日志备份。若故障发生在周三 18:20,恢复路径为:还原周日完整备份 → 还原周三差异备份 → 依次还原周三 06:00、10:00、14:00、18:00 的日志备份,并使用 STOPAT = '2025-01-08 18:20:00' 恢复到故障前一刻。此时最大数据丢失为 18:00 到 18:20 之间的 20 分钟,满足 15 分钟 RPO 吗?不满足,说明日志备份间隔需要缩短到 15 分钟以内。

这里有一个容易被忽略的细节:日志备份的恢复点精度受限于最后一次日志备份的时间。如果故障发生在 18:20,而最后一次日志备份是 18:00,那么 18:00 之后的日志仍在活动日志中,只有在数据库仍可访问时才能做尾日志备份(Tail-Log Backup)。如果数据库已损坏无法访问,就只能恢复到 18:00,丢失 20 分钟数据。因此,尾日志备份能力是评估恢复可用性时必须单独确认的一环。

备份验证:不要等到故障才发现备份不可用

备份成功不等于备份可还原。SQL Server 提供 RESTORE VERIFYONLY 做备份集完整性校验,但它只检查备份集头部和校验和,不验证数据页是否可还原。真正可靠的验证是定期在测试实例上执行完整还原演练,并运行 DBCC CHECKDB 确认数据一致性。

-- 校验备份文件完整性
RESTORE VERIFYONLY FROM DISK = 'D:\Backup\Sales_Full_20250105.bak';

-- 查看备份集元数据,确认 LSN 与类型
RESTORE HEADERONLY FROM DISK = 'D:\Backup\Sales_Full_20250105.bak';

-- 查看备份中的文件逻辑名,用于 WITH MOVE
RESTORE FILELISTONLY FROM DISK = 'D:\Backup\Sales_Full_20250105.bak';

建议把验证结果记录成一张可复查的清单,至少包含:备份类型、备份时间、LSN 起止、依赖的完整备份、验证方式、验证结果、验证人。这样在故障发生时,可以直接从清单中定位可用的恢复点,而不是临时翻找备份文件。

评估恢复可用性时,先问三个问题:最近一次完整备份是什么时候?从它出发的差异和日志链是否连续?最后一次日志备份之后是否还能做尾日志备份?这三个问题答清楚,恢复点就基本确定了。

文件与文件组备份的恢复可用性

文件与文件组备份的恢复逻辑与常规链不同:它允许只还原受损的文件组,再应用日志备份使该文件组与数据库其余部分保持一致。这种方式能显著缩短大库的恢复时间,但前提是文件组划分合理、日志链完整、且受损文件组与其它文件组的日志衔接正确。若文件组划分不当或日志链断裂,部分还原会失败,反而增加恢复复杂度。因此,采用文件组备份策略时,必须把"文件组—日志链—还原顺序"作为整体来验证。

综合来看,备份体系与恢复可用性评估不是一次性的配置工作,而是持续验证的过程。完整备份提供基准,差异备份压缩恢复窗口,日志备份决定 RPO 精度,文件组备份解决大库恢复效率,而备份链完整性和还原验证则决定这套体系在真实故障中是否真的可用。把这四类备份的依赖关系、恢复点计算方法和验证手段掌握清楚,才能在应急恢复时做到心中有数、手上有据。