为什么备份事务日志如此重要？

我们目前正在为客户端实施备份解决方案，而他们的ERP解决方案使用SQL Server。

ERP解决方案是由另一家公司建立的。而且他们告诉我，备份和截断事务日志是超级重要。

我一直在阅读此事务日志，但无论如何我已经备份了整个计算机时，我不明白为什么这是如此重要（我们使用的是ArcServe UDP，它知道SQL Server并使用VSS）。据我了解，SQL Server VM上的清理任务已经在处理截断日志，但是，UDP也允许SQL Server日志截断。

据我了解，事务日志可用于还原损坏的数据库，因为它是所有事务的日志。但是我已经有整个数据库的每小时备份，那么，为什么我会关心呢？

仅当数据库恢复模式设置为“完全”时，才需要这样做。如果将其设置为“简单”，则不必备份事务日志。但是请注意这两个选项之间的区别！

首先：如果您希望能够将数据库还原到特定的时间点，则必须使用“完全”模式。（我认为您可以精确地调整时间，甚至可以指定恢复点的毫秒数）。在“简单”模式下，您只能返回到上次完整备份。

如果不备份/截断事务日志，它将在整个时间内（以完整模式）增长。我看到的数据库中.trn文件的大小是数据库本身的两倍以上。这取决于对数据库进行更改的频率。

另一点是，日志备份通常比完整备份更快。

因此，我认为您的每小时进行一次完整备份的备份计划不是最佳的。但这取决于您的情况：

如果您说：好的，如果我可以将数据库还原到最后一个小时，一切都很好。->如果您想每小时保留一次完整备份，也可以考虑将恢复模式设置为“简单”。

我认为，一个更好的主意是在清晨进行一次完整备份，然后每小时进行一次事务日志备份。它应该快得多，并且您可以恢复到想要的任何时间点。而且您的.trn文件不会增长太多...

希望这可以帮助。

好。您很在意，因为如果您将恢复模型设置为完全，并且不使用SQL的备份（而不是服务器备份）来备份事务日志，则事务日志会继续增长，直到消耗所有可用磁盘空间为止。（我曾经看到一个较小的同事在系统驱动器上安装SQL Server，并且从不备份事务日志。它是Windows的。）

是的，它也会恢复到特定的时间点。直到分钟。就像Twinkles所说的，是的，人们在放桌子之类的东西。

我不知道您每小时用于备份整个数据库的内容，以及它是否与整个计算机使用的产品相同。如果是这样，则不支持非SQL感知的备份解决方案。例如，VSS复制MDF和LDF文件所花费的时间可能会导致内部时间戳不匹配。

我们还管理多个ERP系统。问题通常在于，晚上经常有长时间运行的批处理作业，这些作业与其他系统同步数据。他们有时要花一个小时或更长时间。因此，如果发生崩溃，您想要做的就是跳到拥有一致数据的地步。（这意味着在两个批处理作业之间进行。）如果仅查看时间，则可能并不总是确切知道此时数据库的状态。

但是，当然这取决于情况。如果您没有任何自动化作业等，那么每小时进行一次备份就可以了。

您要这样做的原因有几个：

1. 数据库系统通常很忙，可能每秒执行数千个事务。数据可以分布在不同文件系统上的多个文件中。还原后确保数据库处于一致（即可用）状态并非易事。如果您的备份解决方案能够胜任该任务，那很好，但是您最好在将工作押在此之前先确定一下。
2. 一个例子：有人误将重要数据放入表中。如果您具有具有时间点恢复功能的数据库备份，则可以快速还原数据，而不必还原整个系统。
3. 如果数据库处于完全恢复模式，则SQL Server的事务日志将增长。事务日志中的存储空间仅在备份了事务日志后才能重新使用。如果您不定期备份事务日志，则文件系统将填满，直到没有剩余空间。此时，由于无法开始新的事务，一切都将立即停止。

当数据库增长到一个小时内无法备份时，您需要一个不同的模型。

数据库的完整备份将截断日志，但是它需要“ SQL感知”，因为在这种情况下，正是备份软件告诉SQL Server已备份的内容以及要截断的内容。

就像其他人提到的那样，如果您的数据库处于“完全”恢复模型中，则它的事务日志将无限期增长，直到您进行完全SQL感知的备份为止。

恢复实际上是这里的问题，而不是备份。这不是技术决定，而是业务决定！

如果您的企业主可以避免丢失一个小时或更多的数据库事务（可能很难或无法重做！），那么您的模型就可以使用。如果通过备份恢复整个数据库时系统停机了几个小时就可以了，那么您的模型就可以工作了。

但是，如果您的企业将其ERP系统视为对其运营至关重要的资产（不是全部吗？），则为关键服务设置最大可接受的恢复时间（又称RTO，恢复时间目标）将是一项业务决策。

此外，业务所有者或系统利益相关者需要定义他们愿意在事件中（即RPO（恢复点目标））冒险丢失多少数据。

如果您询问他们，答案可能是“不会丢失任何数据！ERP系统必须在24/7/365可用！” ...我们都知道，这样做不太可能具有成本效益。如果向他们介绍与构建这样一个完全冗余的不间断系统相关的成本，他们将提供更合理的数字。

关键是，如果您可以避免丢失任何交易，则可以为您的企业节省数百或数千的工作时间损失。它可以为任何公司节省大量资金，并且随着公司规模的增长而增长...

每个人对此都有很好的回应，但我想补充一点重要的注意事项……或两个。

了解SQL Server恢复模型的详细信息以及您对数据丢失的业务要求都非常重要。但是，在这种情况下，必须了解备份产品如何与SQL Server一起使用。（根据上面的评论，听起来您正在通过VSS复制备份磁盘卷，这意味着另外可能需要或可能不需要SQL Server备份。）

在最近评估过类似产品之后，您可能需要询问的一些重要方面是：

• 对于完全恢复的数据库，如何执行恢复到某个时间点的还原？
• 在完全恢复中如何处理新数据库的初始备份？
• 备份产品是否需要SQL Server日志备份才能还原到某个时间点？（就我而言，答案是肯定的。）
• 除了正常的SQL负载外，您的存储基础架构还能处理VSS副本/差异的数据量（以给定的间隔）吗？

希望这会有所帮助。

我的团队在最近的评估中所获得的经验为上述问题提供了一些非常有趣的答案。可以肯定的是，使用VSS备份产品，备份对我们来说更加复杂。

正如许多其他人已经说过的那样，如果您使用第三方工具来备份/快照VM或存储，则仍然存在没有有效备份的风险。所有管理SQL Server备份的第三方工具都将使用VSS实施并连接到SQL Server。这样做是为了要求SQL Server停止对数据文件的所有I / O，以便可以获取一致的快照。如果没有，那么您可以在各种状态下拥有许多事务，而还原将不知道这些事务是否可以向前或向后滚动。

我没有使用过所有第三方VM /存储快照工具，但是我使用过的工具无法快照存储系统数据库所在的存储-SQL Server无法使这些数据库停顿。他们都以流式方式备份了这些数据库-即，发出BACKUP DATABASE命令，然后快照备份文件本身。

最重要的是，正如许多人所说的那样，如果您处于FULL恢复模式，并且不定期发出BACKUP LOG语句，则事务日志将继续增长，直到磁盘上没有剩余空间为止。

您需要问一个真正的问题，上面我可能已经错过了……您是否多次成功地从这些备份中还原，并且对这些还原中数据的一致性感到满意？就个人而言，即使这对我来说还不够，它仍然感觉像一掷骰子，而对于备份和恢复，这是一个好的DBA永远都不会做的事情。

认识到事务日志不仅仅是一种恢复机制。适当的日志维护在总体数据库性能（即事务吞吐量）中也可以发挥关键作用。

经常备份您的日志文件会执行以下两项操作：

1. 它减少了物理日志文件中的VLF计数，这对性能很有好处。
2. 如果需要恢复数据库，则最好准备使用日志备份。
3. 比完整备份要快很多

如果您每小时可以进行一次完整备份，那么您不确定从更频繁的日志备份中能获得多少收益。毕竟，据我所知，完全备份还将备份必要数量的日志，以确保完全还原。

另一方面，如果您的应用在每小时完整备份之间产生大量事务，那么这也许可以解释为什么原始开发人员建议进行更精细的日志维护。许多事务可能会增加日志中的VLF计数，这可能会导致性能下降，直到日志被截断为止。我已经看到这表示为应用程序中的“查询超时过期”错误（挂起前不久）。

与事务日志维护相关的建议在本文“改善事务日志吞吐量的8个步骤”中进行了很好的描述。此外，本文有效数据库维护的重要技巧还提到了针对（<200）的任意VLF计数，这对我来说非常有效。

其他人已经给出了进行Translog备份等的大多数原因。对于已经备份服务器的为什么这是一个很好的策略，似乎存在一些疑问。

对于我来说，有两个以上没有提到的充分理由。如果您的第三方应用程序无法进行备份怎么办，可以还原该怎么办？您是否尝试还原备份？对于刚刚从模板构建的新服务器（想想DR）呢？对于您域中具有不同排序规则的另一台服务器该怎么办？还是SQL实例？

我无缘无故地进行冗余备份，只是有时您的第三方应用程序不是还原的最快方法。有时您的第三方应用程序保存到的存储也会受到影响，或者由于自身原因而损坏。