我试图说服客户，他们的SQL Server备份策略是不够的。 长话短说，他们目前的备份“策略”是每周完整备份，然后是每日事务日志备份。 我已经build议客户，由于数据库的大小，他们应该切换到每日完整的备份策略，同时进行多个日常事务日志备份，或者至less每日添加差异备份到已有的备份。 然而，他们正在摆弄这个，因为它需要比现有更多的驱动器空间。 所以，我的问题是 – 对于只有每周完整备份和日常事务日志备份的备份策略，可能会出现哪些潜在的问题或风险？ 是否主要是可能需要几个小时或几天来恢复数据库，因为t-log恢复必须在完全备份恢复后重新运行每个事务？
以下是大小和活动上下文数据库的规格：
他们的备份策略不应该由您的意见所驱动，而应该由恢复点目标和恢复时间目标驱动。 与客户进行讨论，然后实施一个满足这些目标的备份策略。
话虽如此，如果您提到的数量和大小的数据库和事务日志的恢复时间超过了几分钟，我会感到非常惊讶。 这当然不会需要几个小时或几天。
我最关心的是事务日志备份。 如果在计划的t-log备份之前五分钟他们将丢失数据库，那么他们可能会损失几乎24小时的数据。
更频繁的日志备份不应占用太多的空间 – 不会有更多的事务。 它应该只是允许更好的还原点。
（不，不需要几天就可以在12.5GB的数据库上运行恢复。）
在这种情况下，差异的主要优势在于您可能会开始发现日志备份文件的数量不便。 如果他们正在运行每周完整和每小时事务日志备份，那么每天有24个文件。 如果他们在完整备份之前五分钟，在最后一次备份之后的五十五分钟内丢失了数据库，那么他们可能会丢失五十五分钟，并且需要167个日志备份（我假设它们是不同的文件）。 每晚的差价，他们只需要23。
（如果他们认为55分钟太多了，请更频繁地备份事务日志，并相应地增加文件数量。）