理主要是为防止非法登录者或非授权用户对SQL Server 数据库或数据造成破坏，但在有些情况下这种安全管理机制显得力不从心。例如合法用户不小心对数据库数据做了不正确的操作或者保存数据库文件的磁盘遭到损坏或者运行SQL Server 的服务器因某种不可预见
的事情而导致崩溃。所以我们需要提出另外的方案即数据库的备份和恢复来解决这种问题。本章的主要目的就是介绍备份、恢复的含
义，数据库备份的种类以及备份设备等基本的概念，以及如何创建备份和恢复数据库，使读者对其有全面的了解和认识，能够自主制定自己的备份和恢复计划。
15.1.1 备份和恢复
备份和恢复组件是SQL Server 的重要组成部分。备份就是指对SQL Server 数据库或事务日志进行拷贝，数据库备份记录了在进行备份这一操作时数据库中所有数据的状态，如果数据库因意外而损坏，这些备份文件将在数据库恢复时被用来恢复数据库。
由于SQL Server 支持在线，备份所以通常情况下可一边进行备份，一边进行其它操作，但是，在备份过程中不允许执行以下操作： 创建或删除数据库文件； 创建索引； 执行非日志操作； 自动或手工缩小数据库或数据库文件大小。 如果以上各种操作正在进行当中，且准备进行备份则备份，处理将被终止；如果在备份过程中，打算执行以上任何操作，则操作将失败而备份继续进行。
恢复就是把遭受破坏或丢失数据或出现错误的数据库恢复到原来的正常状态，这一状态是由备份决定的，但是为了维护数据库的一致性，在备份中未完成的事务并不进行恢复。
进行备份和恢复的工作主要是由数据库管理员来完成的。实际上数据库管理员日常比较重要、比较频繁的工作就是对数据库进行备份和恢复。
注意：如果在备份或恢复过程中发生中断，则可以重新从中断点开始执行备份或恢复。这在备份一个大型数据库时极有价值。
15.1.2 数据库备份的类型
在SQL Server 2000 中有四种备份类型，分别为； 数据库备份（Database Backups） 事务日志备份（Transaction Log Backup） 差异备份（Differential Database Backups） 文件和文件组备份（File and File Group Backup） 下面我们将详细介绍其所表述的内容，并涉及到一些使用时注意事项。
1 数据库备份（Database Backups）
数据库备份是指对数据库的完整备份，包括所有的数据以及数据库对象。实际上备份数据库过程就是首先将事务日志写到磁盘上，
然后根据事务创建相同的数据库和数据库对象以及拷贝数据的过程。由于是对数据库的完全备份，所以这种备份类型不仅速度较慢，
而且将占用大量磁盘空间。正因为如此，在进行数据库备份时，常将其安排在晚间，因为此时整个数据库系统几乎不进行其它事务操作，从而可以提高数据库备份的速度。
在对数据库进行完全备份时，所有未完成的事务或者发生在备份过程中的事务都不会被备份。如果您使用数据库备份类型，
则从开始备份到开始恢复这段时间内发生的任何针对数据库的修改将无法恢复。所以我们总是在一定的要求或条件下才使用这种备份类型，比如： 数据不是非常重要，尽管在备份之后恢复之前数据被修改，但这种修改是可以忍受的； 通过批处理或其它方法，在数据库恢复之后可以很容易地重新实现在数据损坏前发生的修改； 数据库变化的频率不大。 在进行数据库备份时，如果您在备份完成之后又进行了事务日志备份，则在数据库备份过程中发生的事务将被备份：但若只进行数据库备份，常将数据库选项“trunc.log onchkpt” 设置为true， 这样每次在运行到检查点（checkpoint） 时，都会将事务日志截断。
注意：如果对数据一致性要求较高（将数据库恢复到发生损坏的刻），则不应使用数据库备份。
2 事务日志备份（Transaction Log Backup）
事务日志备份是指对数据库发生的事务进行备份，包括从上次进行事务日志备份、差异备份和数据库完全备份之后，所有已经完成的事务。在以下情况下我们常选择事务日志备份。 不允许在最近一次数据库备份之后发生数据丢失或损坏现象； 存储备份文件的磁盘空间很小或者留给进行备份操作的时间有限，例如兆字节级的数据库需要很大的磁盘空间和备份时间； 准备把数据库恢复到发生失败的前一点； 数据库变化较为频繁。 由于事务日志备份仅对数据库事务日志进行备份，所以其需要的磁盘空间和备份时间都比数据库备份（备份数据和事务）少得多，这是它的优点所在。正是基于此，我们在备份时常采用这样的策略，即每天进行一次数据库备份，而以一个或几个小时的频率备份事务日志。这样利用事务日志备份，我们就可以将数据库恢复到任意一个创建事务日志备份的时刻。
但是，创建事务日志备份却相对比较复杂。因为在使用事务日志对数据库进行恢复操作时，还必须有一个完整的数据库备份，而且事务日志备份恢复时必须要按一定的顺序进行。比如在上周末对数据库进行了完整的数据库备份，在从周一到本周末的每一天都进行一次事务日志备份，那么若要打算对数据库进行恢复，则首先恢复数据库备份，然后按照顺序恢复从周一到本周末的事务日志备份。
有些时侯数据库事务日志会被中断，例如数据库中执行了非日志操作（如创建索引、创建或删除数据库文件、自动或手工缩小数据库文件大小），此时应该立即创建数据库或差异备份，然后再进行事务日志备份。以前进行的事务日志备份也没有必要了。
3 差异备份（Differential Database Backups）
差异备份是指将最近一次数据库备份以来发生的数据变化备份起，来因此差异备份实际上是一种增量数据库备份。与完整数据库备份相比，差异备份由于备份的数据量较小，所以备份和恢复所用的时间较短。通过增加差异备份的备份次数，可以降低丢失数据的风险，将数据库恢复至进行最后一次差异备份的时刻，但是它无法像事务日志备份那样提供到失败点的无数据损失备份。
但在实际中为了最大限度地减少数据库恢复时间以及降低数据损失数量，我们常一起使用数据库备份、事务日志备份和差异备份，而采用的备份方案是这样的； 首先有规律地进行数据库备份，比如每晚进行备份； 其次以较小的时间间隔进行差异备份，比如三个小时或四个小时； 最后在相临的两次差异备份之间进行事务日志备份，可以每二十或三十分钟一次。
这样在进行恢复时，我们可先恢复最近一次的数据库备份，接着进行差异备份，最后进行事务日志备份的恢复。
但是，在更多的情况下我们希望数据库能恢复到数据库失败那一时刻，那么我们该怎样做呢？下面的方法也许会有大帮助。 首先如果能够访问数据库事务日志文件则应备份当前正处于活动状态的事务日志； 其次恢复最近一次数据库备份； 接着恢复最近一次差异备份； 最后按顺序恢复自差异备份以来进行的事务日志备份。 当然，如果无法备份当前数据库正在进行的事务，则只能把数据库恢复到最后一次事务日志备份的状态，而不是数据库失败点。
4 文件和文件组备份（File and File Group Backup）
文件或文件组备份是指对数据库文件或文件夹进行备份，但其不像完整的数据库备份那样同时也进行事务日志备份。使用该备份方法可提高数据库恢复的速度，因为其仅对遭到破坏的文件或文件组进行恢复。
但是在使用文件或文件组进行恢复时，仍要求有一个自上次备份以来的事务日志备份来保证数据库的一致性。所以在进行完文件或文件组备份后应再进行事务日志备份。否则备份在文件或文件组备份中所有数据库变化将无效。
如果需要恢复的数据库部分涉及到多个文件或文件组，则应把这些文件或文件组都进行恢复。例如，如果在创建表或索引时，表或索引是跨多个文件或文件组，则在事务日志备份结束后应再对表或索引有关的文件或文件组进行备份，否则在文件或文件组恢复时将会出错。
15.1.3 备份和恢复的策略
通常而言，我们总是依赖所要求的恢复能力（如将数据库恢复到失败点） 、备份文件的大小（如完成数据库备份或只进行事务日志的备份或是差异数据库备份）以及留给备份的时间等来决定该使用哪种类型的备份。常用的备份选择方案有：仅仅进行数据库备份、或在进行数据库备份的同时进行事务日志备份，或使用完整数据库备份和差异数据库备份。
选用怎样的备份方案将对备份和恢复产生直接影响，而且也决定了数据库在遭到破坏前后的一致性水平。所以在做出该决策时，您必须认识到以下几个问题： 如果只进行数据库备份，那么将无法恢复自最近一次数据库备份以来数据库中所发生的所有事务。这种方案的优点是简单，而且在进行数据库恢复时操作也很方便； 如果在进行数据库备份时也进行事务日志备份，那么可以将数据库恢复到失败点，那些在失败前未提交的事务将无法恢复，但如果您在数据库失败后立即对当前处于活动状态的事务进行备份，则未提交的事务也可以恢复。 从以上可以看出，对数据库一致性的要求程度成为我们选择这样或那样的备份方案的主要的普遍性原因。但在某些情况下对数据库备份提出更为严格的要求，例如在处理比较重要业务的应用环境中，常要求数据库服务器连续工作，至多只留有一小段时间来执行系统维护任务，在该情况下一旦出现系统失败，则要求数据库在最短时间内立即恢复到正常状态，以避免丢失过多的重要数据，由此可见备份或恢复所需时间往往也成为我们选择何种备份方案的重要影响因素。
那么如何才能减少备份和恢复所花费时间呢？SQL Server 提供了几种方法来减少备份或恢复操作的执行时间。 使用多个备份设备来同时进行备份处理。同理，可以从多个备份设备上同时进行数据库恢复操作处理； 综合使用完整数据库备份、差异备份或事务日志备份来减少每次的需要备份的数据数量； 使用文件或文件组备份以及事务日志备份，这样可以只备份或恢复那些包含相关数据的文件，而不是整个数据库。 另外需要注意的是，在备份时我们也要决定该使用哪种备份设备如磁盘或磁带，并且决定如何在备份设备上创建备份，比如将备份添加到备份设备上或将其覆盖。 在SQL Server 2000 中，有三种数据库恢复模式，它们分别是：简单恢复（SimpleRecovery）、 完全恢复（Full Recovery）、 批日志恢复（Bulk-logged Recovery）。
1 简单恢复（Simple Recovery）
所谓简单恢复就是指在进行数据库恢复时仅使用了数据库备份或差异备份，而不涉及事务日志备份。简单恢复模式可使数据库恢复到上一次备份的状态，但由于不使用事务日志备份来进行恢复，所以无法将数据库恢复到失败点状态。当选择简单恢复模式时常使用的备份策略是：首先进行数据库备份，然后进行差异备份。
2 完全恢复（Full Recovery）
完全数据库恢复模式是指通过使用数据库备份和事务日志备份将数据库恢复到发生失败的时刻，因此几乎不造成任何数据丢失，这成为对付因存储介质损坏而数据丢失的最佳方法。为了保证数据库的这种恢复能力，所有的批数据操作比如SELECT INGO、创建索引都被写入日志文件。选择完全恢复模式时常使用的备份策略是： 首先进行完全数据库备份； 然后进行差异数据库备份； 最后进行事务日志的备份。
如果准备让数据库恢复到失败时刻必须对数据库失败前正处于运行状态的事务进行备份。 3 批日志恢复（Bulk-logged Recovery）
批日志恢复在性能上要优于简单恢复和完全恢复模式，它能尽最大努力减少批操作所需要的存储空间。这些批操作主要是：SELECT INTO 批装载操作（如bcp 操作或批插入操作）、创建索引针对大文本或图像的操作（如WRITETEXT、 UPDATETEXT）。选择批日志恢复模式所采用的备份策略与完全恢复所采用的恢复策略基本相同。
从以上的论述中我们可以看到，在实际应用中，备份策略和恢复策略的选择不是相互孤立的，而是有着紧密的联系。我们并不仅仅是因为数据库备份为数据库恢复提供了 “原材料”这一事实，以便在采用何种数据库恢复模式的决策中考虑该怎样进行数据库备份，更多是因为在选择该使用哪种备份类型时我们必须考虑到当使用该备份进行数据库恢复时，它能把遭到损坏的数据库“带”到怎样的状态（是数据库失败的时刻，还是最近一次备份的时刻）。但有一点我们必须强调，即备份类型的选择和恢复模式的确定都应服从于这一目标：尽最大可能，以最快速度减少或消灭数据丢失。