我主要是开发人员，但是对于一个小型的内部系统，我目前还负责运行SQL Server企业版的服务器的一些configuration。
数据库本身从两个来源看到活动：
我使用内置的SQL服务器备份实用程序相当高兴，我已经设置了一个维护计划，每6小时备份整个数据库，事务每隔6个小时在数据库备份之间logging（例如，上午6点，数据库备份，上午9点事务日志备份，12点数据库备份，3点事务日志备份）。 我们每周都会收集整个服务器的磁带快照（数据不是关键任务，更像是一个研发项目）。
在build立之前，数据库开始急剧增长，现在所有完整的数据库备份都以非常易于pipe理的15Mb（并且在缓慢增长）进行，事务日志logging在9到12Mb之间。
我做对了吗？ 您对事务日志备份的频率有任何其他洞察吗？
如果在另一个问题中有什么我错过了可能是有用的，请随时指向我。
坦率地说，没有理由不以更频繁的速度运行事务日志备份。 事务日志备份不会阻碍任何事情。 （在大多数情况下，它只是需要一点CPU和磁盘活动 – 但它通常几乎可以忽略不计。）
此外，通过将日志文件备份移动到性能较低的磁盘，您可以提高覆盖率并提高性能： SQL Server Magazing：最大化存储性能
通过增加备份频率，您可以减less可能丢失数据的窗口。 （从技术上讲，如果你的日志文件仍然完好无损，如果SQL Server崩溃，你有时可以恢复自上次完整/差异备份以来丢失的事务。但通常，如果出现问题，足以让你首先备份， DECENT偶尔你的日志文件不见了/吐司。）
请随时查看以下video，了解更多背景信息以及有关备份，日志和最佳做法方面的信息：
SQL Server备份揭秘
SQL Server日志logging要点
pipe理SQL Server 2005/2008日志文件
SQL Server备份最佳实践
听起来不错。 你必须记得testing你的备份！
如果您的系统变得至关重要，您还可以考虑事务日志传送，或者更频繁的时间间隔超过3小时。
最佳SQL Server备份策略取决于您的数据库可用性和数据一致性要求…
如果您准备在6小时内丢失数据（连续事务日志/数据库备份之间的时间间隔），则可以。 如果没有 – 考虑优化备份策略（例如，更频繁的事务日志备份/增量备份，甚至数据库镜像）。
安迪，
你也可以在数据库上configuration一些索引维护。 您可以为这些活动configuration单独的维护计划，可能在用户没有连接时每晚或每周运行一次。
如果您有备份策略，那么您的恢复时间是每三个小时。 只要你可以忍受在绝对糟糕的时间丢失三小时的数据，一切都很好。