mssql 2019永远--关于集群备份日志链被打破

Question

现在，我有了一个mssql 2019 Alwaysoncluster.i主节点上的备份数据库，使用每月全备份。每周差异备份。每日日志备份。但不幸的是，备份日志链总是中断，包括日志备份和差异备份.i，检查日志链如下：

.Has任何人都遇到了类似的问题，是由alwayson集群造成的吗？

我认为完整备份后的日志备份的first_LSN值等于上一次日志备份的last_lsn。它显示日志备份不会破坏LSN链，并且自上次日志备份以来它将继续维护该链。但是在我的链日志备份的first_LSN值中，不等于上一次日志备份的last_lsn。我还发现，对于几个相对较小的数据库，当前日志备份的first_lsn总是比上一个日志备份的last_lsn少100000。mysql数据库中没有其他计划作业。另外，差异备份也是

Answer 1

每天的日志备份似乎是方式、方式、方式之间的时间太长了。此外，正如评论所提到的，我很肯定这里没有列出其他一些备份。

• 忘记用于还原方案的msdb数据。如果你的服务器着火了，你不会有它，所以如果你习惯不使用它，你会有更好的习惯在灾难中，这意味着较少的压力。
• 那么，看看你的实际文件-你回哪里去了？看那儿！
  • 那里一天有不止一个文件吗？
  • 请从磁盘恢复HEADERONLY，并查看LSN。他们匹配吗？
  • 酸测试:做一个测试恢复。它会抱怨木链断了吗？

• 正如注释所提到的，查看集群中的其他节点可能备份到的位置。
• 如果你仍然找不到它，仍然有日志链断裂，调高日志备份的频率-我已经看到一分钟，5分钟，15分钟，1小时，4小时相当正常。
  • 让它运行一天；现在，日志何时损坏？你可以从这里缩小范围。请注意，您可以有两个日志备份作业的时间表-一个在“正常”频率一整天，另一个在“高”频率的时间跨度正在缩小。
    • 提示--至少在较旧的SQL中，您可以使用第一个LSN =最后一个LSN进行日志备份，然后尝试恢复该错误。跳过它，继续前进，它是烦人的，但无害的。

• 所有的失败..。有人在对你做截断日志吗？改变完全恢复模式，然后再回来？阻止他们。