SQL Server 灾难恢复之制定备份策略

SQL Server 灾难恢复之制定备份策略

创建备份策略：

咱们前面详细学习了各种恢复模式和备份类型，下面咱们就继续来讨论一下如何针对不同的需求设计出最佳的备份策略。这首先要面临的决定数据库使用何种恢复模式。恢复模式旨在控制事务日志维护。有三种恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式。通常，数据库使用完整恢复模式或简单恢复模式。一般来说如果是测试或者是小型生产用数据库则会使用简单恢复模式，而完整恢复模式而应用于生产数据库，当然也可以选择使用大容量日志恢复模式作为互补。然后制定最佳的数据库备份策略还要考虑到数据库的数据恢复目标要求，数据的使用方式，是否对事务日志进行管理以及管理人员。

恢复目标要求：

能够承受的数据丢失程度

重建丢失数据的成本

是否有高可用性要求，如群集、镜像等

数据使用方式：

该数据库中的数据多长时间更改一次

是否有某些表修改过于频繁

数据库的使用高峰期以及在此高峰期的操作

简单恢复模式场合：

不需要支持时间点的恢复。用户能够承受数据库自上一次备份到故障发生之间的数据丢失。不需要用到日志备份，只使用到完整备份和差异备份。

完整恢复模式场合：支持时间点的还原，能够恢复所有数据，支持事务日志备份，支持文件组备份。但会增加相应的日志备份的管理成本。

大容量日志恢复模式场合：一般使用在大规模大容量操作期间以及在不需要数据库的时间点还原时使用此模式。多数大容量操作仅进行最小的日志记录。如果使用完整模式，可以在此切换到大容量日志恢复模式，以减少日志记录空间。当完成操作后可以切换到完整恢复模式。

总结：

下表概述了这些恢复模式。

恢复模式

说明

工作丢失的风险

能否恢复到时点？

简单

无日志备份。

自动回收日志空间以减少空间需求，实际上不再需要管理事务日志空间。

最新备份之后的更改不受保护。在发生灾难时，这些更改必须重做。

只能恢复到备份的结尾。

完整

需要日志备份。

数据文件丢失或损坏不会导致丢失工作。

可以恢复到任意时点（例如应用程序或用户错误之前）。

正常情况下没有。

如果日志尾部损坏，则必须重做自最新日志备份之后所做的更改。

如果备份在接近特定的时点完成，则可以恢复到该时点。

大容量日志

需要日志备份。

是完整恢复模式的附加模式，允许执行高性能的大容量复制操作。

通过使用最小方式记录大多数大容量操作，减少日志空间使用量。

如果在最新日志备份后发生日志损坏或执行大容量日志记录操作，则必须重做自该上次备份之后所做的更改。

否则不丢失任何工作。

可以恢复到任何备份的结尾。不支持时点恢复。

设计实例：

简单恢复模式下的备份策略

1. 仅使用完整数据库备份策略

这种策略仅适用于经常备份的小型数据库，数据丢失风险比较大。如果发生数据丢失，则只能还原到最近的备份。下图显示了简单恢复模式下最简单的备份与还原策略。此策略仅使用包含数据库中所有数据的完整数据库备份。存在五个完整数据库备份，但只需要还原最近的备份（在 t5 时点执行的备份）。还原此备份会将数据库恢复到 t5 时点。由 t6 框表示的所有后续更新都将丢失。

在简单恢复模式下，在执行下次完整备份或差异备份前，所做工作丢失的风险会随时间的推移而增加。与完整备份不同的是，差异备份仅包括自上次完整备份以来所做的更改。因此，我们建议您在不影响备份管理的前提下时常备份，以免丢失大量数据。

下图显示了仅使用数据库备份的备份计划的工作丢失风险。此策略仅适用于可经常备份的小型数据库。

2  完整备份+差异备份策略

下图显示的备份策略通过使用差异数据库备份对数据库备份进行补充，从而减少了工作丢失风险。在第一个数据库备份完成后，会接着进行三个差异数据库备份。第三个差异备份足够大，因而下一个备份为完整数据库备份。该数据库备份将成为新的差异基准。

完整恢复模式下的备份策略

完整恢复模式使用日志备份在最大范围内防止出现故障时丢失数据，这种模式需要备份和还原事务日志（“日志备份”）。使用日志备份的优点是允许您将数据库还原到日志备份内包含的任何时点（“时点恢复”）。假定可以在发生严重故障后备份活动日志，则可将数据库一直还原到没有发生数据丢失的故障点处。使用日志备份的缺点是它们需要使用存储空间并会增加还原时间和复杂性。

对于定期使用完整恢复模式的数据库，可以通过暂时使用大容量日志恢复模式来优化某些大容量操作。大容量日志恢复模式会带来多种限制，因此不适合用于日常使用。

1． 完整数据库备份+日志备份策略

下图显示了在完整恢复模式下的最简单的备份策略。在此图中，已完成了完整数据库备份 Db_1 以及两个例行日志备份 Log_1 和 Log_2。在 Log_2 日志备份后的某个时间，数据库出现数据丢失。在还原这三个备份前，数据库管理员必须备份活动日志（日志尾部）。然后还原 Db_1、Log_1 和 Log_2，而不恢复数据库。接着数据库管理员还原并恢复结尾日志备份 (Tail)。这将把数据库恢复到故障点，从而恢复所有数据。

2． 完整数据库备份+差异数据库备份策略

例如下图在第一个数据库备份完成后，会接着进行三个差异数据库备份。随着时间推移，第三个差异备份已经足够大，因而下一个备份重新使用完整数据库备份。该数据库备份将成为新的差异基准。

在这种备份策略下，如果在t10时进行“差异数据库备份3”完成后而t13时的“完整数据库备份2”还没进行的情况下发生灾难，还原时，必须先备份活动日志（日志尾部，如果能备份的话）。然后依次还原t10时的“完整数据库备份1”，最后一次即t4时的“差异数据库备份3”（还原时必须使用norecovery选项），接着还原并恢复结尾日志备份 (还原时必须使用recovery选项)。这将把数据库恢复到故障点，从而恢复所有数据。

3． 完整数据库备份+差异数据库备份+日志备份策略

此策略是一般数据库推荐使用的备份策略，可以最大程度地降低数据丢失的风险。

下图显示的备份策略使用差异数据库备份及一系列例行日志备份来补充完整数据库备份。使用事务日志备份可缩短潜在的工作丢失风险的存在时间，使该风险仅在最新日志备份之后存在。在第一个数据库备份完成后，会接着进行三个差异数据库备份。第三个差异备份很大，足以使下一个备份成为完整数据库备份。该数据库备份将成为新的差异基准。

在此图中的第一个数据库备份创建之前，数据库存在潜在的工作丢失风险（从时间 t0 到时间 t1）。该备份建立之后，例行日志备份将工作丢失的风险降为丢失自最近日志备份之后所做的更改（在此图中，最近备份的时间为 t14）。如果发生工作丢失，则数据库管理员应该立即尝试备份活动日志（日志尾部）。如果此“结尾日志备份”成功，则数据库可以还原到故障点。

如果此时，T14当天的日志备份完成后数据发生了丢失应该如果还原数据库？

第一步：备份活动日志（日志尾部，如果能备份的话）

第二步：还原t13时的“完整数据库备份2”

第三步：还原t14时的“日志备份”

第四步：还原第一步的“尾日志备份”

其中第二，三步还原时必须用norecovery选项，第四步用recovery选项。

如果是下图的备份方式，

在这种备份策略下，当t12时的日志备份完成后数据丢失或发生灾难，如何还原数据库呢？步骤如下：

第一步：备份活动日志（日志尾部，如果能备份的话）

第二步：还原t1时的“完整数据库备份1”

第三步：还原t10时的“差异数据库备份3”

第四步：还原t11时的日志备份

第五步：还原t12时的日志备份

第六步：还原第一步的“尾日志备份”

其中第二，三，四，五步还原时必须用norecovery选项，第六步用recovery选项。

根据业务系统级别的不同，一般可以一周进行一次完整数据库备份，一天进行一次差异数据库备份，30分钟或1小时进行一次日志备份。