数据备份一直被认为数据库的生命，也就是一个DBA所要掌握的主要技能之一，本篇就是介绍SQL Server备份原则，SQL Server数据库分为数据文件和日志文件。为了使得数据库能够恢复一致点，备份不仅需要拷贝数据数据文件里的内容，还要拷贝日志文件里的内容。那么根据每次备份的目标不同，我们可以将备份分为数据备份和日志备份。

数据备份的范围可以是完整的数据库、部分数据库、一组文件或文件组。所以根据备份下来的数据文件的范围，又分为了完整数据库备份、文件备份和部分备份。

完整数据库备份

完整数据库备份就是拷贝下数据库里的所有信息，通过一个单个完整备份，就能将数据库恢复到某个时间的状态。但是由于数据库备份是一个在线的操作。一个大的完整数据库备份可能需要一个小时甚至更长的时间。数据库在这段时间里还会发生变化。所以完整数据库备份还要对部分事务日志进行备份，以便能够恢复数据库到一个事务一致的状态。

完整数据库备份易于使用。它包含数据库中的所有数据。对于可以快速备份的小数据而言，最佳方法就是使用完整数据库备份。但是，随着数据库的不断增大，完整备份需要花费更多时间才能完整，并且需要更多的存储空间。仅做完整备份可能不能满足用户需求。

文件备份

文件备份指的备份一个或多个文件或文件组中的所有数据。在完整恢复模式下，一整套完整文件备份加上跨所有文件备份的日志备份合起来等同于完整数据库备份。使用文件备份能够只还原损坏的文件，而不用还原数据库其余的部分，从而可加速恢复速度。例如，如果数据库由位于不同磁盘上的若干个文件组成，在其中一个磁盘发生故障时，只需要还原这个故障磁盘上的文件的备份，其它磁盘上的文件无须还原。这样会缩短还原时间。

部分备份

部分备份是SQL Server2005中的新增功能。部分备份与完整数据库备份类似，但是部分备份默认只包含数据库可读写的部分，数据库的只读文件将不会备份。因为只读部分是不会发生变动的。总是去备份它有点浪费。所以部分备份在希望备份不包括只读文件组时非常有用。

部分备份可以说是数据库部分和文件备份之间的一个中间类型。如果一个数据库里没有只读文件，那么部分备份和数据库备份就没有什么差别。

数据库文件常常是非常巨大的。在流行数据集中的趋势下，库容上TB的数据库现在已经屡见不鲜。对于这样的一个数据库，做数据库备份，哪怕是文件备份都是一个非常昂贵的事情，可能不是每天能去做的。再这样的背景之下就出现了：差异备份。

从是否拷贝所有的数据来分，数据备份有可以分为完整备份和差异备份。

差异备份基于差异，备份要求数据库之前做过一次完整备份。差异备份仅捕获自该次完整备份后发生更改的数据。这个完整备份被称为差异备份的”基准“。差异备份仅包括差异基准后更改的数据。差异备份比差异基准更小且更快，便于执行频繁备份，从而降低了数据丢失的风险。

对于完整数据库备份、文件备份和部分备份这3种数据备份形式，SQL Server都能够做完整备份和差异备份。所以，引出了一共6种数据备份模式：完整数据库备份、完整文件备份和完整部分备份，差异数据库备份、差异文件备份和差异部分备份。

数据备份集中精力数据文件的备份。对于日志文件，相应地有事务日志备份。每个日志备份都包括创建备份时处于活动状态的部分事务日志，以及先前日志备份中未备份的所有日志记录。不间断的日志备份序列包含数据库的备份（即连续不断的）日志链。在完整恢复模式下（或者在大容量日志恢复模式下的某些时候），连续不断的日志链让您可以将数据库还原到任意时间点。

SQL Server2005以后，还增添了一类新的备份模式，即仅复制备份。”仅复制备份“是独立于常规SQL备份序列的SQL Server备份。通常，进行备份会更改数据库并影响其后备份的还原序列。但是，有时在不影响数据库全部备份和还原过程的情况下，为了特殊目的而进行的备份还是有用的。为此，SQL Server2005引入了下列两种仅复制备份：

1、仅复制完整备份

仅复制完整备份也备份整个数据库内容。它和正常的完整备份的区别是，做完了以后差异备份基准不会改变，因此不影响差异备份序列。

2、仅复制日志备份

仅复制日志备份只备份当前日志文件里的现有内容，但是不会截断日志，因此，下次在做正常日志备份的时候，这些内容还原被再次备份下来，从而不影响常规日志备份的序列。这种备份主要用在数据库上已经有了一个备份计划任务在运行，但是现在需要做一个日志备份，同时不影响到原有的备份序列。

以上两种方法SSMS不支持图形化操作，只需要在备份语句后面加上copy only选项

现在总结SQL Server的11种主要备份方法

备份的方式很多种，其实我们经常用的就几种重要的方式。

首先，仅复制备份这类方法的出现，是为了方式将要做的备份破坏现有的备份策略而生的，例如，对于一个已经建立了严格备份规则（例如 Log Shipping）的数据库，现在需要做一个日志备份到另一个文件夹里。普通的日志备份会破坏现有备份文件系统所维护的日志链。仅复制备份就不会被破坏。所有这种方法仅仅在偶尔的特殊情况下去使用。不在指定备份策略的一开始考虑。

其次，在现实中，很少有数据库专门维护一个只读的文件或文件集。（这种方法维护成本较高，只会在非常巨大的数据库上才能体现出优势。）所以部分备份也是很少用到的。

这样上面的备份方式就可以简化成几个比较传统，也是最常用的备份方式

 当然除此之外，还存在一种暴力的备份方式那就是直接拷贝数据库文件，然后用文件附加（Attach）的方式备份和恢复数据库，这种方式在应对事例瘫痪掉的时候，万般无奈之极是可以尝试采取的，但是这种方式不作为标准的方式推荐。

不推荐的原因有以下几个：

1、SQL Server在运行的时候，对文件施加了排它锁，通过一般的方法是不能直接拷贝文件的。除非通过一些备份软件，否则只能停掉SQL Server服务，或者关闭数据库，才能备份文件。

2、SQL Server在理论上，只保证通过运行sp_detach_db语句得到数据库文件，才一定能被成功附加上。如果用户是通过暂停SQL Server服务或其它方法得到文件，SQL Server不能保证就一定能附加上。

3、有些用户只拷贝数据文件，不拷贝日志文件的做法，是非常不规范的。很容易导致数据库不能正常恢复。从而丢失数据。

拷贝文件的方法也不是一定能用，笔者在做灾难恢复的时候，如果数据库不是很大，会先做一个数据库备份，在做一个文件级的备份，以期双保险。文件拷贝发生在SQL Server被成功关闭之后，或者sp_detach_db后，而且所有的文件都要做备份，包括日志文件。

如何选择备份策略和恢复模式

SQL Server提供了足够多的技术来做各种各样的数据库备份。作为一个数据库管理员，应该选择何种备份方式，需要根据两个问题来抉择：

1、数据库最多能容忍多长时间的数据丢失？

2、准备投入多少人力物力来做数据库备份与恢复策略？

其实是这样，要想获得最好的效果，就需要越多的投入。数据库备份策略尤其这样。不考虑镜像技术（包括SQL Server自己的数据库镜像和物理磁盘级镜像），SQL Server不可能时时刻刻的做数据库备份，每次备份之间总要有一定的时间间隔。而这个时间间隔之间的数据变化在下一次备份之前，是没有保护的。所以讲到底，数据丢失的最大时间段，就是这两次备份之间的时间间隔。利用备份数据恢复机制保护数据，是不可能保证数据一点都不丢失的。如果用户提出来要求不能有任何数据丢失，则必须和用户沟通，让他们了解这样的要求仅使用数据备份技术实现是不现实的，需要做更大的投入，引入镜像技术。

既然数据丢失的最大时间段，就要两次备份之间的时间间隔，也就是说备份做的越多，数据丢失量就越少。可是，做备份越频繁，需要投入的也就越多。涉及的因素也就越多：

1、备份越多，要管理的备份文件也越多，数据库恢复时要恢复的文件也越多。需要建立一个合适的制度。

2、备份虽然会阻塞数据的正常操作，但是会产生一系列的磁盘读写。如果服务器本身的IO就比较频繁，备份动作会进一步影响数据库的性能。需要增强服务器的硬盘的读写处理能力，才能避免这种问题的发生。

3、备份难免会因为种种因素失败。备份越勤，遇到失败的几率就越多。管理员要及时处理错误，将备份任务恢复常态。这对管理员的要求也比较高。

当您对您愿意投入的人力物力心中有数以后，就可以来决定采用什么也样的备份策略了。

使用日志备份，可以将数据库恢复到故障或特定的时间点。所以日志备份在备份策略中扮演者很重要的角色。但是日志备份只能在完整恢复模式和有些大容量日志恢复模式的数据库上进行。

指定备份策略，首先要决定是否需要做日志备份。如果需要做日志备份，数据库恢复模式就要选成完整模式。（大容量恢复模式不能保证日志备份成功，所以一般不推荐在生产环境下使用。）如果不做日志备份，数据库模式就要设置成简单。否则会遇到日志文件无限增长问题。

一、简单恢复模式下的备份

简单恢复模式下，不能做日志备份。所以它只支持最简单的备份和还原模式。很容易管理。不过如果没有日志备份，就只能将数据库恢复到最后一次备份的结尾。如果发生灾难，数据最后一次备份之后做的修改将丢失。

上图显示了简单恢复模式下最简单的备份与还原策略，此策略仅使用包含了数据库中所有数据的完整数据库备份。存在五个完整数据库备份，但是只需要还原最近的备份（t5时点执行的备份），还原此备份会将数据库恢复到t5时点，由于t6框表示的所有后续更新都将丢失。

并且在简单恢复模式下，会自动截断事务日志，以删除不活动的虚拟日志文件。截断通常发生在每个检查点之后，但在某些情况下会延迟。

在简单恢复模式下，工作损失风险会随时间增长而增加，直到进行下一个完整备份或者差异备份为止。因此，建议安排足够的频率，以避免遗失大量的数据。同时，频率也不能太高而让备份变得难以管理。

上图显示了这种备份计划的工作损失风险。所以这个粗略只适合用于频繁备份的小型数据库里。

为了降低风险，SQL Server又引入了差异备份。

上图显示了使用差异数据库备份补充数据库完整备份来减轻工作损失风险的一种备份策略。在第一次数据库备份之后，连续建立了3此差异备份。第3个差异备份后，进行数据库完整备份，建立新的差异基准。因为差异备份的开销一般都比完整备份低，所以能够比较经常的运行。这样的备份策略可以使用在数据量稍大，能够容忍较长时间丢失的数据库上。

以上两种备份策略的优势，是不管是备份还是恢复，管理起来都比较简单。但是不管是数据库完整备份，还是差异备份，都不能以比较频繁的频率进行，一般都只能在晚间进行。如果数据库比较庞大，或者不允许长时间的数据丢失，这样的备份策略是不能满足要求的。必须引入日志备份。

二、完整恢复模式下的备份

如果数据库是完整恢复模式，就可以使用日志备份。由于日志备份只拷贝上次日志备份以来的所有日志记录，所以开销会比数据库备份小很多。可以定义以一种很频繁的频率（5分钟甚至更短）来做备份，以达到在最大限度内，防止出现故障丢失数据的目的。使用日志备份的优点是允许您将数据库还原到日志备份的任何点（“时点恢复”）。假定可以在发生严重故障后备份活动日志，则可能数据库一直还原到没有发生数据丢失的故障点处。使用日志备份的缺点是它们的数量很多，而且恢复备份时，需要严格按照备份产生的顺序依次恢复。中间不能有任何备份缺失或跳跃。所以日志备份做的越多，还原时间就越多。管理复杂性也越高。

上图显示了完整恢复模式下最简单的备份策略。上图中已经完成了备份Db_1以及两个例行日志备份Log_1和Log_2。在Log_2日志备份后的某个时间，数据库出现故障。在还原这3个备份前，数据库管理员必须备份活动日志（日志尾部）。然后还原Db_1、Log_1和Log_2，并且不恢复数据库。接着，数据库管理员还原并恢复尾（Tail）日志备份。这一步将可以把数据库恢复到故障点。从而恢复所有数据。如果尾日志能够成功的备份和恢复。这次灾难可能甚至不会带来任何数据丢失。如果遭难毁坏的是日志文件。使得尾日志不能成功备份和恢复，那这次灾难造成的数据丢失就是从Log_2以后所有的修改。

所以，在第一个完整数据库备份完成，并且常规日志备份开始之后，潜在的工作丢失风险的时间，仅为数据库损坏时点。到上次一次常规日志备份的那一段时间，因此，建议经常执行日志备份，以将工作丢失的风险限定在业务所要求所允许的范围内。

出现故障后，可以尝试备份“日志尾部”（尚未备份的日志）。如果尾部日志备份成功，则可以通过将数据库还原到故障点来避免任何工作丢失。所以这种备份计划的优点也是很明显的。

上图显示了该中备份策略并且使用一系列例行日志备份来补充完整数据库备份。使用事务日志备份可缩短潜在的工作丢失风险存在的时间，使该风险仅在最新日志备份之后存在。在第一个数据库备份完成后，每天会做一个差异数据库备份，而在工作时间进行若干日志备份。

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

但是，上述备份计划存在一大缺陷，就是灾难发生后需要恢复的日志文件数目太多。假设每个小时做一次日志备份，每周做一次数据库备份，如果灾难在周五发生，就不得不恢复上百个日志备份。这个工作量和所要花的时间是很大的。所以为了最大程度缩短还原时间，可以对相同数据库进行一系列差异备份做补充。

三、文件或文件组备份

 完整文件备份指的是备份一个或多个文件或文件组中的所有数据。在完整恢复模式下，一整套完整文件备份和所有文件备份的日志备份合起来。等同于一个完整数据库备份。使用文件备份能够只还原损坏的文件，而不用还原数据库的其余部分，从而加快恢复速度。例如，如果数据库由位于不同磁盘上的若干文件组成，在其中一个磁盘发生故障时，只须还原故障磁盘上的文件。

在SQL Server7.0和SQL Server2000中，文件备份和差异文件备份不包含日志记录。必须显式会恢复日志备份才能恢复其数据。因此，在这两个版本中。只能将文件备份与完整恢复模式和大容量日志恢复模式结合使用。在SQL Server 2005以后，文件备份在默认情况下包含足够的日志记录，可以将文件前滚至备份操作的末尾。（但是在简单恢复模式下，必须一起备份所有读/写文件，而不是逐个指定每个读/写文件或文件组。）

相对于数据库备份，文件备份具有如下优点：

1、能够更快的从隔离的媒体故障中恢复。可以迅速还原损坏的文件。

2、与完整数据库备份（对于超大型数据库而言，变得难以管理）相比，文件备份增加了计划和媒体处理的灵活性。文件或文件组备份的更高灵活性对于包含具有不同更新特征的数据的大型数据库也很有用。

此种备份方法和完整数据库备份相比，文件备份的主要缺点是管理比较复杂。如果某个损坏的文件未备份，那么媒体故障可能会导致无法恢复整个数据库。因此，必须维护一组完整的文件备份，对于完整/大容量日志恢复模式，还必须维护一个或多个日志备份。这些日志备份至少涵盖第一个完整文件备份和最后一个完整备份之间的时间间隔。

维护和跟踪这些完整备份是一种耗时的任务，所需空间可能会超过完整数据库备份的所需空间。所以这种备份策略在实际应用中应用的还是比较少的。而且在现在来讲存储已经变得很便利，但是这种方法在管理超大数据库时，才能发挥出其不可代替的优势。

在完整恢复模式下，一整套完整文件与涵盖第一个文件备份开始的所有文件备份的足够日志备份起来等同于完整数据备份。

上图显示了文件备份的原理，如果可能最好执行完整数据库备份并在第一个文件备份开始之前开始日志备份。上图显示了创建数据库（在t0时间）之后立即执行完整数据库备份（在t1时间）的策略。创建了第一个数据库备份之后，便可开始执行事务日志备份。事务日志备份计划按照设置间隔执行。文件备份以最合适数据库业务要求的间隔执行。此图显示了4个文件组，每次备份其中的一个文件组。它们的备份顺序（A、C、B、A）反映了数据库的业务要求。

在完整恢复模式下，恢复一个文件组备份，不但需要恢复文件组备份本身，还需要依次恢复从上一次完整数据库备份后，到恢复的目标时间点为止的所有日志备份。以确保该文件与数据库的其余部分保持一致。所以要恢复的事务日志备份数量会很多。要避免这种情况，可以考虑使用差异文件备份。可是这样会使整个备份计划更加难于管理。这也是为什么文件备份不常使用的重要原因。但是在管理超大数据库时，这可能是唯一的选择。

不同的的库设置不同的备份方案，可以自己自行选择。

《SQL Server企业级平台管理实践》读书笔记——关于SQL Server数据库的备份方式