我是一个.NET开发人员，我知道如何编写SQL，但是在执行任何forms的数据库维护调度yadda时，却一无所知
所以，我最近接pipe了一个以前客户的项目。 该网站托pipe与Rackspace。
无论如何，以前的客户每天（每8小时）做三次完整备份。 我只是好奇什么是正确的标准？
我有一些问题。
我追加还是覆盖？
我是否将每日备份设置为过期？ [Rackspace做每日差分和每周完整我相信以及]
我是否需要备份事务日志？
我是否需要缩小事务日志？
请分享一些见解和最佳实践。 他们将不胜感激！
谢谢！！
我追加还是覆盖？
如果以后要磁带，我会覆盖，否则select一个可以接受的磁盘时间段备份到期（根据您的恢复时间），并追加。
我是否将每日备份设置为过期？ [Rackspace做每日差分和每周完整我相信以及]
是的，除非磁盘空间不是问题
我是否需要备份事务日志？
是的，只要你需要一个时间点的恢复。 例如，如果您的SLA表示如果发生故障，您将只丢失15分钟的数据，则需要每15分钟备份一次转录日志。
我是否需要缩小事务日志？
没有，除非你以某种方式让它在一个点上成长为一个巨大的尺寸，现在从未超过1％，而且磁盘空间不足，那么也许
请分享一些见解和最佳实践。 他们将不胜感激
您需要与业务部门合作，以确定在出现问题时他们期望丢失的数据types，以及将允许数据库不可用的时间。 一旦你有了这些协议，其余的就成为一个math练习。 在你的例子中，你提到你每天做3满。 你需要弄清楚这是不是有人在黑暗中拍摄的，或者是因为这是一天3的原因（可能是因为恢复时间不可能增加）
请注意，只有在获得业务要求后，才能计划恢复。 “计划你的恢复”的口头禅如此滥用，以至于许多pipe理者实际上相信这一点，并且如果他们只是担心备份，就会犯同样的错误。
实际上没有一个“适当的标准”，而是一个问题：
你能承受多less数据丢失？
一个相当标准的备份是做这样的事情：
显然这取决于你的负载看起来像多less磁盘空间备份等
根据您提供的信息，我不认为每天有三个完整的备份是必要的。 您可以很容易地每天进行一次完整备份，然后根据您的需要select尽可能多的差异备份。
备份的REAL键不是像计划恢复过程那样计划备份。
如果您从头到尾考虑…并且涉及到恢复过程以及您可能丢失（或愿意丢失）的最大数据量，那么您会发现适用于您的备份计划。
在我的店里，我每小时运行一次t-log备份。 我的差异每晚运行，我的完整备份周日运行。 我没有将我的备份设置为自动过期。 我不再需要时手动删除它们。 我还没有实现日志传送，因为我没有可用的资源。