我们目前正在为客户实施备份解决方案，他们的 ERP 解决方案使用 SQL Server。
ERP 解决方案由另一家公司设置。并且他们告诉我备份和截断事务日志非常重要。
我已经阅读了一些关于这个交易日志的内容，但我不明白为什么这如此重要我已经备份了整台机器（我们正在使用 ArcServe UDP，它可以识别 SQL Server 并使用 VSS）。据我了解，SQL Server VM 上的清理任务已经负责截断日志，但是，UDP 还允许 SQL Server 日志截断。
据我所知，事务日志可用于恢复损坏的数据库，因为它是所有事务的日志。但我已经对整个数据库进行了每小时备份，那么我为什么要关心它呢？
答案1
只有当您的数据库恢复模式设置为“完整”时，您才需要这样做。如果设置为“简单”，您不必备份事务日志。但请注意这两个选项之间的区别！
首先：如果您希望能够将数据库还原到具体时间点您必须使用“完整”模式。（我认为您可以调整时间，甚至精确到可以指定还原点的毫秒数）在“简单”模式下，您只能返回到上次完整备份。
如果您不备份/截断事务日志，它将一直增长（在完整模式下）。我看到数据库中的 .trn 文件比数据库本身大两倍多。这取决于对数据库进行更改的频率。
另一点是日志备份通常比完整备份更快。
因此，我认为每小时进行一次完整备份的备份计划并不是最佳选择。但这取决于您的情况：
如果你说：好的，如果我可以将数据库恢复到最后一个整小时，那么一切都没问题。-->如果您想每小时保留完整备份，您还可以考虑将恢复模式设置为“简单”。
我认为，更好的办法是在清晨进行完整备份，然后每小时进行一次事务日志备份。这样应该会快得多，而且你可以恢复到你想要的任何时间点。而且你的 .trn 文件也不会增长太多……
希望这可以帮助。
答案2
好吧。你之所以关心，是因为如果你将恢复模式设置为完整，并且不使用 SQL 的备份（而不是服务器备份）备份事务日志，事务日志就会继续增长，直到它耗尽所有可用的磁盘空间。（我曾经看到一个不太擅长的同事在系统驱动器上安装了 SQL Server，但从不备份事务日志。它吃窗户。
是的，它还会恢复到特定时间点。精确到分钟。就像 Twinkles 说的，是的，人们会放下桌子之类的。
我不知道您每小时备份整个数据库时使用的是哪种产品，以及它是否与您备份整个计算机时使用的产品相同。如果是，则不支持非 SQL 感知备份解决方案进行恢复。例如，VSS 复制 MDF 和 LDF 文件所需的时间可能会导致内部时间戳不匹配。
答案3
我们还管理多个 ERP 系统。问题往往在于，晚上经常会有长时间运行的批处理作业与其他系统同步数据。有时它们会花一个小时甚至更长时间。因此，在发生崩溃时，您要做的就是跳转到具有一致数据的点。（这意味着就在两个批处理作业之间。）如果您只看时间，您可能并不总是确切知道数据库当时的状态。
但当然这取决于具体情况。如果你没有任何自动化作业等，每小时备份一次就完全没问题了。
答案4
当您的数据库超出您在一小时内能够备份的范围时，您需要一个不同的模型。
数据库的完整备份将截断您的日志，但它需要“SQL 感知”，因为在这种情况下，备份软件会告诉 SQL 服务器它已备份什么以及要截断什么。
正如其他人提到的，如果您的数据库处于“完整”恢复模型中，它的事务日志将无限增长，直到您进行完整的 SQL 感知备份。
恢复才是真正的问题，而不是备份。这不是一个技术决定，而是一个商业决策！
如果您的企业主可以接受丢失一小时或更长时间的数据库事务（这可能非常困难或不可能重做！），那么您的模型就有效。如果他们可以接受系统停机数小时，而您从备份中恢复整个数据库，那么您的模型就有效。
然而，如果您的企业将其 ERP 系统视为其运营的关键资产（难道不是吗？），那么为您的关键服务设置最大可接受恢复时间（又名 RTO，恢复时间目标）将是一项业务决策。
此外，企业主或系统利益相关者需要定义他们愿意承担在事件中丢失多少数据的风险，即 RPO（恢复点目标）。
如果你问他们，他们的答案可能是“不能丢失任何数据！ERP 系统必须 24/7/365 全天候可用！”……我们都知道这不太可能具有成本效益。如果你向他们展示构建这样一个完全冗余、不间断的系统所涉及的成本，他们会得出更合理的数字。；）
重点是，如果您可以避免丢失任何交易，那么您就可能为企业节省数百或数千个工作小时的损失。这对任何公司来说都是一笔巨大的节省，并且会随着公司规模的扩大而增长……