Azure Recovery Services Vault备份SQL VM与手动SSMS备份的冲突及恢复咨询

1. 是否建议取消本地SSMS手动备份？ #

建议立即取消，原因如下：

• 你当前的SSMS维护计划备份会打断SQL日志链，直接导致Azure Recovery Services Vault的每小时日志备份报错，破坏了Azure备份的连续性，让原本的增量/日志备份失去意义。
• 你已经配置了Azure层面的两种备份策略：每日VM全量备份、每日SQL全量+每小时日志备份，已经覆盖了全量+增量的备份需求，重复的SSMS备份完全是冗余操作，还额外占用存储资源。

2. 当前状态下恢复数据库的流程及可能遇到的问题？ #

恢复流程 #

1. 先定位最近一次未被SSMS备份打断日志链的Azure SQL全量备份（也就是SSMS备份执行前的最后一次Azure全量备份）。
2. 恢复该全量备份，然后尝试应用该全量备份之后、日志链断裂前的所有每小时日志备份，恢复到日志链断裂前的最新时间点。
3. 如果需要恢复断裂后的数据，只能依赖断裂后执行的SSMS手动备份，但要注意这种备份是独立的，无法和Azure的备份链合并，只能单独恢复该备份文件。

可能遇到的问题 #

• 日志链断裂后，Azure的每小时日志备份从断裂点开始就失效了，无法用来恢复断裂后的最新数据，只能回退到断裂前的状态，会丢失断裂点到当前的部分数据（除非有SSMS备份可用）。
• 同时存在两种备份源（Azure备份+SSMS备份），恢复时需要手动区分不同备份的时间线，容易出现恢复错误，比如恢复了错误的备份版本导致数据不一致。
• 如果没有保留断裂前的完整日志链，可能连全量备份后的部分增量数据都无法恢复，只能恢复到全量备份的时间点。

能否使用每小时备份？ #

只有日志链断裂前的每小时备份可以正常使用，断裂后的每小时备份因为日志链被打断，已经无法和之前的全量备份形成完整的恢复链，完全没用。断裂后的恢复只能依赖SSMS手动备份，或者放弃断裂后的数据，恢复到断裂前的全量+日志备份状态。

内容的提问来源于stack exchange，提问作者Aaron Krytus