当看这篇文章之前，请先给你的所有重要的库做一次完整 数据库备份

前言

为什么要备份？理由很简单——为了还原/恢复。当然，如果不备份，还可以通过磁盘恢复来找回丢失的文件，不过SQL Server很生气，后果很严重。到时候你就知道为什么先叫你备份一次再开始看文章了。∩__∩。本系列将介绍SQL Server所有可用的备份还原功能，并尽可能用实例说话。

什么是备份？SQL Server基于Windows，以文件形式存放资料，所以备份就是Windows上SQL Server相关文件的一个某个时间点的副本。根据备份类型的不同，副本的种类和内容也有不同。
备份类型有哪些？SQL Server 目前版本中，可用的备份类型有：完整数据库备份、差异数据库备份、事务日志备份（后称日志备份）、文件和文件组备份、部分备份，根据SQL Server版本不同，有些备份类型不支持，另外根据恢复模式的不同，某些备份类型也不支持。

什么是恢复模式？

很多人只把关注点放在备份上面，而没有在意恢复模式，其实所有的备份都应该从恢复模式作为切入点。恢复模式实际上是一个控制备份还原的行为的数据库级别选项。SQL Server 在当前所有发布版本中只有三种恢复模式：简单恢复模式（后面简称简单模式），大容量日志恢复模式（后面简称大容量模式），完整恢复模式（后称完整模式）。

本文从恢复模式开始，提醒一下，绝大部分的专业属于都会陆续解释，如果读者有不明白，可以继续往下看或者上网搜索：

简单模式，Simple recovery model：某些操作可以被最小日志化。这种模式下，不支持日志备份、时间点恢复和页恢复。且文件恢复功能仅限于次要数据文件中的只读文件。
大容量日志模式，Bulk-logged recovery model：和完整模式类似，有时候可以理解为完整模式于简单模式的过渡模式。这种模式对某些大容量操作进行最小日志化，支持完整备份中的备份还原策略，但是由于某些操作被最小日志化，所以不能保证时间点恢复。
完整模式，Full recovery model： 在这个模式下，所以操作都被完整记录下来，并且支持所有类型的备份还原策略。

默认情况下，新库会继承Model库的配置，包括恢复模式，也就是FULL模式。可以在创建或日常使用过程中修改，并且不需要重启服务。恢复模式最重要的区别在于对待日志的行为。

简单模式：

是三种模式中最容易管理的，可以进行完整，差异和文件备份，但是不能做日志备份。在这种模式下，每当Checkpoint 进程发生时，会自动把日志文件中不活动的日志（在日志备份一文介绍）写入数据文件，写入后，对应的日志文件中的空间就可供新事务使用，注意这种空间重用或者截断并不自动减少日志文件的物理大小，如果需要减少空间，需要使用DBCC SHRINKFILE/DATABASE等命令实现。让日志空间重用的过程叫做截断。在简单模式下这个过程称为自动截断(auto-truncate)。在这种模式下，日志通常不需要管理，但是对于单个的大事务，日志文件可能会增长得很快，这种情况下最好把批处理降为小的批。简单模式最主要的限制是不能进行日志备份，也就是说无法进行时间点还原。在一些测试，开发或者SLA要求不严格的环境下，可以使用这种模式。

完整模式：

这种模式下，所有数据库操作都被完整地记录在日志中，2008出现某些操作在这种模式下也还是最小化日志。并且不是自动截断。它支持任何备份还原策略，特别是时间点还原，在日志还原一章介绍。即使发生Checkpoint ，不活动的事务也不会截断到数据文件中。唯一能控制日志文件的只有日志备份，所以这种模式下日志备份极其重要，一方面提供时间点还原，另外一方面控制日志文件大小。

日志文件会完整保存自上一次日志备份后的事务。使用copy_only或者no_truncate选项均不会截断日志。

大容量日志：

这种模式是最少用到的，某些操作会被最小日志化，包含：

使用bcp进行导入
bulk insert
insert select *from openrowset(bulk )
select into
使用writetext/updatetext插入或附加数据
重建索引

在这种模式下，会用bitmap image记录发生最小日志化的区。如果数据库故障导致数据文件不了用，并且日志尾部包含最小化日志，不能做日志尾部备份，因为这个操作需要访问数据文件中数据修改后的区。这种模式适用于大容量操作，但是如果事务包含最小化日志，则不能进行时间点还原，只能还原到之前。

恢复模式扩展说明：

如上所说，恢复模式是数据库级别的配置项，在创建过程中及后续使用中均可修改，但是由于种种原因，尽量在规划阶段就做好配置，并且在创建过程中明确指定。

这个选项主要用于决定数据库是否可以（或者需要）做日志备份？什么事务需要被记录？还有是否可以做其他类型的备份还原操作等。

简单模式：

某些操作能被最小化日志，这里要说明一下，很多人以为简单模式下“不记录日志”，其实这是很严重的误解，会导致后续使用的很多问题，无论任何恢复模式，都会记录日志，只是记录的形式和内容不同。在简单模式下，日志备份选项被禁用，带来的影响是不支持时间点还原、页还原，而文件还原功能仅限于READONLY文件组中的次要数据文件。

简单模式是最容易管理的恢复模式，在这种模式下，可以进行完整数据库备份、差异数据库备份和文件备份，但是不能进行日志备份。在日志备份一文会详细介绍，但是在这里要提一下，关于日志空间重用的问题，不管任何恢复模式，都会有一个系统进程在后台运行——CHECKPOINT，每当这个进程启动时，会把数据库的日志文件（通常就是LDF文件）中，非活动的事务写入数据文件，然后把这部分的空间标识为“可重用”，这个步骤称为日志截断，在简单模式下称为自动截断（auto-truncate），记住可重用不代表空间被清空，唯一可以清空LDF文件物理大小的操作是收缩数据库/文件操作。简单模式会自动执行这个截断操作，截断后，日志空间可被新事物重新使用，从宏观变现来说，就是LDF文件的物理大小不增加，或者增加缓慢，其实当使用简单模式，并且LDF合适的情况下，如果LDF物理大小还在增长，可能就需要引起注意。

由于日志的自动截断，导致简单模式下无法进行时间点恢复，也无法进行日志备份。但是对于对数据要求不高的系统，或者SLA（在还原基础一文中介绍）没有什么特殊要求的环境，可以使用这种模式，可以最大限度减少对日志的管理。但是不是意味着使用了这种模式，就不用管理日志了，对于一些大规模、长时间运行的批处理，会引起大量的活动事务，此时LDF文件依旧会迅速增长，引起一些潜在的问题。对此，尽可能把批处理拆分为多个、短事务。

简单来说，这种模式的优缺点：

优点：

完整模式：

完整模式很多概念都是相对于简单模式来说的，这种模式下，所有操作被完整地记录在事务日志文件中，并且不会发生自动截断（除了数据库完全没做过最少一次完整备份），事务日志只有在事务日志备份发生时，才会截断到数据文件，并且使对应部分可用。这种模式能够执行所有类型的备份还原选项，特别是可以进行时间点恢复，保证数据接近0丢失。这是几乎所有正式环境（也称生产环境）使用的恢复模式。

优点：