SQL Server提供的几种备份类型

    SQL Server所提供的几种备份类型基本可以分为以下三种（文件和文件组备份以及部分备份不在本文讨论之列):

    1.完整(Full)备份:直接将所备份的数据的所有区(Extent)进行复制。这里值得注意的有2点:

•     完整备份并不像其名字“完整”那样备份所有部分，而是仅备份数据库本身，而不备份日志(虽然仅仅备份少量日志用于同步）

•     完整备份在备份期间，数据库是可用的。完整备份会记录开始备份时的MinLSN号，结束备份时的LSN号，将这个区间的日志进行备份，在恢复时应用到被恢复的数据库(这里经过修改，感谢魔君六道指出)

    2.差异(Differential)备份:只备份上次完整备份后，做修改的部分。备份单位是区(Extent)。意味着某个区内即使只有一页做了变动，则在差异备份里会被体现.差异备份依靠一个BitMap进行维护，一个Bit对应一个区，自上次完整备份后，被修改的区会被置为1，而BitMap中被置为1对应的区会被差异备份所备份。而到下一次完整备份后，BitMap中所有的Bit都会被重置为0。

    3.日志(Log)备份:仅仅备份自上次完整备份或日志备份之后的记录。在简单模式下，日志备份毫无意义(SQL Server不允许在简单恢复模式下备份日志)，下文会说明在简单恢复模式下，为什么日志备份没有意义。

简单恢复模式(Simple Recovery Mode)

    在简单恢复模式下，日志仅仅是为了保证SQL Server事务的ACID。并没有恢复数据的功能.

　 但操作仍然会使用WAL，直到check point与lazy write.

    比如，我们有一个备份计划，如下:

    我们在每周一0点做一次完整备份，在周三0点和周五0点分别做差异备份。在简单恢复模式下，如果周六数据库崩溃。我们的恢复计划只有根据周一0点的做的完整备份恢复后，再利用周五0点的差异备份进行恢复.而周五0点之后到服务器崩溃期间所有的数据将会丢失。

    正如”简单”这个词所涵盖的意思，在简单恢复模式下，日志可以完全不用管理。而备份和恢复完全依赖于我们自己的完整和差异备份.

    恢复模式是一个数据库级别的参数，可以通过在SSMS里或通过SQL语句进行配置:

完整(Full)恢复模式

    完整恢复模式通过将对数据库的任何修改记录到日志来给予数据最大程度的保护。在完整恢复模式下，日志的作用不仅仅是保证了数据库事务的ACID。并且还可以使数据恢复到在日志范围内的任何时间点。

    在上一篇文章中说过，在简单恢复模式下，日志几乎是不用进行管理的。每一次CheckPoint都有可能截断日志，从而来回收不活动的VLF以便重复利用空间。因此在简单恢复模式下，日志的空间使用几乎可以不去考虑。与之相反，在完整恢复模式下，日志作为恢复数据的重要组成部分，日志的管理和对日志空间使用的管理则需要重视。

    在完整恢复模式下，CheckPoint不会截断日志。只有对日志的备份才会将MinLSN向后推并截断日志。因此在一个业务量稍大的系统中，日志的增长速度将会变得很快。

    因此日志备份的目的分为以下两个:

•     减少活动日志的大小

•     减少日志损坏的风险

    通过从MSDN中摘自的下图可以看到:

     在DB_1处做了完整备份，并且接下来两次分别做了两次日志备份(Log_1和Log_2),在Log_2备份完不久服务器由于数据所在磁盘损坏。这时如果日志文件完好，则可以通过备份尾部日志(Tail of log)后，从DB_1开始恢复，依次恢复Log_1,Log_2,尾部日志来将数据库恢复到灾难发生时的时间点。理论上可以使数据的损失为0。

     从日志恢复数据的原理是Redo,也就是将日志中记载的事务再重做一遍。这个开销和从完整或差异备份中恢复相比，要大很多。因此尽可能的减少利用日志的恢复量。而使用完整或者差异备份来恢复更多的数据。

大容量日志(Bulk-logged)恢复模式

      大容量恢复模式在很多地方和完整恢复模式相同。但由于在完整恢复模式下，对数据库的每一项操作都会记录在日志中。而对于某些大量数据的导入导出操作，无疑会在日志中留下大量记录。很多情况下，我们并不需要将这些信息记录在日志中。

     而大容量日志恢复模式作为完整恢复模式的备选方案。微软推荐的最佳实践是在进行大量数据操作时(比如索引的创建和rebuilt,select into操作等)，暂时由完整恢复模式切换到大容量恢复模式来节省日志。这个转换并不会破坏日志链。

     本文不会深入探讨这个模式，仅仅是对这个概念做简单解释。假设我要插入一批数据，则完整恢复模式和大容量日志恢复模式在日志中所记录的信息如下:

     由此可以看出，在日志中，大容量恢复模式将这类操作变为一个原子。

切换恢复模式时应该采取的措施

介质集、介质簇和备份集 (SQL Server) 

　　包含一个或多个备份介质的集合的备份构成一个介质集。 “介质集”是“备份介质”（磁带或磁盘文件，或者是 Windows Azure Blob）的有序集合，使用固定类型和数量的备份设备向其写入一个或多个备份操作。 给定介质集使用磁带机，或者使用磁盘驱动器或 Windows Azure Blob，但不能结合使用两者或以上。 例如，与介质集关联的备份设备可能是三个名为 \\.\TAPE0、\\.\TAPE1 和 \\.\TAPE2 的磁带机。 该介质集仅包含磁带，最少需要三个磁带（每个磁带机一个磁带）。 备份设备的类型和数量是在创建介质集时建立的，不能更改。 但是，如有必要，可以在备份和还原操作之间将给定设备替换为同一类型的设备。

　　介质集是在备份操作过程中通过格式化备份介质从而在备份介质上创建的。 有关详细信息，请参阅本主题后面的创建新介质集。 设置格式后，每个文件或磁带都包含介质集的介质标头，可以开始接收备份内容。 有了标头后，备份操作会将指定数据备份到为该操作指定的所有备份设备中的备份介质。

1、介质集是备份介质（磁盘或磁带）的有序集合，任何多个备份只要在一定基础上，都可设置成一个介质集；因此一个介质集可包含多个介质簇。一个介质集可包含多个备份集。默认情况下，一个备份名称为一个介质集

2、介质簇为介质集中的单个非镜像设备或一组镜像设备上创建的备份，介质簇的数量与备份名称一一对应，介质簇的数量决定于备份设备的数量。因此若有多个镜像设备的时候，可以将备份分成多份存放在不同的镜像设备中。

3、每执行一个备份操作就会有一个备份集，一个备份集包含多个文件。

4、备份行为包括覆盖和非覆盖，由此建议日常自动化备份采用覆盖形式备份，以防止磁盘不足。

5、同类型备份（如完整备份）且同一个语句执行多次，会往同一个介质簇中追加[noinit]或覆盖[init]数据。若是不同类型备份同一个语句执行只会往介质簇中追加数据，不会覆盖。

6、每个备份介质集的开始以初始化介质标头为开始，新的介质集以新的介质标头为标志。若无新的介质标头，则说明此备份要么覆盖原有备份集，要么追加到原有备份集。