前言

一般我们在数据库运维时，会采取周期性的物理全备，并在小时间间隔内物理增量备份。一般想着：每天增量备份成功了，应该没问题吧？事实是，增量备份文件恢复需要依赖对应的归档文件，但我们容易忽视归档日志的完整性。

1、案例描述

在项目例行检查中，发现归档目录里最近连续3天的归档日志文件不见了。我当时心里“咯噔”一下：这几天的增量备份还能用吗？赶紧去翻备份日志，结果发现这几天的增量备份全是“BACKUP SUCCESSFULLY”。我当时真的有点懵：归档都不完整了，备份怎么还能成功？我决定对备份文件还原，亲自验证一下。
我手动执行了一次增量备份，日志依然显示成功。然后把备份文件拷贝到测试环境，尝试恢复——果然，恢复到最后一步报错了，提示归档缺失。说明备份时提示成功，但恢复时问题就暴露出来了。

2、原因

后来我翻了翻达梦的技术资料，才慢慢搞明白其中的差异：归档链是否完整，备份过程不会主动检查。
1）备份的时候：工具只检查“当前时刻需要的归档日志”是否存在。只要执行备份那一刻需要的归档在，它就认为成功。
2）恢复的时候：需要从头到尾把归档日志全部应用一遍，中间缺一环都不行。
所以归档日志即使之前断过，只要备份时需要的还在，备份就能成功。但恢复时要从头开始，中间缺的就补不上了。

3、教训总结

这次经历让我后怕了很久——如果哪天真的需要恢复数据，才发现备份是坏的，那后果不敢想。所以在运维时，要定期的在测试环境做恢复演练。不需要恢复全部数据，只要能把备份集还原起来、启动实例、随便查几条数据，就能验证备份是否真的可用。步骤其实不复杂：

# 1. 还原数据文件
./dmrman RESTORE DATABASE '/dm8/test/dm.ini' FROM BACKUPSET '/backup/latest'
# 2. 恢复数据库
./dmrman RECOVER DATABASE '/dm8/test/dm.ini' FROM BACKUPSET '/backup/latest'
# 3. 更新DB_MAGIC
./dmrman RECOVER DATABASE '/dm8/test/dm.ini' UPDATE DB_MAGIC
# 4. 启动实例，随便查条数据
./dmserver /dm8/test/dm.ini

如果启动实例查数据正常，说明备份集是完整的。如果报错，能够尽快发现问题后排查故障解决，让在真正需要恢复的时候，心里有底。