我们目前正在为客户实施备份解决方案，他们的 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 系统。问题通常是晚上经常有长时间运行的批处理作业与其他系统同步数据。他们有时需要一个小时或更长时间。因此，如果发生崩溃，您想要做的是跳转到您拥有一致数据的点。（这意味着正好在两个批处理作业之间。）如果您只查看时间，您可能并不总是确切地知道此时数据库的状态。
但当然，这取决于具体情况。如果您没有任何自动化作业等，您可以使用每小时备份完全没问题。
您想要这样做有几个原因：
当您的数据库增长超出您在一小时内能够备份的容量时，您需要一个不同的模型。
数据库的完整备份将截断您的日志，但它需要“支持 SQL”，因为在这种情况下，备份软件会告诉 SQL 服务器它已备份的内容以及要截断的内容。
正如其他人提到的，如果您有一个处于“完整”恢复模式的数据库，它的事务日志将无限增长，直到您进行完整的 SQL 感知备份。
恢复确实是这里的问题，而不是备份。这不是技术决策，而是商业决策！
如果您的企业主可以接受丢失一个小时或更长时间的数据库事务（这可能非常困难或不可能重做！），那么您的模型就可以工作。如果在您从备份中恢复整个数据库时系统停机几个小时，他们可以接受，那么您的模型就可以工作。
但是，如果您的企业将其 ERP 系统视为其运营的关键资产（不是全部吗？），那么为您的关键服务设置最大可接受的恢复时间（也称为 RTO，恢复时间目标）将是一项业务决策。
此外，业务所有者或系统利益相关者需要定义他们愿意在事件中冒丢失多少数据的风险，即 RPO（恢复点目标）。
如果您问他们，答案可能是“不会丢失任何数据！ERP 系统必须 24/7/365 全天候可用！”......我们都知道这不太可能具有成本效益。如果您向他们展示与构建这样一个完全冗余的不间断系统相关的成本，他们会提出更合理的数字.. ;)
关键是，如果您可以避免丢失任何交易，您可能会为您的企业节省成百上千的工作时间。这对任何公司来说都是巨大的节省，并且随着公司规模的增长而增长......
每个人对此都有很好的反应，但我想添加另一个重要说明......或两个。
了解 SQL Server 恢复模式的细节以及您对数据丢失的业务需求都非常重要；但是，在这种情况下，您必须了解备份产品如何与 SQL Server 配合使用。（根据上面的评论，听起来您正在通过 VSS 副本备份磁盘卷，这意味着可能需要也可能不需要 SQL Server 备份。）
最近评估了一个类似的产品，您可能需要询问的一些重要问题是：
希望这会有所帮助。
我的团队对我们最近的评估的经验为上述问题提供了一些非常有趣的答案。可以肯定的是，使用 VSS 备份产品的备份对我们来说更加复杂。
正如许多其他人已经说过的那样，如果您使用第三方工具来备份/快照 VM 或存储，您仍然面临没有有效备份的风险。所有管理 SQL Server 备份的第三方工具都将使用 VSS 实施并连接到 SQL Server。它这样做是为了请求 SQL Server 静默所有对数据文件的 I/O，以便可以拍摄一致的快照。如果没有，那么您可以有许多处于不同状态的事务，并且还原将不知道这些事务是否可以向前或向后滚动。
我没有使用过所有第三方 VM / 存储快照工具，但我使用过的工具永远无法对系统数据库所在的存储进行快照 - SQL Server 无法停止这些数据库。他们都以流式方式备份这些数据库 - 即......发出 BACKUP DATABASE 命令，然后捕捉备份文件本身。
最重要的是，正如许多人所说，如果您处于 FULL 恢复模式，并且您不定期发出 BACKUP LOG 语句，则事务日志将继续增长，直到磁盘上没有空间为止。
您需要问的真正问题，我可能在上面错过了...您是否多次成功地从这些备份中恢复，并且您对这些恢复中数据的一致性感到满意。就个人而言，即使这对我来说还不够，它仍然感觉像是掷骰子，而这是一个优秀的 DBA 在备份和恢复方面永远不会接受的事情。
认识到事务日志不仅仅是一种恢复机制。适当的日志维护也可以在整体数据库性能（即事务吞吐量）中发挥关键作用。
经常备份你的日志文件会做几件事：
如果您可以每小时进行一次完整备份，那么我不确定您会从更频繁的日志备份中受益多少。毕竟，据我了解，完整备份还将备份尽可能多的日志，以确保完整还原。
另一方面，如果您的应用程序在每小时完整备份之间产生大量事务，那么这可能解释了为什么最初的开发人员建议进行更细粒度的日志维护。许多事务可能会增加日志中的 VLF 计数，这可能会导致性能损失，直到日志被截断。我已经看到这表示为应用程序中的“查询超时过期”错误（在它挂起之前不久）。
这篇文章8 Steps to Better Transaction Log Throughput很好地描述了与事务日志维护相关的建议。此外，这篇文章有效数据库维护的重要提示提到了一个有点武断的 VLF 计数目标（< 200），这对我来说效果很好。
其他人已经给出了translog备份等的大部分原因。当您已经备份服务器时，为什么这是一个好的策略似乎有些疑问。
对我来说，有几个很好的理由不在上面。如果您的第 3 方应用程序无法进行备份，您可以恢复怎么办？您是否尝试过恢复备份？对于您刚刚从模板构建的新服务器（想想 DR）怎么样？对于您域上具有不同排序规则的另一台服务器呢？还是 SQL 实例？
除了有时您的第三方应用程序不是最快的恢复方式外，我无缘无故地进行冗余备份。有时，您的 3rd 方应用程序保存的存储空间也会受到影响，或者由于其自身原因而损坏。