在此先感谢您就此主题提供的任何帮助。这是我从 stackoverflow 发来的第一篇 serverfault 帖子。
我一直在工作中设置 SQL Server 实例，用于安装我们销售的应用程序，理想情况下，我们希望它基本上可以独立运行。为此，我设置了一些维护计划，用于运行备份、清除日志表和重建索引等。
所有这些都运行正常，但我对备份的工作方式有点困惑。我进行了全面的每周完整备份，每晚进行差异备份，每小时进行事务日志备份。一切都运行正常，但随着系统使用的增加，我注意到每小时事务日志备份变得越来越大。有时甚至超过 2GB，而完整备份只需要 90MB。这可能是正常的，但在我看来似乎很奇怪。据我所知，事务日志备份应该对服务器的影响非常小，但怎么会这样，写入 2GB 的数据永远不会那么快。当然，这些日志的大小会导致磁盘空间问题（服务器的规格很吝啬 - 不是我的选择），我们的服务受到了一些损失。
所以实际上有两个问题，为什么事务日志备份这么大，我是否做错了什么。
其次，我是否应该关心事务日志备份，为什么不直接进行每小时差异备份，因为它们的大小只有大约 20MB。
如果有人愿意向我推荐一些关于备份的好书，我也会非常感激。我确实有一本好书，《SQL Server 2005 unleashed》，但我可能需要一本关于备份的更详细的书，才能真正获得设计适当备份计划所需的信息。
答案1
导致此行为的原因之一是您的数据库执行大量更新、插入和删除操作。就您而言，如果仅更新数据或插入/删除行，则整个数据库的大小可能不会增长。将数据库置于完全恢复模型，意味着 SQL Server 需要维护所有这些更改的运行日志，这使您能够执行时间点恢复，但这意味着您的日志备份将很大。
首先，我想问的是，您的应用程序是否真的需要时间点恢复？这不是您可以做出的决定，而是一项业务决策。如果业务确实决定需要时间点恢复，那么请考虑以较小的间隔进行事务日志备份，并让主管知道您将需要大量存储空间！
如果企业决定不需要 point-int 时间，但希望获得最新的可恢复性，那么可以考虑使用批量日志恢复模型并每隔几分钟进行一次日志备份。这可能会减少日志备份的大小，具体取决于应用程序正在执行的操作，因为某些操作可以最少地记录。这意味着当发生日志备份时，它实际上正在复制最少日志事务的数据页。
当然，如果企业愿意丢失几个小时或一天的数据，那么可以改为简单恢复模型结合完整/差异备份是可行的方法。