32. 备份SQL Server
备份的术语
系统故障
SQL Server记录文件
备份方法
执行备份
排程备份
改善备份
本章总结
将数据库备份是 DBA 最重要的任务之一。备份和仔细的还原计划可在系统失效时将数据还原。DBA 的责任是保持系统的执行状态，并在失效时尽快还原所有的服务。系统停止运作会造成许多不便，有时更要付出昂贵的代价，因此在系统停止运作时得很快的取得取得数据库备份。有些技术会对系统失效的还原有帮助，如丛集和容错磁盘子系统，但是还是比不上一个好的计划和可靠的备份。
因为备份、还原和复原数据库的主题十分重要，因此我们会分成两章的来讨论。本章中将学习 SQL Server 交易记录文件，以及备份数据库的几种方法。在 第 33 章 中，将学习如何还原数据库、SQL Server 如何回复、以及如何建立回复计划。
备份的术语
在开始讨论备份技术之前，让我们回顾一些术语。在这个章节中，您将学到关于备份、还原、和回复操作的实例。
备份和还原
备份（backup）和还原（recover）操作相辅相成的，即保存数据库中的数据以便稍后使用，类似操作系统所执行的备份和还原作业。在备份过程中，数据从数据库中复制出来，并保存到另一个位置。操作系统备份和数据库备份是不同的，差别在于操作系统备份可以保存个别的档案，而数据库备份则保存整个数据库。通常数据库供很多的使用者共享，但是很多操作系统档案则是属于各使用者。因此，数据库备份同时备份了所有的使用者的数据。由于 SQL Server 设定了使用时间的最大值，因此不管当时使用者是否正在存取数据库，备份过程都会执行。
在还原过程中，备份数据被复制回数据库中。不要将还原（restore）和回复（回复）混淆在一起，这是两种不同的操作。和备份过程不同的是，当 SQL Server 正在执行时，还原过程无法进行。此外，数据表也无法个别还原。如果一个使用者遗失了数据库中的某些数据，遗失的数据很难还原，因为还原操作将还原整个数据库或者部分数据，而从数据库的所有数据中区分出单一使用者的数据是相当困难的。
回复
回复（recovery）包含用来解救系统故障的关系型数据库管理系统（RDBMS）和重新进行（回复）交易的能力。每次变更数据库时，SQL Server 并不会立即将变更写到磁盘上。如果系统每次都立即写到磁盘上，那么一个大系统（例如银行中的系统）可能会运作得相当缓慢，因为必须等待每笔交易完成写入后才能进行。这会导致交易延迟。
由于将变更内容写入磁盘时有所延迟，系统失效时可能会使数据库处于毁损状态，有些数据库的变更可能还没写到磁盘上，或是写到磁盘上的变更可能未被认可。为了保持系统的完整性，SQL Server 在交易记录文件中记录了所有的变更。（交易记录文件将在本章的 ＜交易记录文件＞ 一节中详细讨论。）系统失效后重新启动 SQL Server，它会使用交易记录文件来进行所有已经认可但没有写入磁盘的交易，并且返回故障时没有认可的交易。在这种方式中，可以保证数据的正确性。
在回复过程中，SQL Server 必须准备好处理多种类型的交易，包含以下：
• 只进行查询的交易 不需要回复。
• 已经变更数据库中的数据交易，以及已经认可但没有写到磁盘上 在回复过程中，SQL Server 从磁盘上读取数据页，重新套用变更，然后再将数据页写回磁盘上。
• 已经变更数据库中数据的交易，已经认可而且已经写到磁盘上 在回复过程中，SQL Server 确定变更已经写到磁盘上，不需要其它介入。
• 已经变更数据库中数据的交易，还没有认可 在回复过程中，SQL Server将使用交易记录文件，复原所有数据页上的变更，将数据库还原到交易执行前的状态。
当 SQL Server 从系统失效后重新启动时，回复机制将自动开启。回复机制利用交易记录文件来确定哪些交易需要回复，哪些不需要回复。很多的交易是不需要回复的，但是 SQL Server 仍必须读取交易记录文件才可做决定。SQL Server 从最后的检查点开始读取交易记录文件。（检查点将在本章的后面加以讨论。）
________________________________________
说明
由于在故障发生时，交易记录文件对于交易的回复十分重要，因此它通常保存在RAID-1（镜像）磁盘区中。（RAID 曾在 第 5 章 中讨论。）
________________________________________
在系统故障时，需要使用备份文件还原数据库（例如损毁一个磁盘），交易记录文件和交易记录文件备份用来将数据库回复到故障点。因此，还原和回复操作通常是共同作业的。在发生电力故障时，可能只需要回复。
________________________________________
说明
由 S QL Server 复原的交易等于以 ROLLBACK 指令中止交易。这个交易将被取消，而且所有的数据将还原到它的原始状态。当一个交易重新进行时，这些已经记录到数据库中但没有写入到磁盘上的数据将被重置，因此数据文件将回到故障时间的状态。也就是说，重新进行使数据库的状态返回到故障的时间点，重新处理已认可的交易，消除所有未认可的交易。
________________________________________
系统故障
如果使用的是如 Microsoft 丛集服务，或是磁盘具 RAID 容错功能，您可能正在怀疑是否真的需要备份，答案是「需要」。由于系统的故障方式不尽相同，容错和错误回复可能只能修正某些情况。在这一节中，我们将讨论一些潜在的故障原因，以及如何避免故障。
某些系统故障的情形可能并不严重，而另一些却可能十分严重。要了解备份的重要性，就得先了解三种主要的故障类型：硬件故障、软件故障和人为错误。
硬件故障
硬件故障可能是最普遍的故障类型。由于现在的计算机硬件比起之前更稳定，因此这种故障类型所发生的频率慢慢减少，但是在使用一段时间之后，组件的磨损在所难免。典型的硬件故障包括下列几种：
• CPU、内存或总线故障 这些故障通常会导致系统损毁。在替换了有故障的组件并重新启动系统后，SQL Server 将自动执行数据库回复。数据库本身是完整的，因此并不需要进行还原，只需要回复遗失的交易。
• 磁盘故障 如果使用了 RAID 容错功能，那么这种故障类型可能不会影响到数据库的状态，因此只需要修复 RAID 数组。如果没有使用 RAID 容错，或是 RAID 数组发生故障，那么唯一的选择就是从备份还原数据库，然后利用交易记录文件备份回复数据库。
• 系统大故障或永久性服务器损失 如果系统在火灾或灾难中受到损毁，理所当然就得重新设定所有系统。硬件需要重新装配，数据库需要从备份进行还原，然后使用数据和交易记录文件备份回复数据库。
软件故障
软件故障并不常见，然而软件故障通常比硬件故障更严重。由于软件大多内建了将硬件故障影响最小化的功能，因此当软件发生故障，硬件就失去了这个保护功能，使系统更容易受到故障的影响。交易记录文件就是一个具有这种软件功能的例子，用来帮助从硬件故障进行回复。典型的软件故障包括下列几种：
• 操作系统故障 如果故障发生在 I/O 子系统中，就会破坏磁盘上的数据。如果数据库未被破坏，则只需要回复数据即可。当然，如果数据库被破坏，唯一的选择就是透过备份进行数据库还原。
• RDBMS故障 SQL Server 本身是可能故障的。如果这种故障造成了损坏，那么就需要透过备份进行数据库还原和回复。如果没有损坏，利用自动回复就可以使系统返回到出现故障的那一点。
• 应用程序故障 应用程序也可能故障，导致数据破坏。如果这类故障造成数据的损坏，也需要透过备份进行数据库还原。反之，就不需要还原，利用自动回复将使得系统返回到出现故障的那一点即可。您可能还需要向应用程序厂商所取修补程序，以避免故障再次发生。
________________________________________
说明
有些公司会使用 SQL Server 的 beta 版。其实 beta 版只是用来评估和测试，不能用在一个正式的执行环境中。有时候beta版含有软件错误，包括尚未完全通过测试的功能。您应该使用 Microsoft SQL Server 2000 的产品版本，这是完全通过测试的，且供正式执行环境使用。
________________________________________
人为错误
第三种重要的错误类型是人为错误。人为错误可能在任何时候不经意的发生。人为的错误所造成的损坏可轻可重，麻烦的是，这类型错误很容易被忽视个几天甚至几周，使得回复更加困难。和使用者建立良好的互动关系（包括良好的通讯管道），就可以快速的回复使用者造成的错误。使用者不会害怕立即报告错误，当然越早发现错误越好。下面的故障可能是由人为错误引起的：
• 数据库服务器损失 人为错误会造成服务器故障的情形包括：不小心关闭电源、没有先关闭 SQL Server 就关闭服务器。当 SQL Server 重新启动时，回复将自动执行，当然这要花上一些时间。不过由于磁盘上的数据库未受损伤，所以不需要还原。
• 遗失数据 可能是有人不小心删除数据文件所造成。必须执行还原与回复操作来使数据库返回故障点前的状态。
• 数据表遗失或被破坏的数据 如果误删数据表，或者由于某种因素误改资料，可以使用备份和还原来将资料表返回到它的原始状态。由于遗失的单一数据表或一小组数据不能只从备份还原，因此这种故障类型的回复可能相当复杂。我们将在 第 33 章 中讨论回复这类型故障的范例。
SQL Server 记录文件
要了解备份和还原操作如何与数据库回复共同作业的，必须先了解 SQL Server记录文件的运作方式。这一节将提供关于 SQL Server 记录和检查点的概述，并将告诉您如何备份交易记录文件。
交易记录文件
交易记录文件 （transaction log）用来记录所有的交易以及这些交易对数据库做出的修改。这个记录让回复可以进行。当认可一个交易时，只要认可记录还没写入交易记录文件，认可操作就不算完成。由于对于数据库的变更并不需要立即写入磁盘中，这个记录文件只是一种在系统故障事件中可以回复交易的方法。
________________________________________
说明
如果一个数据文件受到损坏必须透过备份还原时，所有发生在这个数据文件上的交易都必须重复执行一次，才能将数据库回复到故障的那一点。由于交易记录文件是这个过程的关键，而且空间有限，所以必须执行交易记录文件备份。您必须保存从上次备份到现在产生的所有交易记录数据，这样才能回复数据库。如果您只对上一次备份的还原感兴趣，您可以跳过交易记录文件备份，但是目前的交易记录文件将不能回复那次备份以后发生的交易。
________________________________________
延迟写入器执行绪
在数据库上的变更是最先写入 SQL Server 快取区中的资料。变更快取区中的数据主要是为了提升效能，因为等待 I/O 运作是相当费时的。这些变更最终还是会写入磁盘，只是这个过程在背景执行，而使用者并不知道。由于修改的页面储存在快取区，在这些页面（称为Dirty分页）被 SQL Server 执行绪写入磁盘之前，会耗费相当大量的时间。这个执行绪称为 延迟写入器执行绪 （lazywriter thread）.
延迟写入器执行绪使用近来最少使用的页面清单，这表示近来最少使用的数据将放在写入磁盘的清单开头，而刚刚才被使用的数据放在清单结尾，而且也最不可能被写入磁盘中。那些经常被修改的页面（因此总是不断地被移到清单的结尾）可能永远不会被延迟写入器执行绪写入磁盘中。这样会增加回复时间，因为可能必须读取许多交易记录才能将所有的变更应用在数据上。
例如，在一个具有超过 1 GB 的 RAM 的大规模系统中，要对数据库做很多变更的话，回复过程将花费好几个小时。除了延迟写入器执行绪之外，检查点（checkpoint）执行绪也将 Dirty 页面写入到磁盘中。（我们将在本节的后面详细讨论检查点执行绪。）
顺序记录
因为交易记录文件是交易的历史记录，交易记录文件的 I/O 运作主要是写入，并且一般是按照时间顺序。在交易复原事件中，交易记录文件将被读取，且 I/O 的时间顺序将被破坏。由于复原相当少见（因为系统崩溃很少见，而且使用者不会常常复原交易），交易记录文件中的 I/O 模式相当稳定。您可将交易记录文件放在它自己的磁盘或 RAID 数组中来增强 I/O 效能，就像 第 4 章 和 第 5 章 讨论过的。您应该使用 RAID 保护交易记录文件，因为这些交易纪录对于数据库回复是很重要的。
交易记录文件大小
根据对数据库的变更数量，交易记录文件可能增长得很大。因为交易记录文件是一个或多个档案的有限集合，最终它将被填满，因此必须定期删减。完成记录文件备份时，记录文件会自动被删减，这将在本章的后面讨论。
________________________________________
说明
如果没有备份记录文件，您还是可以删减这个记录文件，只要将数据库的数据库选项 trunc.log on chkpt 设为 TRUE 就行了。然而，这样做以后您便不能备份交易记录文件。这个设定将使得数据库不可回复，因此不建议使用。
________________________________________
使用交易记录文件回复
在数据库档案没有破坏的系统故障事件中，当前的交易记录文件可以用来回复数据库，因为只需要回复那些还没有写入到磁盘中的交易。必须回复的页面数量取决于数据库中的 dirty page 数量，由检查点间隔决定。检查点会将 dirty page 写入磁盘中，减少执行回复的时间。检查点和检查点间隔将在本章的 ＜检查点＞ 一节中详细讨论。
交易记录属性
SQL Server 2000 和 SQL Server 7.0 中的交易记录文件有很多相同的特点，如下：
• 交易记录文件不再被视为等同于一个资料文件。在 8KB 页面中交易不会像数据文件一样从交易档案中被写入或读取。现在交易记录文件可以写在任何它需要的大小尺寸中，交易记录文件页面不再按照数据页的格式。因此，如果记录文件写入执行绪只需写入少量内容，它就不必写 8 KB 的资料。如果系统经常更新，那么记录文件写入执行绪可以使用大型区块（16 KB、32 KB等）来写入。
• 交易记录文件可以依据需要设定为自动增长。这个特性允许在需要时增加更多的空间，但是在使用它时应该注意避免交易记录文件的无限制增长而占用整个磁盘。
• 现在交易记录文件可以用多个档案来建置。这些档案也可以设定为自动增长。但是交易记录档案无法划分成数据带；它们要一个接着一个使用。（数据带划分在 第 5 章 中讨论。）
• 交易记录文件可以移到其它系统中使用，以便在备用系统中再度执行。这就是所谓的记录转移，将在下一章中有更多的讨论。
无纪录操作
您已经熟悉纪录和回复的规则，可以开始学这些规则的例外情形。如之前所提到，在正常的情况下，所有交易以及变更都记录在交易记录文件中。然而，您可以执行某些不会记录下来的操作。这些操作称为非记录作业（nonlogged operation）。使用非记录作业来执行大量数据操作（占用大量的交易记录档案资源）时，可以提升操作效能。
由于非记录作业没有记录在交易记录文件中，如果有必要回复数据库的话，就必须重新操作一次。因此，在使用非记录作业前，必须仔细考虑非记录作业的影响结果。非记录作业的执行方法如下：
• SELECT INTO
• BULK COPY and Bulk Copy Program (BCP)
• CREATE INDEX
• 特定文字操作
本章稍后会谈到上述操作的更多细节。
为了让数据库中可以执行非记录作业，必须将数据库设定在 BULK_LOGGED 回复模式。其它的回复操作是 FULL 和 SIMPLE。使用 ALTER DATABASE 指令设定这些选项，如下：
ALTER DATABASE Northwind
SET RECOVERY BULK_LOGGED
ALTER DATABASE Northwind
SET RECOVERY FULL
ALTER DATABASE Northwind
SET RECOVERY SIMPLE
使用 BULKED_LOGGED 回复模式时，本章所提的大量操作将不会有记录（会有些例外情形，将在稍后说明），而其它操作仍会有记录。如果选择 FULL 回复模式，那么所有的操作又会全部记录下来。当执行SIMPLE回复模式时，数据只会回复到最后一次备份。
________________________________________
说明
因为回复模式限定您的系统的故障容忍度，所以使用 BULK_LOGGED 回复模式时必须很谨慎。如果您使用这个模式，可以提升非记录大量操作的效能，但是故障事件发生时，将会增加回复时间。
________________________________________
SELECT INTO
SELECT INTO 陈述式是用来在数据库中建立新的数据表。因为 SELECT INTO陈述式不能用来选择数据放入已存在的对象中，所以它不能用来更新数据，只能用来建立数据。建立数据的过程常常可以重复执行，因此 SELECT INTO 陈述式很适合用来执行非记录作业。
大量复制和 BCP
为了使大量复制和 BCP 操作可用来执行非记录作业，必须符合下列几项要求：
• 数据库选项 select into/bulkcopy 必须设定在TRUE。
• 当大量数据复制开始时，目标数据表必须是空的才能够制作索引。
• 不能复制目标数据表，因为交易复制时占用了交易记录文件中复制数据时所需要的项目。
• 必须指定 TABLOCK 提示来强制锁定数据表。
这些限制让大量复制操作节省交易记录文件的空间，还让执行速度变快。然而，当数据库必须从备份还原时，这些非记录作业都要重新操作一次。
CREATE INDEX
CREATE INDEX 陈述式操作使也很适合执行非记录作业，因为索引可以依需要重新建立。重建索引并不困难。然而，如果数据表太大，过程可能会相当花费时间，并占用资源。
文字操作
文字操作可以用来执行非记录作业的是 WRITETEXT 和 UPDATETEXT。要使这些操作执行时不留下记录，您只要像刚刚所提的使用 BULK_LOGGED 回复选项就可以了。
检查点
检查点（checkpoint）是用来使实体数据文件和数据库快取的状态同步的操作，可以减少系统故障事件发生时的必要回复时间。回复数据库需要的时间取决于最后一个检查点以来的时间总量和缓冲快取区中的 dirty page 数量。因此，减少检查点的间隔可以减少回复时间，但会增加系统负荷：检查点过程会导致大量的系统资源占用。
检查点发生在以下时间点：使用 CHECKPOINT 陈述式时、使用 SHUTDOWN陈述式关闭 SQL Server 时、使用服务管理员关闭 SQL Server 时，以及 SQL Server 自动产生检查点时。
检查点操作
检查点过程执行数个操作，包括下列内容：
• 在检查点开始时就将所有的dirty page写出 这时所有包含已变更数据但尚未写到磁盘中的页面将被写到磁盘中。
• 将未完成的交易清单写到交易记录文件中 告诉 SQL Server 在检查点发生时进行了哪些交易。如果系统发生故障，回复过程将使用这个数据回复交易。
• 将所有的 Dirty 记录文件分页写到磁盘中 确保记录文件缓冲区会更新到磁盘中。
• 将检查点记录储存到数据库中 由于交易记录文件会被备份并删减，所以需要在交易记录文件以外保留一个检查点的记录。
设定检查点间隔
检查点间隔由 SQL Server 设定选项 复原间隔 定义。这个组态选项为整个SQL Server 系统设定，不是为单个数据库设定，但检查点在每个数据库都会执行。这个组态选项指定了 SQL Server 在系统故障时用来回复每个数据库的分钟数。默认值为 0，指示 SQL Server 为您确定检查点间隔，通常小于一分钟。对于拥有海量存储器和大量插入以及更新行为的系统，这个默认值可能导致过多的检查点数量。在这种情况下，您可以将这个组态选项设定为较大的值。如果您的使用者可以容忍系统故障时，花费较长的回复时间（例如 30 分钟），那么您系统上的交易效能将会提升。您应该根据您掌控停机时间的能力和故障的频率来设定这个组态选项。
检查点间隔还取决于交易记录文件中的记录数量。它不由系统时间或记录文件大小来决定。交易记录文件中的记录越多，检查点间隔越短。做出的变更越多，插入到交易记录文件中的记录也就越多，从而导致 SQL Server 设定检查点间隔时必须经常将变更写入磁盘。如果数据库的变更很少甚至没有的话，那么交易记录文件将只包含很少的记录，检查点间隔将会变长。
复原间隔组态选项可以透过两个途径变更：使用 Enterprise Manager 或使用T-SQL。要从 Enterprise Manager 中设定复原间隔，请在左边窗格中在需要设定这个组态选项的服务器名称上按鼠标右钮，从快捷菜单中选择 内容 进入 SQL Server 属性窗口。选择 数据库设定 页签，如图32-1所示，在复原间隔选择方块中指定需要的复原间隔，单位为分钟。
图32-1SQL Server属性窗口
要使用 T-SQL 设定复原间隔，请使用 sp_configure 预存程序，如下所示：
sp_configure "recovery interval", 1
GO
您将看到下面的输出：
DBCC execution completed. If DBCC printed error messages,
contact your system administrator.
Configuration option changed. Run the RECONFIGURE statement
to install.
在执行 RECONFIGURE 命令前，这个变更不会生效。如果确认变更，请键入下面的 T-SQL 陈述式：
RECONFIGURE
GO
RECONFIGURE 命令发出信号给 SQL Server，让它接受设定的变更。不需要为了改变复原间隔组态选项使之生效而重新启动 SQL Server。要确保您的设定确实生效，请使用下面的 T-SQL 陈述式：
sp_configure "recovery interval"
GO
输出看起来像这样：
name minimum maximum config_value run_value
------------------------- ------- ------- ------------ ---------
reconvery interval (min) 0 32767 1 1
可以看到到复原间隔组态选项已被设定。
________________________________________
注意
复原间隔组态选项是进阶选项，只有在仔细规划后才能变更。增加复原间隔设定将增加执行数据库回复时需要的时间。
________________________________________
备份方法
有数种备份数据库的方法：完全备份、差异备份、交易记录文件备份、档案群组备份和数据文件备份。每种方法都有它自己的操作方式和功能。完全备份（full backup）备份数据库、档案群组或数据文件中的所有数据。差异备份（differential backup）只备份那些自上次备份以来变更过的资料。交易记录文件备份（transaction log backup）用来备份和删减交易记录文件。（正如我们所见，备份交易记录文件是很重要的 DBA 任务，因为交易记录数据是用来和数据库备份连结的）档案群组备份（File群组 backup）和数据文件备份（datafile backup）用来备份数据库中特定的档案群组或数据文件。
所有的 SQL Server 备份都对特定的数据库执行。要完成备份，您应该备份系统中的所有数据库和它们的交易记录文件。不要忘记备份 master 数据库。记住，没有一个好的备份，在出现故障事件时，您就不可能还原您的数据。
完全备份
前面已经提到，完全备份将备份一个完整的数据库。将备份所有作为数据库一部分的档案群组和数据文件。如果您有多个数据库，您应该备份所有的数据库。对于备份小规模的数据库，完全备份可能是最普遍的技术。根据数据库的大小，整个过程可能相当的占用时间。因此，如果时间成为问题，您可能应该考虑执行差异备份或档案群组备份，这将在后面讨论。您一旦开始备份，就没有办法将它暂停，备份过程将一直继续到整个数据库完成备份。我们将在稍后 ＜执行备份＞ 一节讨论完全备份的执行。
差异备份
差异备份只备份那些自上次备份以来修改过的信息。由于它们只备份一部分数据，差异备份比完全备份速度快，而且占用较少的空间。然而差异备份的还原比完全备份更困难、也更花费时间。还原差异备份需要最近完全备份的还原，所有差异备份都自上次完全备份后产生。
交易记录文件备份
交易记录文件备份使您能够备份交易记录文件。正如在本章前面所述，这些备份对于数据库回复很重要。
档案群组备份
档案群组备份将备份与数据库中的单一档案有关的所有数据文件。这个过程和完全备份类似，它将备份数据文件中所有的数据，而不考虑数据上次备份的时间。您可以根据系统设定，使用档案群组备份来备份和特定的部门或工作群组有关联的档案群组。如果您的系统分成各个独立部门的数据并存取它们自己的档案群组，您可以按照不同的排程来分别备份每个部门的数据。
数据文件备份
数据文件备份使您能备份文件群组中的单一档案。这种备份类型和 SQL Server 2000 分别还原单一数据文件的能力一起运作。如果您每晚没有足够的时间备份整个档案群组，那么数据文件备份会十分好用，它允许您循环备份数据文件。当磁盘故障事件发生时，有某个数据文件遗失或受到破坏，您只需还原这个特定的数据文件。然而数据文件备份的时间越久，还原过程所花的时间会越长。
执行备份
您可以使用 Enterprise Manager、T-SQL 指令或 Create Database Backup Wizard来执行备份。Create Database Backup Wizard 方法是这些方法中最简单的，但是 Enterprise Manager 也是很容易使用的。另一方面，T-SQL 指令可以放置到 SQL 指令文件中，这样就可以重复使用。应该使用最合乎您需要的方法。
备份操作自身可以导向到实体装置或逻辑装置中。实体装置（physical device）是如磁带机或磁盘驱动器的对象。实体装置透过操作系统分配名称，而您必须使用这些名称来存取这些装置。由于这些预先分配的名称很难记住，您可能想要为实体装置建立一个别名或使用者自订名称。这样的别名就被称为逻辑装置（logical device）。这些的逻辑装置只存在于 SQL Server 中，并且只能由 SQL Sever 备份使用，因此也可以将它视为逻辑备份装置（logical backup device）。如果您要将数据备份到逻辑装置上，您必须预先建立这个装置。在我们讨论执行备份的不同方法之前，让我们先看看如何建立逻辑备份装置。我们将使用一个逻辑备份装置作为本节的例子。（参见系统管理员中关于在系统中增加实体装置的详细内容。）
建立逻辑备份装置
逻辑备份装置的建立有两种方法：使用 Enterprise Manager 或 T-SQL。我们将在本节中讨论这两种技术。多个备份装置的使用可以改善效能。（在本章的 ＜改善备份＞ 一节中将提供备份效能的提示。）
使用 Enterprise Manager 建立备份装置
要使用 Enterprise Manager 建立备份装置的方法如下：
1. 在 Enterprise Manager 左边窗格中展开 SQL Server 群组数据夹、Server 数据夹和 管理 数据夹。
2. 在 备份 上按鼠标右钮，然后从快捷菜单中选择 新增备份装置 ，进入 备份装置属性 窗口，如图32-2所示。
图32-2「备份装置属性」窗口
3. 只要在 名字 文字方块中键入备份装置的描述性名称， 文件名称 文字方块就会自动填入。要变更文件名称路径，可以在 文件名称 文字方块中键入新的路径，或者点选 浏览 按钮打开 备份装置位置 对话框。本例中，备份装置的名称是 Backup_dev_1。如果要增加一个磁带装置，按下 检视内容 按钮，以检视当前在磁带装置中的备份集合。
一旦完成了这些步骤，这个装置就已经可以使用了。在学习如何建立备份过程中，我们还要学习如何使用备份装置。注意，如果您没有任何连接到您的系统的磁带装置，就不能使用 磁带装置名称 选项。
使用 T-SQL 建立备份装置
要使用 T-SQL 建立一个备份装置，请使用预存程序 sp_addump-device。sp_addumpdevice的语法如下：
sp_addumpdevice device_type, logical_name, physical_name
device_type 组态选项可以是 disk、tape 或 pipe，分别表示磁盘、磁带机和连接协力厂商软件到备份系统中。logical_name 组态选项是您分配给这个装置的名称；这个名称可在 BACKUP 和还原陈述式中引用。physical_name 组态选项是系统分配的装置或文件名称。
例如，要建立一个名为 Backup_dev_2 磁盘档案的逻辑装置，请使用下面的语法：
sp_addumpdevice 'disk', 'Backup_dev_2',
'C:\MSSQL7\BACKUP\Backup_dev_2.BAK'
建立远程备份装置
为了将数据库备份到远程系统，您必须先使用系统预存程序 sp_addumpdevice来建立备份装置。您不能在远程服务器上用 Enterprise Manager 建立备份装置。为了指定远程系统，您必须像实体名称一样指定 Universal Naming Convention (UNC)的全名，如下例所示：
sp_addumpdevice 'disk', 'netbackup1',
'\\ptc4\c$\backup\netbackup1.bck'
一旦建立了这个备份装置，您就能够使用 Enterprise Manager 或者 T-SQL 陈述式来将数据备份进去。
________________________________________
说明
将数据备份到远程系统上，您必须先安装 SQL Server 来执行。如果在LocalSystem 账号之下执行，LocalSystem 账号没有存取远程系统的权利，会使得备份失败。
________________________________________
透过多重网络备份数据
您也可以透过多重网络适配卡来执行备份。透过好几个 LAN 程序段将数据备份到多重装置上，您可以克服可能限制效能的网络频宽问题。如果您正好透过两个 LAN 程序段来将数据备份到一个系统上，您就可以在 UNC 地址上指定 IP 地址，如下所示：
sp_addumpdevice 'disk', 'netbackup1',
'\\100.100.100.1\c$\backup\netbackup1.bck'
sp_addumpdevice 'disk', 'netbackup2',
'\\100.100.200.1\c$\backup\netbackup2.bck'
建立了这个备份装置，您就能够使用 Enterprise Manager 或 T-SQL 指令将数据备份在里面。
使用 Enterprise Manager 备份
在您建立了一个或多个备份装置后，您已经可以开始执行备份了。我们将首先讨论 Enterprise Manager 方法。为了避免重复，有些交易记录文件和数据库备份方法将放在一起讨论，其中可辨识两者差别的特定选项将会特别提出说明。
执行备份
要使用 Enterprise Manager 执行备份，请按照下面的步骤：
1. 要呼叫 SQL Server Backup 工具，请使用下面的技术之一：
o 在 Enterprise Manager 的左边窗格中展开一个服务器，然后展开管理数据夹。在 备份 上点选鼠标右钮，并从快捷菜单中选择 备份数据表 。
o 在 Enterprise Manager 的左边窗格中展开一个服务器，然后在 数据库 上点选鼠标右钮，并从快捷菜单中选择 所有工作 ，接着选择 备份数据表 。
o 在 Enterprise Manager 的左边窗格中展开一个服务器，然后点选 数据库 数据夹。在右边窗格中的一个数据库上点选鼠标右钮，并从快捷菜单中选择 所有工作 ，接着选择 备份数据库 。这时将出现 SQL Server 备份窗口，如图32-3所示。
图32-3SQL Server 备份窗口的一般页签
2. 在 数据库 下拉式清单中对话框的顶部区域，选取您要备份的数据库。（如果您在第一步骤中使用第三种技术，那么就已经选择了数据库的名称。）备份的名称会依据数据库的名称自动产生，可以在 名称 文字方块中键入一个备份的名称来覆写自动产生的名称。也可以在 描述 文字方块中键入一个备份说明。在您试着还原数据库时，这个说明可能会很重要。例如，如果您在删除一个数据表前立即建立了这个备份，则这个备份说明中的批注将十分有用。如果您在加载新的数据前执行备份，请将这信息包含在您的说明中。
3. 在这个对话框的 备份 区域中，必须指定执行备份的类型。可用选项将根据选择的数据库而有所不同。例如，Northwind 数据库预设 Truncate Log On Checkpoint 选项，设定这个选项会让备份程序无法使用 Transaction Log 和 File And File 群组选项。这些备份选项说明如下：
o 数据库 - 完整备份 执行一个完全数据库备份；将备份数据库中的所有数据。
o 数据库 - 差异备份 执行一个差异数据库备份；将备份自上次备份以来变更的所有数据。
o 交易记录文件 执行一个交易记录文件备份；它将同时删减这个记录文件。
o 档案及档案群组 备份单一档案群组或档案；您可以指定备份的档案群组或档案。
只能选择其中一种备份类型。要执行完全数据库备份和交易记录文件备份，您必须执行两次备份程序。
4. 在 目的地 区域，必须指定备份是到磁带还是磁盘上。点选 新增 ，可以加入更多的逻辑或实体备份装置。这时将出现 选取备份目的 对话框，如图32-4所示。在这个对话框中，您可以指定一个文件名称或从 Backup Device 下拉式清单中选取备份装置。点选 确定 ，返回一般页签。在图32-3的例子中，在 Backup To 清单中列出了两个装置。要删除一个装置，请在选择该装置后，点选 移除 。点选 内容 来检视装置的内容。
图32-4选取备份目的对话框
如果一个备份装置先前已经使用过，就可使用信息是可用的：
o 名称 这个名称由曾经执行备份的使用者选择过。
o 服务器 曾经执行备份的服务器的名称。
o 数据库 曾经执行备份的数据库的名称。
o 类型 备份的类型（完全、差异、档案群组、档案）。
o 日期 备份执行的日期和时间。
o 到期时间 该备份指定的到期时间。
o 规模 备份集合的总规模。
o 描述 备份的说明。
记住，多个备份经常能够执行到同一备份装置中。
5. 在 SQL Server Backup 对话框中的 Overwrite 区域，您可以选择覆写（overwrite）媒体（如磁带、磁盘）或者附加（append）媒体。磁盘装置通常是使用附加。但是如果您正在使用磁带，并循环使用旧的磁带，您需要删除以前的信息。虽然您可以在对话框中点选 Overwrite Existing Media 来覆写那些信息，但较好的习惯是在执行备份前先清除那些信息。采取这个预防措施有助于确保不会意外地覆写了一个磁带或磁盘装置。
6. 在 排程 区域中，可以选择稍晚才来排程备份。排程备份对于交易记录文件备份特别有用，这种类型的备份必须按照一定的时间来执行，以避免交易记录文件被填满。如果您要排程备份，选取 排程 复选框，然后点选 ... 按钮来显示 编辑排程 对话框，如图32-5所示。
7. 在 名称 文字方块中，为每个排程提供一个名称。排程的命名允许您建立多个排程（也许是每个备份一个排程）。
在 排程类型 区域中，您可以指定在 SQL Server 代理程序启动时是否自动启动备份、是否只要 CPU 闲置就启动备份、以及备份是否只执行一次或是将反复执行。如果您选择执行一次备份，您可以使用 日期 来选择备份执行日期，并使用 时间 选择方块来选择时间。
图32-5编辑排程对话框
要设定循环备份的排程，请点选 重复执行 和 变更 。这时将出现 编辑执行作业排程 对话框，如图32-6所示。
这个对话框提供您极好的排程灵活度。在 每天 、 每周 和 每月 选项中，可以安排每个工作的频率和持续时间。
图32-6编辑执行作业排程对话框
8. 点选 确定 返回 编辑排程 对话框，再次点选 确定 返回 SQL Server备份对话框，然后点选 选项 页签，如图32-7所示。在这个页签中，可以指定是否应该在备份完成时确认备份媒体，并指定是否要标示以及如何标示这个媒体。可用的选项如下所述：
o 完成时确认备份 确认备份媒体是否可读取。只确认媒体的完整性；过程中不确认资料是否已经备份。
o 备份后退出磁带 在备份完成后，将磁带从磁带装置中退出。当多个应用程序或使用者正在存取磁带装置时，该选项是有用的。这个选项可以避免您的磁带被其它人覆写。
o 移除交易记录文件中不使用的项目 在备份后删减交易记录文件。
o Check Media Set Name And Backup Set Expiration 指定媒体要被检查，并在到期前不被覆写。
o 检查媒体集名称及备份集是否逾期 允许设定媒体的到期日期。
o 备份及逾期时间 允许为媒体指定一个标示。
图32-7SQL Server 备份对话框的选项页签
9. 完成这些选项的设定后，点选 确定 ，开始执行所设定的备份。
管理备份
要检视、删除和修改您已经安排的备份工作，请按照下列步骤：
1. 在 Enterprise Manager 的左边窗格中，展开一个服务器数据夹，展开管理数据夹，展开 SQL Server 代理程序数据夹，并点选 作业 。这时已经安排的工作会列在 Enterprise Manager 的右侧窗格中，如图32-8所示。
图32-8Enterprise Manager 作业显示
2. 要删除一个作业，只要在作业名称上按鼠标右钮，并从快捷菜单中选择 删除 。
3. 要检视或修改一个作业，在工作名称上按鼠标右钮，并从快捷菜单中选择 内容 来显示属性窗口。执行您的修改，然后点选 套用 和 确定 。
使用 T-SQL 指令备份
刚开始使用 T-SQL 备份数据库比使用 Enterprise Manager 稍微难一些，但是如果您属于那种喜欢使用指令文件自动执行操作的 DBA 类型，那么这种技术应该也是您所喜欢的。TSQL BACKUP 指令也提供比在 Enterprise Manager 中的备份程序还要多的选项。本节中我们将讨论 BACKUP 指令的语法和选项。实际上有两种 T-SQL 备份指令，使用时依照您所要执行备份的类型而定。这些指令如下：
• BACKUP DATABASE 用来备份整个数据库、档案或档案群组。
• BACKUP LOG 用来备份交易记录文件。
因为这两种指令大部分共享相同的选项，所以我们将它们放在一起讨论。
执行备份
用来进行完全数据库备份的 BACKUP 陈述式语法如下：
BACKUP DATABASE database_name
TO backup_device
[ WITH options ]
这个陈述式只需要数据库名称、文件名称或档案群组名称和备份装置名称。可以包括多个文件名称或档案群组名称，中间以逗号隔开。
交易记录文件备份的陈述式语法如下：
BACKUP LOG database_name
{
[ WITH { NO_LOG | TRUNCATE_ONLY )]
}
|
{
TO backup_device
}
[ WITH options ]
这个陈述式需要数据库名称、WITH NO_LOG 或 WITH TRUN-CATE_ONLY 选项、或者是备份装置名称，然后您可以加入任何您需要的选项。NO_LOG 和 TRUNCATEONLY 选项是同义的，都将只删减记录文件，而不使用备份拷贝。
________________________________________
注意
在系统故障事件中，如果使用 BACKUP LOG 陈述式中的任何一个选项，您都将无法将数据库回复到故障点，因为没有记录文件会保存下来。不建议使用这两个选项，使用它们需要您自己承担风险。
________________________________________
在所有的三个备份指令中，database_name 是您要执行备份的数据库名称。backup_device 组态选项可以是一个逻辑备份装置名称或是实体装置名称。如果指定为实体装置，就要根据装置类型来为装置名称加上前置字 DISK=、TAPE= 或 PIPE=。您可以指定一个装置或用逗号隔开的一组装置，如下面两个例子所示：
Backup_dev_1, Backup_dev_2, Backup_dev_3
TAPE = '\\.\Tape0', TAPE = '\\.\Tape1', TAPE = '\\.\Tape2'
选项
表32-1 列出了 BACKUP 指令可用的选项。如果某个选项只能对数据库备份或记录文件备份所用，将会对这些例外作批注。
表32-1BACKUP 指令选项
选项 描述
BLOCKSIZE 实体区块大小，单位为字节。
DESCRIPTION 指定备份集合的文字说明。对于还原时定位正确的备份集合十分有用。
DIFFERENTIAL 指定一个差异备份。这个选项只在使用完全数据库备份有用。
EXPIREDATE = date |
RETAINDAYS = days EXPIREDATE 选项指定备份集合到期的日期（可以被覆写）。RETAINDAYS 选项指定备份集合到期前的天数。
PASSWORD = password 指定备份的密码。提供备份本身较大的安全性。
FORMAT | NOFORMAT FORMAT 选项指定媒体标题将被重写，因此会使媒体中的原始数据无效。NOFORMAT 指定媒体标题将不被重写。
INIT | NOINIT INIT 选项指定备份集合位于媒体的第一个档案中并保存媒体标题，但覆写媒体中的所有数据。也就是说，INIT覆写在磁带上的任何内容。NOINIT 选项指定备份附加到媒体中。如果您要重新使用磁带，您将需要使用这个选项。
MEDIADESCRIPTION = text 设定媒体集合的说明。
MEDIANAME = media_name 指定媒体的名称。
MEDIAPASSWORD = password 指定媒体集合的密码
NAME = backup_set_name 设定备份集合名称
NOSKIP | SKIP NOSKIP 选项指定在备份集合被覆写前，检查媒体中备份集合的到期日期。SKIP 选项不检查到期日期。
NO_TRUNCATE 指定在备份后不删减交易记录文件。这个选项只在记录文件备份中有用。
NOUNLOAD | UNLOAD NOUNLOAD 选项指定在完成备份后，媒体不被卸载（例如，不退出磁带）。UNLOAD 选项指定在完成备份后，卸载媒体。
RESTART 指示 SQL Server 重新启动被中断的备份。
STATS [ = percentage ] 在完成指定备份的百分率后，显示一个讯息。如果您想要检视操作的过程，这个选项将会是有用的。
请确认您指定了备份附加到媒体中，或是应该覆写媒体；您选择的选项会影响到写入磁带中数据的数量。如果您正要备份数据到一个已经使用过的磁带装置上，却没有清除这个磁带，也没有指定要覆写磁带，您将发现磁带的空间很快就用完了。在附加模式中，备份程序将只使用磁带末端的可用空间。
________________________________________
真实世界 使用BACKUP
这里有一些使用 BACKUP T-SQL 指令的例子。
下面的例子为 Example 数据库备份数据文件：
BACKUP DATABASE Example
TO Backup_Dev_1, Backup_Dev_2
WITH
DESCRIPTION = "DB backup of example",
STATS = 5
GO
备份装置是 Backup_Dev_1 和 Backup_Dev_2，并当每完成备份的 5% 就会显示统计数字。注意，在先前的例子中提供备份的说明。
如果您在一个小的数据库上测试这个例子，例如 Northwind，您看到的统计数字并不是 5% 的增量，您可能看到如 7%、16% 等的增量。这种差异的出现是因为备份程序一次读取和写入大于整个备份的 5%，这时就显示那些较大的增量。对于较大的数据集合，写入的增量将比 5% 小，所以将按照预设的显示。
下面的陈述式将备份 Example 数据库的交易记录文件：
BACKUP LOG Example
TO Backup_Dev_3, Backup_Dev_4
WITH
DESCRIPTION = "DB backup of example",
STATS = 25
GO
备份装置是 Backup_Dev_3 和 Backup_Dev_4，统计数字将显示出 25% 的间隔时间。输出结果显示已完成操作和备份结果的百分率。您将会被通知备份了多少页面、备份花了多长时间、以及备份的速度（MB/sec）。
________________________________________
管理备份
因为 T-SQL 指令 BACKUP 不在 Enterprise Manger 下执行，因此不能在 SQL Server Agent 下执行，所以您不能透过 BACKUP 指令来排程一个工作。然而您可以使用 SQL Server 排程功能来排程一个 T-SQL BACKUP 指令。一旦排程了这个工作，就能够和管理 Enterprise Manager 备份一样来管理这个工作了。
使用建立数据库备份精灵
现在让我们进入第三种执行备份的方法：使用建立数据库备份精灵。
执行备份
要使用建立数据库备份精灵来执行一个备份，请按照下列步骤：
1. 在 Enterprise Manager 中，点选您要建立备份的数据库，然后从 工具 菜单中选择 精灵 ，显示 选择精灵 对话框。在 选择精灵 对话框中展开 管理 数据夹，选择 备份精灵 ，接着点选 确定 。此时出现 欢迎使用数据库备份精灵 画面，如图32-9所示。
图32-9欢迎使用数据库备份精灵画面
2. 点选 下一步 进入 选取要备份的数据库 画面，如图32-10所示。在这个画面中，指定将要备份的数据库。图32-10显示所选的 Northwind 数据库。
图32-10选取要备份的数据库画面
3. 点选 下一步 进入 输入备份的名称及描述 画面，如图32-11所示。提供备份集合的名称和说明，在 名称 的文字方块中键入名称，在 描述 的文字方块中键入说明。如果拥有很多备份，建议键入一些说明。
图32-11输入备份的名称及描述画面
4. 点选 下一步 进入 选取备份类型 画面，如图32-12所示。选择想要执行备份的类型： 备份整个数据库、差异式数据库备份 或 交易记录文件备份 。图32-12显示选择的是 备份整个数据库 。
图32-12选取备份类型画面
5. 点选 下一步 进入 选取备份目的地及动作 画面，如图32-13所示。在 选取备份装置 区域中，指定是否要备份数据到磁带、档案或是一个特定备份装置上，如果需要的话，请在适当的文字方块中键入文件名称或装置名称。在 属性 区域中，指定是否应该覆写或附加备份媒体，在备份后是否要弹出磁带（如果您使用磁带），以及是否应该确认备份的完整性。确认备份的完整性是很好的主意，因为坏的磁带可能导致整个备份失效。SQL Server 透过读取磁带并确认所有数据是可读取的来确认备份的完整性。
________________________________________
说明
建立数据库备份精灵只允许选择一个备份装置，这将彻底影响到备份效能，我们在本章的 ＜改善备份＞ 一节中看到。由于这个原因，Enterprise Manager 备份方法比建立数据库备份精灵更适合使用。
________________________________________
图32-13选取备份目的地及动作画面
6. 点选 下一步 进入 备份确认与排程 画面，如图32-14所示。这里有确认媒体标示和设定到期日期的选项，如在 ＜使用Enterprise Manager备份＞ 一节中的说明。您也可以使用 编辑排程 对话框来将备份排程在稍后的时间执行，前面曾说明过（如图32-5所示）。
图32-14备份确认与排程画面
7. 点选 下一步 进入 完成建立数据库备份精灵 画面，如图32-15所示。检查文字方块中的信息，并点选 Finish 来执行这个备份。
图32-15完成建立数据库备份精灵画面
管理备份
如果使用建立数据库备份精灵，只能执行备份或建立一个定期的备份作业。如果建立了一项作业，必须使用 Enterprise Manager 或 T-SQL 来管理作业。管理作业在本章的 ＜使用Enterprise Manager备份＞ 一节中已经简要说明。
追踪备份
当您执行一个备份时，不管是透过 Enterprise Manager、T-SQL 或建立数据库备份精灵，都将保存一个备份的记录。这个记录作为一列储存在 msdb 数据库的 backupfile 数据表中。在数据库回复时，这些信息用来确定数据库是在何时执行的最后一次备份。其它信息，例如备份集合 ID、被备份的文件名称等等也被储存。因此系统数据库定期进行备份是很重要的，这样在需要时，便能够获得回复的信息。
排程备份
排程备份是非常主观的任务。很多因素将会影响到设计备份排程。由于在备份过程中，系统效能将会降低，所以备份应该限制在业余时间进行。在本节中，我们将回顾几个诀窍，这些诀窍可以帮助您设定一个备份排程。记住，即使备份影响了系统的效能，它们仍然是必须进行的关键操作，它们可以防止系统出现数据丢失。
备份排程秘诀
下面的诀窍可以协助您决定系统的理想备份排程：
• 计划完全备份在业余时间进行 如果您的公司不是 在7-by-24 环境（每周7天，每天24小时）中执行，那么业余时间将是执行备份的最佳时间。
• 每隔几天做一次完全备份排程 如果您的数据库很大，而您不能在指定的时间执行完全备份，那就将备份操作分成几个区块。每次您可以执行数据库中一个区块的档案或档案群组备份。几天之后您就备份了所有的数据。
• 使用差异备份 如果您不能每晚都提供时间来执行完全备份，那么您可以在一周中执行差异备份，在周末的时候执行完全备份。
• 自订备份计划 每个系统都是不同的，每个公司也都是不同的。设计最能符合您需要的备份排程。
________________________________________
真实世界规划备份
这里有几个备份规划的范例，可能有助于您开发您自己的备份排程：
• 5-by-8环境中的小系统 这种类型的系统通常允许每晚的完全备份。根据交易记录文件的大小和完成的交易数量，交易记录文件每天只需备份一次。
• 7-by-24环境中的中等规模系统 执行在 7-by-24 环境的中等规模系统不允许大量备份的停机时间。然而，如果您的系统是这种规模，可以在周末时执行完全备份。备份的排程范例如下：
周一差异数据库备份
周二 差异数据库备份
周三差异数据库备份
周四差异数据库备份
周五差异数据库备份
周六差异数据库备份
周日完全数据库备份
每天根据需要的交易记录文件备份
• 7-by-24环境的大规模系统 大规模的系统可能不允许在一天内完成完全备份。折衷的办法是将完全备份分到几天当中完成（在这个例子中，分到周六和周日）：
周一差异数据库备份
周二差异数据库备份
周三差异数据库备份
周四差异数据库备份
周五差异数据库备份
周六完全档案群组备份
周日完全档案群组备份
每天根据需要的交易记录文件备份
这个信息是要为您提供如何排程备份的方法。由于每个系统和系统要求都是不同的，只有您才能决定最佳的排程备份。
________________________________________
改善备份
使用一些简单的技术，您就可以改善备份的效能和备份的执行。在本节中，您将学到其它增强效能以及改善备份的诀窍。
增强备份效能
增强备份效能是很重要的主题，这是因为备份执行的越快，在备份过程中 SQL Server 效能降低的时间越短。下面的技术将帮助您改善您的备份效能，并且在某些情况下也能帮助改善还原效能。（数据库还原将在 第 33 章 中讨论。）
• 使用多个备份装置 拥有多个备份装置使得 SQL Server 能够同时执行多个备份操作。这是透过 SQL Server 将备份划分到几个装置中达成的。为了建置这一点，SQL Server 根据数据文件的数量和备份装置的数量建立了大量的执行绪。备份效能同时也透过额外的执行绪得以改善，这些额外的执行绪被用以写入数据到这些装置中。同时执行操作减少了这些操作花费的时间总量，特别是在多处理器的系统中。这项技术将同时改善备份和回复效能。
• 在数据库中使用多个数据文件 在数据库中使用多个小数据文件，而非一个大的数据文件，这样 SQL Server 就能够同时执行更多备份。这项技术将同时改善备份和回复效能。
• 使用多重LAN程序段来执行备份 透过将备份分割成多重 LAN 程序段，您可以增加备份的网络频宽。如两个 LAN 程序段提供双倍频宽，三个区段提供三倍频宽等等。
• 阶段（stage）备份 要改善备份的效能，您可以执行这个备份作为磁盘备份，然后将磁盘备份文件拷贝到磁带机中。这种方法可以改善效能，因为磁盘比磁带快，而且它还能在磁盘上保存最新的可用备份。但这项技术只有当备份文件仍留在磁盘上时才能改善还原的效能。
• 使用差异备份 差异备份可以改善每个备份的效能，但是在还原整个数据库时将花费更长的时间，您将在 第 33 章 中看到。如果无法接受备份的时间过长，那么这种方法可以为您的系统提供最佳解决方案。如果您需要还原资料的机会很少，这种风险是可以接受的。
其它诀窍
下面关于执行备份的诀窍也许可以套用到您的个人环境中：
• 离开工作储存备份 如果您在工作站之外储存备份，这样备份就能在诸如火灾或洪水的灾难中保存下来。备份数据比计算机系统本身要重要的多。
• 确认备份 备份不可能总是好的。磁带可能变质，特别是您一次次的重复使用同一个磁带时更是如此。透过确认备份（至少有时候），您至少可以知道磁带是好的
• 不要每天重复使用同一备份媒体 每天重复使用同一备份媒体，您可能无法还原几天前删除的数据。循环使用备份磁带，这样您至少可以还原过去几天的信息。
• 保留记录 您应该制作使备份运作以及必要时如何重建系统的档案。记住，不可能总是您自己去重建系统。
• 备份系统数据表 记住定期备份系统数据库，例如 master、msdb 数据库。
这些诀窍是用来帮助您开发您自己的备份策略。每个系统是不同的，且每人的需求是不同的。再一次说明，您必须开发适合您的策略。
本章总结
在本章中，您学到了 SQL Server 记录文件是如何工作的、如何使用检查点来缩短数据库还原的时间，您学到了执行 SQL Server 备份的基础知识、以及完全备份和差异备份、数据库备份和交易记录文件备份之间的差别，您还学到了如何排程和改善您的备份。在 第 33 章 中，我们将继续讨论关于数据库备份、还原和回复，您将学到如何还原数据库、以及如何规划损坏回复。
