事务日志备份策略。尾备份还是标准日志备份？

Question

我们被迫在我们的生产环境中进行一些必要的维护。供应商的指示说明数据库的恢复模型在进行工作之前应该设置为SIMPLE。

我对此很满意，企业已经批准了这一改变，但我正在努力寻找灾难恢复计划方面最好的前进之道。

如果需要，我希望确保数据库可以恢复到更改恢复模型的程度。

我们每晚午夜进行完整的数据库备份，并在凌晨4点至晚上9点(操作时间)每小时记录一次备份。

这项工作将在上午9点开始，就在预定的日志备份之后，但当然，基于各种因素，我已经准备好滑到那个小时了。我想确保我们有一个日志备份可以覆盖，比方说，上午9点到9点20分

编辑:用户在上午9点左右被锁在系统之外，但是我不能仅仅依靠最后一次日志备份，因为可能会有事务滑过9点，需要恢复。这取决于管理层何时按下按钮..。

什么是最好的行动方针？

我应该只是采取一个临时事务日志备份，如果需要的话，可以在最新的完全备份和日志备份序列之后应用吗？

或者我应该考虑使用尾日志备份，尽管我可能永远不会使用它。

Answer 1

真正的问题是，您需要知道应用程序何时关闭，并且用户不在数据库。如果知道“何时管理按下按钮”存在通信问题，那么也许可以监视sys.dm_exec_sessions和/或sys.dm_exec_requests，以确定何时用户流量减少。一旦您看到用户不再活跃在系统中，您就可以进行最后的日志备份，然后将数据库切换为简单的恢复。

如果您使用尾日志备份(例如，BACKUP LOG...WITH NORECOVERY)，当DB切换到恢复状态时，您将把用户踢出数据库。但是，您仍然需要恢复数据库，以便可以将其更改为简单并运行升级。当您恢复数据库时，如果用户仍然在应用程序中，您将有同样的可能性丢失事务。

一旦您知道所有用户都不在数据库中，一个简单的事务日志备份就足以捕获所有事务。

此外，即使数据库处于简单恢复模式，也可以对数据库进行差异备份。差异备份不会提供与日志备份相同的实时恢复，但是如果您确实在寻找“在我开始维护之前”的恢复点，那么使用差异可能是您的最佳选择。这一选择有两个主要好处：

1. 它实现了一个简单的恢复点的目标，该还原点包括对数据库的所有更改，直到维护之前的某个点。
2. 恢复到该还原点只需要还原完整+差异备份。与full +N日志相比，这可能会减少恢复所需的时间和精力。

与进行最后一次日志备份相比，此差异将花费更长的时间来运行，并且需要在备份共享上占用更多的磁盘空间。准确的时间和空间将根据上次完全备份后数据变化的多少而变化，因此您需要自己评估。

有关来自Microsoft的差异备份的其他信息：https://technet.microsoft.com/en-us/library/ms191180(v=sql.105).aspx

Answer 2

最安全的办法是：

1. 停止应用程序，确保所有用户断开连接，并对数据库进行tail_of_the_log备份。
2. 将恢复模型更改为简单
3. 升级
4. 将恢复模型更改为满并执行新的完全备份

如果这是不可能的，您可以通过进行差异备份来覆盖数据库处于简单恢复模式的时间。

1. 进行日志备份
2. 将数据库放到简单的恢复中
3. 升级
4. 当数据库回到完全恢复模式时，进行差异备份，然后再次启动日志备份。

这将意味着您可以恢复到升级之前的时间点(最后一次完全备份和日志备份直到最后一次备份)，如果您恢复了最后一次完全备份和数据库后所做的差异，则可以恢复到完整恢复模型和之后进行的任何日志备份。

最后，最好的解决方案是:安排您的日志备份在升级期间每10-15分钟运行一次，不要将恢复模型更改为简单。