只进行每周完全备份和每日事务日志备份的Server备份策略的风险是什么？
我试图让客户相信他们的Server备份策略是不够的。长话短说，他们当前的备份“策略”是一周一次的完整备份，然后是每日事务日志备份。我已经通知客户端，由于数据库的大小，他们应该切换到每天完整的备份策略，同时进行多个每日事务日志备份，或者至少在现有的基础上添加一个每日差异备份。然而，他们在这周围挣扎，因为它将需要比他们已经有更多的驱动器空间。所以，我的问题是--每周备份和每日事务日志备份的备份策略可能会出现哪些潜在的问题或风险？主要原因是恢复数据库可能需要几个小时或几天，因为t-log还原必须在恢复完整备份之后重新运行每个事务吗？
以下是用于调整大小和活动上下文的数据库规范：
- 使用的数据库空间:大约12.5GB
- 价值一周的事务日志备份:总计约400 MB的7个TRN文件
- 每周重新索引事务日志备份:大约3GB
回答 2
Server Fault用户
发布于 2016-01-21 02:25:16
他们的备份策略不应该被你的观点所驱动，而应该由他们的恢复点目标和恢复时间目标驱动。与客户进行讨论，然后实施符合这些目标的备份策略。
尽管如此，如果您提到的数量和大小的数据库和事务日志的恢复花费了超过几分钟的时间，我会感到非常惊讶。肯定不会花上几个小时或几天。
Server Fault用户
发布于 2016-01-20 23:53:13
我最关心的实际上是事务日志备份。如果他们在预定的t日志备份前5分钟丢失数据库，那么他们可能会损失近24小时的数据。
更频繁的日志备份不应该占用那么大的空间--不会有更多的事务。它应该只允许一个更好的恢复点。
(不，在12.5GB数据库上运行还原不需要几天时间。)
在这种情况下，差异的主要优点是您可能开始发现日志备份文件的数量难以处理。如果他们每周运行一次的事务日志备份和每小时的事务日志备份，那就是一天24份文件。如果他们在上一次日志备份前5分钟和最后一次日志备份后55分钟就丢失了数据库，那么他们可能会损失55分钟，并且需要167次日志备份(我假设这些是不同的文件)。有了每晚的差数，他们只需要23个。
(如果他们认为55分钟损失太大，那么就更频繁地备份事务日志，并相应地乘以文件数量。)
https://serverfault.com/questions/750630
复制相似问题
腾讯云开发者
