我是一名 .NET 开发人员，我知道如何编写 SQL，但对任何形式的数据库维护调度等一无所知
所以，我最近接手了一位前客户的一个项目。该网站由 Rackspace 托管。
无论如何，以前的客户每天进行三次完整备份（每 8 小时一次）。我只是好奇正确的标准是什么？
我有一些问题。
我应该追加还是覆盖？
我是否要将每日备份设置为过期？[我相信 Rackspace 也会进行每日差异备份和每周完整备份]
我需要备份事务日志吗？
我是否需要缩小事务日志？
请分享一些见解和最佳实践。我们将不胜感激！
谢谢！！
答案1
我应该追加还是覆盖？
如果之后要将其录制到磁带上，我会覆盖，否则选择一个可接受的磁盘时间范围以使备份过期（根据您的恢复时间）并附加。
我是否要将每日备份设置为过期？[我相信 Rackspace 也会进行每日差异备份和每周完整备份]
是的，除非磁盘空间不是问题
我需要备份事务日志吗？
是的，按照您需要的频率进行时间点恢复。例如，如果您的 SLA 规定在发生故障时您只会丢失 15 分钟的数据，那么您需要每 15 分钟备份一次交易日志。
我是否需要缩小事务日志？
不，除非你让它在某个时候增长到巨大的规模，而且现在它使用的容量从未超过 1%，而你的磁盘空间不足，那么也许
请分享一些见解和最佳实践。我们将不胜感激
您需要与企业合作，确定在出现问题时他们预计会丢失哪些类型的数据，以及数据库将无法使用多长时间。一旦您就这些达成一致，剩下的就变成了数学练习。在您的示例中，您提到您每天进行 3 次全量操作。您需要找出这是否只是某些人的胡乱猜测，或者是否有原因导致每天进行 3 次操作（可能是由于恢复时间无法进行增量操作）
请注意，只有在您了解业务需求后，您才能规划恢复。“规划恢复”这个口号被滥用了，以至于许多管理员实际上相信了这一点，并且犯下了他们如果只担心备份就会犯的同样类型的错误。
答案2
实际上并不存在一个“适当的标准”，而是一个以下问题：
您能承受丢失多少数据？
一个相当标准化的备份是这样做的：
- 每周进行完整备份（或每周 2-3 次）
- 每天（或每天几次）进行差异备份
- 已实施日志传送的辅助服务器
显然，这取决于您的负载情况、用于备份的磁盘空间大小等等。
根据您提供的信息，我认为每天进行三次完整备份是没有必要的。您可以每天进行一次完整备份，然后根据需要进行多次差异备份。
备份的真正关键不在于规划备份，而在于规划恢复过程。
如果您从一开始就考虑最终结果...以及所涉及的恢复过程和可能丢失（或愿意丢失）的最大数据量，那么您就会找到适合您的备份计划。
答案3
在我的商店中，我每小时运行一次 t-log 备份。我的差异备份每晚运行一次，完整备份在周日运行一次。我没有将备份设置为自动过期。当不再需要它们时，我会手动删除它们。我还没有实施日志传送，因为我还没有可用的资源……目前还没有。