我试图说服客户，他们的 SQL Server 备份策略是不够的。长话短说，他们当前的备份“策略”是每周进行一次完整备份，然后进行每日事务日志备份。我已经建议客户，由于数据库的大小，他们应该切换到每日完整备份策略，并伴随着多次每日事务日志备份，或者至少在他们已经拥有的备份策略上添加每日差异备份。然而，他们对此感到困惑，因为这将需要比他们现有的更多的驱动器空间。所以，我的问题是 - 对于仅是每周进行一次完整备份和每日事务日志备份的备份策略，可能存在哪些潜在问题或风险？主要是因为在完整备份恢复后，t-log 恢复必须重新运行每个事务，因此可能需要数小时或数天才能恢复数据库吗？
以下是数据库的大小和活动上下文的规格：
- 数据库使用空间：约12.5GB
- 一周的事务日志备份：7 个 TRN 文件，总大小约为 400 MB
- 每周重新索引后事务日志备份：约 3GB
答案1
他们的备份策略不应该由您的意见决定，而应该由他们的恢复点目标和恢复时间目标决定。与客户进行讨论，然后实施符合这些目标的备份策略。
话虽如此，如果恢复您提到的数据库和事务日志的数量和大小需要几分钟以上，我会感到非常惊讶。当然不会花几个小时或几天。
答案2
我最担心的其实是事务日志备份。如果他们在预定的事务日志备份前五分钟丢失数据库，他们可能会丢失近 24 小时的数据。
更频繁的日志备份不应该占用那么多空间——不会有更多的交易。它应该只允许更好的还原点。
（不，恢复 12.5GB 的数据库并不需要花费几天的时间。）
在这种情况下，差异的主要优势在于，您可能会开始发现日志备份文件的数量难以处理。如果他们每周运行一次完整备份，每小时运行一次事务日志备份，那么每天就有 24 个文件。如果他们在完整备份前五分钟丢失了数据库，在最后一次日志备份后五十五分钟丢失了数据库，那么他们可能会损失五十五分钟，并且需要 167 个日志备份（我假设这些是不同的文件）。如果使用夜间差异，他们只需要 23 个。
（如果他们认为 55 分钟的损失太大，则更频繁地备份事务日志，并相应地增加文件数量。）