我主要是一名开发人员，但对于一个小型内部系统，我目前还负责运行 SQL 服务器企业版的服务器的一些配置。
数据库本身可以从两个来源看到活动：
- 提供数据的客户端软件
- 我们的客户使用这个网络应用程序来检查来自客户的数据并进行外部管理。
我对使用内置的 SQL Server 备份实用程序相当满意，我制定了一个维护计划，每 6 小时备份一次整个数据库，并在数据库备份之间每 6 小时备份一次事务日志（例如，早上 6 点，数据库备份，早上 9 点事务日志备份，中午 12 点数据库备份，下午 3 点事务日志备份）。我们每周对整个服务器进行磁带快照（数据不是关键任务，更像是研发项目）。
在进行此项设置之前，数据库开始急剧增长，现在所有完整数据库备份的大小都在非常易于管理的 15Mb 左右（并且缓慢增长），事务日志的大小在 9 到 12Mb 之间。
我做对了吗？您对事务日志备份的频率还有其他见解吗？
如果我遗漏了其他问题中任何可能有用的内容，请随时指出我。
答案1
坦白说，没有理由不以更高的频率运行事务日志备份。事务日志备份不会造成任何损害。（在大多数情况下，它只会占用一点 CPU 和磁盘活动 - 但通常几乎可以忽略不计。）
此外，您可以通过将日志文件备份移至性能较差的磁盘来增加覆盖率并提高性能： SQL Server Magazing：最大化存储性能
通过增加备份频率，您可以减少可能丢失数据的时间。（从技术上讲，如果 SQL Server 崩溃，有时您可以恢复自上次完整/差异备份以来丢失的事务，前提是您的日志文件仍然完好无损。但通常情况下，如果出现足以让您首先备份的问题，则您的日志文件很有可能会丢失/损坏。）
请随意观看以下视频，了解有关备份、日志和最佳实践的更多背景信息：
答案2
到目前为止听起来不错。你也必须记得测试你的备份！
如果您的系统变得至关重要，您还可以考虑事务日志传送，或以超过 3 小时的频率传送。
答案3
最佳 SQL Server 备份策略仅取决于您的数据库可用性和数据一致性要求......
如果您准备好丢失数据 6 小时（连续事务日志/数据库备份之间的时间段） - 没关系。如果不行 - 请更多地考虑优化备份策略（例如，更频繁地进行事务日志备份/增量备份，甚至数据库镜像）。
答案4
如果你的备份策略没问题，那么恢复窗口是每三个小时一次。只要你能忍受在最糟糕的时候丢失三个小时的数据，一切都没问题。