无论是数据库Dev还是DBA，都希望关键业务数据库的完整性和可用性能得到保障，数据库备份是一种不错的选择。SQL Server 2008支持不同应用层次的多种备份方式，为我们的业务数据提供了强有力的保障，这一篇博文就来探讨如何在SQL Server 2008下设计合理的备份策略。
为了设计合理的备份策略，首先要熟悉SQL Server 2008都支持哪些恢复模式，它支持的恢复模式有如下：
翻译后如下：
简单恢复模式：
在简单恢复模式下，只支持完整备份和差异备份，不支持事务日志备份。在简单恢复模式下还原数据库时只能还原到上一次数据库备份的数据，而上一次数据库备份以后的数据将无法进行还原，在发生灾难时，这些上一次数据库备份以后的数据必须重做。所以简单恢复模式并不适用于生产系统。另外在简单恢复模式下，由于事务日志会被截断，所以日志文件不会一直膨胀，非常小。
完整恢复模式：
完整恢复模式是微软建议在生产环境中使用的恢复模式。在正常情况下（即能备份日志尾部）发生灾难进行还原数据库时，不会丢失任务数据。但是如果日志尾部损坏，则必须重做自上一次日志备份或差异备份等之后所做的更改。在完整恢复模式下，所有的操作都会在日志中完整地记录下来。
大容量日志恢复模式：
大容量日志恢复模式简单地记录了大多数大容量操作日志(如Bulk INSERT,CREATE INDEX,SELECT INTO等)，而不是记录全部大容量操作日志，所以这些大容量操作比在完整恢复模式下执行要快很多，同时大容量日志恢复模式完整记录了其他事务日志。所以大容量日志恢复模式是一种特殊用途的恢复模式，只应用于提高某些大规模大容量操作（如大量数据的大容量导入）的性能。完整恢复模式下有关备份的许多说明也适用于大容量日志恢复模式。
如果在最新日志备份后发生日志损坏或执行大容量日志记录操作，则必须重做自该上次备份之后所做的更改，否则不丢失任何数据。
另外设计合理的备份策略，还要熟悉SQL Server 2008都支持哪些备份类型，它支持的备份类型有如下：
翻译后如下：
完整数据库备份：
完整备份会备份数据库中的所有数据，以及可以恢复这些数据的足够的日志。它为差异、事务日志备份创建基准备份。在数据库底层上，完整备份实际上是把所有页(page)复制到备份设备上。
差异数据库备份：
差异备份仅备份自上次完整备份后发生更改的数据。通常，建立基准备份之后执行的差异备份比基准备份更小，创建速度也更快。因此，使用差异备份可以加快进行频繁备份的速度，从而降低数据丢失的风险。通常，一个差异基准会由若干个相继的差异备份使用。还原时，首先还原完整备份，然后再还原最后一个的差异备份。
业务数据库运行一段时间后，随着数据库的更新，包含在差异备份中的数据量会增加。这使得创建和还原差异备份的速度变慢。因此，必须重新创建一个完整备份，为另一个系列的差异备份提供新的差异基准。
业务数据库运行一段时间后，随着数据库的更新，包含在差异备份中的数据量会增加。这使得创建和还原差异备份的速度变慢。因此，必须重新创建一个完整备份，为另一个系列的差异备份提供新的差异基准。
同样，差异备份和完整备份类似，也会备份恢复数据的足够日志，这是由数据库系统控制的。
在数据库底层上，差异备份是备份自上次完整备份以后所有修改的区(extent)。
部分备份：
部分备份与完整数据库备份类似，但是部分备份不包含所有文件组。部分备份包含主文件组、每个读写文件组以及任何指定（可选）的只读文件中的所有数据。部分备份在希望不包括只读文件组时非常有用。只读数据库的部分备份仅包含主文件组。
部分备份功能从SQL Server 2005开始引入。
创建部分备份时，必须在BACKUP 语句中指定 READ_WRITE_FILEGROUPS 选项。也可以指定任何只读文件或文件组，以便将其包括在部分备份中。
事务日志备份：在完整恢复模式或大容量日志恢复模式下，需要定期进行事务日志备份。每个日志备份都包括创建备份时处于活动状态的部分事务日志，以及先前日志备份中未备份的所有日志记录。在创建第一个事务日志备份之前，必须先创建完整备份(如完整数据库备份或一组文件备份中的第一个完整备份)。此后，必须定期备份事务日志。这不仅能最小化工作丢失风险，还有助于事务日志的截断。通常，事务日志在每次常规日志备份之后截断。
连续的日志备份序列称为“日志链”。日志链从数据库的完整备份开始。通常，仅当第一次完整备份数据库时或者将恢复模式从简单恢复模式切换到完整恢复模式或大容量日志恢复模式之后，才会开始一个新的日志链。在完整恢复模式下（或者在大容量日志恢复模式下的某些时候），连续不断的日志链可以将数据库还原到任意时间点。
若要将数据库还原到故障点，必须保证日志链是完整的。也就是说，事务日志备份的连续序列必须能够延续到故障点。此日志序列的开始位置取决于所还原的数据备份类型：数据库备份(包括完整或差异备份)、部分备份或文件备份。对于数据库备份或部分备份，日志备份序列必须从数据库备份或部分备份的结尾处开始延续。对于一组文件备份，日志备份序列必须从整组文件备份的开头开始延续。
如果日志备份丢失或损坏，则可通过创建完整数据库备份或差异数据库备份并随后备份事务日志来开始一个新的日志链。如果要将数据库还原到事务日志备份内的某个时点，则建议保留丢失的日志备份之前的事务日志备份。
尾日志备份：
在完整恢复模式或大容量日志恢复模式下数据库发生灾难时，SQL Server 2005或2008可以备份日志结尾以捕获尚未备份的活动日志记录，把还原数据库操作之前对日志尾部执行的日志备份称为尾日志备份。
所以这里面有一点特别重要，在完整恢复模式或大容量日志恢复模式下一旦数据库发生灾难，还原数据库时，进行的第一步操作是尾日志备份(如果尾日志能备份的话)，这样才不会丢失自上一次日志备份(也可能是完整或差异备份，主要是看用什么备份策略)后的数据。如果日志文件受损且无法创建结尾日志备份，则必须在不使用结尾日志备份的情况下还原数据库。最新日志备份(也可能是完整或差异备份，主要是看用什么备份策略)后提交的任何事务都将丢失。
文件和文件组备份：
针对大型数据库和性能要求使完整数据库备份显得不切实际时，则可以创建文件备份。文件备份包含一个或多个文件（或文件组）中的所有数据。文件备份包括完整文件备份和差异文件备份。针对大型数据库可以分别备份和还原数据库中的文件，而且可以仅还原已损坏的文件，而不必还原数据库的其他部分。
差异文件备份为创建当前文件备份提供了一种快速并且节省空间的方式。在简单恢复模式下，仅为只读文件组启用了差异文件备份。在完整恢复模式下，允许对具有差异基准的任何文件组进行差异文件备份。
文件和文件组备份增加了备份和还原的复杂度。
Copy_only备份：
仅复制备份可以在不打断正常备份序列的情况下复制数据库的内容，这个功能从SQL Server 2005开始引入。事务日志从不在仅复制备份后出现截断，这对平时DEV或DBA仅想获得一份完整的数据库用于测试工作，而又不影响当前的备份序列非常方便。
设计一个数据库的最佳备份策略，会面临如何选择使用哪种恢复模式的问题，因为恢复模式控制着备份和还原的行为。一般来讲，简单恢复模式一般适合用于测试或开发数据库。对于生产数据库，最佳选择通常是完整恢复模式，还可以选择大容量日志恢复模式作为补充。但简单恢复模式有时也适合小型生产数据库（尤其是当其大部分或完全为只读时）或数据仓库使用。
若要为特定数据库确定最佳恢复模式，应考虑数据库的恢复目标和要求，数据使用方式，员工因素以及是否可对日志备份进行管理等。
恢复目标要求 ：
l 不丢失任何更改的重要程度如何？
l 重新创建丢失的数据的难易程度如何？
l 是否有两个或两个以上的数据库在逻辑上必须保持一致？
员工因素 ：
是否雇用系统或数据库管理员？如果没有，那么由谁负责执行备份和恢复操作，如何对他们进行培训？
数据使用方式，针对当前数据库考虑下列问题：
l 数据库中的数据多长时间更改一次？
l 是否有些表明显比其他表修改频繁？
l 是否有关键生产周期？如果有，那么在这些周期中的使用方式是怎样的？数据库是否会经历插入操作和其他更新操作的高峰期？
可能需要计划在非高峰期进行数据备份。当大量使用 I/O 系统时，通常只需使用日志备份。
可能需要计划在非高峰期进行数据备份。当大量使用 I/O 系统时，通常只需使用日志备份。
l 数据库是否会遇到可能无法立即检测到的危险更新或应用程序错误？
如果数据库会遇到这些情况，请考虑使用完整恢复模式。这可以使用日志备份将数据库恢复到特定时间点。
如果数据库会遇到这些情况，请考虑使用完整恢复模式。这可以使用日志备份将数据库恢复到特定时间点。
何时使用简单恢复模式？
如果符合下列所有要求，则使用简单恢复模式：
l 不需要故障点恢复。如果数据库丢失或损坏，则会丢失自上一次备份到故障发生之间的所有更新，但你愿意接受这个损失。
l 愿意承担丢失日志中某些数据的风险。
l 不希望备份和还原事务日志，希望只依靠完整备份和差异备份。
何时使用完整恢复模式？
如果符合下列任一要求，则使用完整恢复模式（还可以选择使用大容量日志恢复模式）：
l 必须能够恢复所有数据。
l 必须能够恢复到故障点。
l 希望可以还原单个页。
l 愿意承担事务日志备份的管理开销。
l 数据库包含多个文件组，并且希望逐段还原读/写辅助文件组（以及可选地还原只读文件组）。
何时使用大容量日志恢复模式？
大容量日志恢复模式作为完整恢复模式的附加补充。建议仅在运行大规模大容量操作期间以及在不需要数据库的时间点恢复时使用该模式。
l 数据库是否会发生周期性的数据库大容量操作？
在该恢复模式下，多数大容量操作仅进行最小日志记录。如果使用完整恢复模式，则可以在执行此类大容量操作前临时切换到大容量日志恢复模式。通常，大容量日志恢复模式与完整恢复模式相似，只是它按最小方式记录多数大容量操作。大容量日志恢复模式仅适合在能够以最小方式记录操作的大容量操作期间使用。建议在其余时间使用完整恢复模式。当完成一组大容量操作后，建议立即切换回完整恢复模式。
在该恢复模式下，多数大容量操作仅进行最小日志记录。如果使用完整恢复模式，则可以在执行此类大容量操作前临时切换到大容量日志恢复模式。通常，大容量日志恢复模式与完整恢复模式相似，只是它按最小方式记录多数大容量操作。大容量日志恢复模式仅适合在能够以最小方式记录操作的大容量操作期间使用。建议在其余时间使用完整恢复模式。当完成一组大容量操作后，建议立即切换回完整恢复模式。
下面就以简单恢复模式和完整恢复模式来设计几个备份策略。
一，简单恢复模式下的备份策略设计：
1， 仅完整数据库备份策略
这种策略仅适用于经常备份的小型数据库，数据丢失风险比较大。
此策略仅使用包含数据库中所有数据的完整数据库备份。例如下图完成5个完整数据库备份后发生灾难，只需要还原最近的备份（在 t5 时点执行的备份）。还原此备份会将数据库恢复到 t5 时点。由t6 框表示的所有后续更新都将丢失。
在这种策略下为了最大程度降低数据丢失的风险，可以增加备份次数和缩短备份间隔，如下图：
2，完整数据库备份+差异数据库备份策略
这种策略比只使用仅完整数据库备份策略，减少了数据丢失风险。例如下图在第一个完整数据库备份完成后，会接着进行三个差异数据库备份。随着时间推移，第三个差异备份已经足够大，因而下一个备份重新使用完整数据库备份。该数据库备份将成为新的差异基准。
在这种备份策略下，如果在t4时进行“差异数据库备份3”完成后而t5时的“完整数据库备份2”还没进行的情况下发生灾难，只需要先还原t1时的“完整数据库备份1”，接着还原最后一次即t4时的“差异数据库备份3”就可以恢复数据库，但是t4以后的数据会丢失。
二，完整恢复模式下的备份策略设计：
1， 完整数据库备份+日志备份策略
例如下图已完成了完整数据库备份 Db_1 以及两个日志备份 Log_1 和 Log_2。在 Log_2 日志备份后的某个时间，数据库出现数据丢失或灾难。在还原这三个备份前，必须备份活动日志（日志尾部，如果能备份的话）。然后依次还原 Db_1、Log_1 和 Log_2，而不恢复数据库（还原时必须使用norecovery选项），接着还原并恢复结尾日志备份 (还原时必须使用recovery选项)。这将把数据库恢复到故障点，从而恢复所有数据。
2， 完整数据库备份+差异数据库备份策略
例如下图在第一个数据库备份完成后，会接着进行三个差异数据库备份。随着时间推移，第三个差异备份已经足够大，因而下一个备份重新使用完整数据库备份。该数据库备份将成为新的差异基准。
在这种备份策略下，如果在t10时进行“差异数据库备份3”完成后而t13时的“完整数据库备份2”还没进行的情况下发生灾难，还原时，必须先备份活动日志（日志尾部，如果能备份的话）。然后依次还原t10时的“完整数据库备份1”，最后一次即t4时的“差异数据库备份3”（还原时必须使用norecovery选项），接着还原并恢复结尾日志备份 (还原时必须使用recovery选项)。这将把数据库恢复到故障点，从而恢复所有数据。
3， 完整数据库备份+差异数据库备份+日志备份策略
这种备份策略可以最大程度地降低数据丢失的风险，也是比较推荐的备份策略！
例如下图从t1到t12时间段内，进行了一次完整数据库备份，若干日志备份，三个差异数据库备份。
在这种备份策略下，当t12时的日志备份完成后数据丢失或发生灾难，如何还原数据库呢？步骤如下：
第一步：备份活动日志（日志尾部，如果能备份的话）
第二步：还原t1时的“完整数据库备份1”
第三步：还原t10时的“差异数据库备份3”
第四步：还原t11时的日志备份
第五步：还原t12时的日志备份
第六步：还原第一步的“尾日志备份”
其中第二，三，四，五步还原时必须用norecovery选项，第六步用recovery选项。
根据业务系统级别的不同，一般可以一周进行一次完整数据库备份，一天进行一次差异数据库备份，30分钟或1小时进行一次日志备份。