• 项目

SQL Server

了解 SQL Server 备份

Paul S. Randal

 

一眼：

  • 完全备份
  • 事务日志备份
  • 差异备份
  • 规划备份策略和备份的完整性

内容

完整备份
差异备份
事务日志备份
规划备份策略
备份的完整性
摘要

您真的需要进行 SQL Server 备份吗？ 是。 除非您并不关心您的数据，或者您不介意完全重新创建数据库发生的灾难需要某种方法将数据库还原到一个可用的点。 有些人认为有一个冗余数据库副本的其他位置删除需要有备份，但如果的复制已损坏或不可访问吗？ 备份是仍然需要以确保您始终可以恢复。

但是，您应该采取哪种类型的备份？ 频率您需要它们? 它们将在数据库和工作负荷上有什么效果？ 以如何执行，确保它们是有效？

将放在一起备份策略是实际上比您可能认为容易的即使备份和还原命令有一个大量的选项。 我将帮助您将其所有签出的图。

这是在第一个系列文章中一个由三部分。 此处的第 1 部分我介绍备份。 第 2 部分中 （9 月 2009年问题），我将讨论使用备份为灾难恢复。 ，并在部件 3 （11 月 2009年问题），我将在查看从备份没有灾难恢复。 我要进入有点比通常这些文章中, 更深层次，但您应该能够按照背景材料的帮助。

本月本文我将介绍如何的基础知识各种类型的备份工作并且如何可能想要在备份策略中使用它们。 如果您有一些事务日志是如何工作 （请参阅我的文章"的知识，它将帮助 了解日志记录和 SQL Server 中恢复." 还有没有点有备份，如果他们发现当您试图使用它们，因此我还将介绍如何添加一些完整性检查它们可能已损坏。 同时，我将一些常见的 misconceptions debunk，提供进一步的信息的链接。

我不打算执行的一点是说明备份语法的工作原理以及如何执行各种备份类型。 SQL Server 联机丛书有极好涵盖这是为什么浪费空间此处复制该节？ 请参阅主题" 备份 （处理 SQL）为"详细信息时尤其是在示例末尾一节。 主题" 备份和还原操作方法主题 （SQL Server 管理 Studio）"说明如何使用工具来执行备份。 因此，最好后阅读此文章，检查，操作方法，如这里我将解释内容和该原因。

备份策略的实现是相对简单部分。 设计一个有效的策略是在非常重要的但经常被忽视部分。

完整备份

最简单类型是备份的完整数据库备份。 也可以为单个数据文件或文件组的完整备份的。 但是，这些不常使用，讨论的所有原则应用于这些，太，我将焦点上数据库级备份。 但 SQL Server 2005 的每个更精细的备份类型完全相同 （不是真正 SQL Server 2000 中）。 同样适用于差异备份 — — 他们可执行文件、 文件组或数据库级别上 — 但这些相同的所有工作方式，以及，而不考虑该组件的都备份。

完整数据库备份提供了数据库的完整副本，并提供一个单个点的时间，可以还原数据库。 即使它可能需要许多小时运行备份过程，可以仍然只还原备份到单个数据点 （有效末尾的在备份，但我将讨论确切的是本文后面）。 完整备份不允许恢复到任何点中的时间运行备份时。 这也是相同的差异备份。

没有有关此，但是，通过这一事实可以使用的 STOPAT fuelled 一个误解 = < 时间或日志序列号 > 完全备份和差异备份的还原选项。 尽管该语法使得，选项不起作用，只是有为方便起见。

有关完整的备份的另一种误解是它们只包含数据。 完全备份和差异备份也包含某些事务日志记录，以便还原的组件 （数据库、 文件或文件组） 进行事务性一致。

请考虑一个具有单个非聚集索引的表中插入一条记录的一个示例事务。 数据文件通过扩展的表和索引页。 在事务内部拆分为两个部分： 一个记录中插入表和插入在非聚集索引中的索引页中所需记录的数据页。 如果只备份过程中发生读取之前，记录插入非聚集索引页，但记录插入后读取表数据页，表示只是在备份中数据的数据库是事务性不一致的。

这是事务日志播放进入。 通过在备份中，还包括某些事务日志记录，恢复可以还原的副本的使得事务性一致的该数据库上运行。 此示例交易记录根据时提交，恢复部分还原可能滚它 （这意味着它将显示为已提交已还原数据库的副本中） 或回滚它返回 （表示它将不会出现在所有在中还原的数据库的副本）。 在这两种情况下，维护事务的一致性以至关重要的。

完整备份执行以下操作：

  1. 强制数据库检查点，记在的日志序列号此时。 这将刷新到磁盘之前，任何读取备份帮助最小化的还原的恢复部分已执行的工时量的所有更新的内存中的页面。
  2. 从数据库中的数据文件中开始读取。
  3. 停止读取数据文件和生成记录的最早的活动事务在该点开始的日志序列号 （请参阅我的文章"Understanding Logging and Recovery in SQL Server"这些术语的解释）。
  4. 读取是需要尽可能事务日志。

说明必需的程度的事务日志是最佳完成与 图 1 中视觉帮助的。 在时间线上红色数字说明在此列表中：

  1. 检查点和开始从数据库读取。
  2. 读取的操作读取第 X 页。
  3. 事务 A 开始。
  4. 事务 A 对第 X 页进行更改。 该副本在备份中的现在已过时。 请注意，备份将不读取页 X 再次 — 它的数据库中已传递的点。
  5. 将启动事务 B。 它不读取数据的操作完成之前会完成。
  6. 提交的事务 A。 这可以提交所做的更改对第 X 页。
  7. 读取备份数据的操作完成并开始读取的事务日志。

fig01.gif

图 1 示例的更改在一个完整备份的时间线

备份事务日志的足够是所需，以便可以成功地运行恢复在还原过程中，以使数据库中的所有页相同的点处的时间，时间的数据读取的部分备份操作完成 （点 7）。 要求为允许恢复到运行的事务日志从最早的活动 （或未提交） 事务 （5 点） 事务 B 开头到末尾的备份 （点 7）。 若要允许所有页被引入到同一点时间需要从备份检查点 （点 1） 事务日志备份 （点 7） 的末尾。

如果只从包含事务日志的最早的活动事务 （点 5） 开始，然后页面已从备份还原 X 读取在点 2 的副本将不会更新与从事务 A，点 4 上发生的更改。 这意味着它将不会事务性一致时间读取的数据操作完成 （点 7） 的数据库的其余部分。

因此，完整备份中包含的事务日志的在最小的日志序列号 (LSN) 是最小 （备份检查点的 LSN，最早的活动事务的 LSN），它可能是由于为开始，甚至在开始备份之前的交易记录。 这可以确保还原的数据库的副本 （或您所还原的任何 — 页、 文件、 文件组、 数据库） 是完全一致的。

此机制意味着尽管可能在数据库上额外的 I/O 工作负荷会降低它们有点交易记录不由备份的操作暂停以任何方式。 此机制的不利方面是事务日志不能因为它是需要清除的完整备份持续时间内。 如果还有大量更新活动的并且完全备份需要长时间才能完成这可能导致事务日志的增长，我已经讨论在几个以前的文章和 SQL 问答列中的一个问题。

完整备份中包含数据不一定是所有的所有数据文件的内容。 备份将只包含数据文件中的分配的页。 例如，单文件数据库可能是 100 GB，但只包含已分配的数据的 15 GB。 在这种情况下完全备份将只包含已分配的数据在 15 GB 加上必要的事务日志。 （但是，还原的数据库将始终保持相同的大小与原始 — — 在此情况下 100GB）

另一种误解是备份过程中检查或更改其备份的数据。 这是 untrue，除在单个的情况下，备份的校验和启用时，将稍后解释。

差异备份

其他类型的数据是备份的差异备份。 差异备份执行相同的操作作为一个完整的备份，但仅包含已更改或自上一完整备份以来已添加的所有数据。 一个常见误解是增量差异备份。 它们实际累计和连续的差异备份完整备份后以及将增加的大小更改或添加更多的数据时。

在每个 4 GB 有每个数据文件的部分 （称为一个 GAM 间隔） 是特殊的数据库页称为差异的位图跟踪 （称为扩展盘区） 的部分，4 GB 节的最后一次完整备份，指出已更改或被添加到数据库的数据以来发生更改的。 （有几个其他分配位图，太，并且您可以找到有关在我的博客文章中的详细信息" 内部的存储引擎： GAM SGAM，PFS，其他分配映射").

差异备份扫描通过这些位图，并将只备份数据文件标记为已更改的扩展盘区。 通过在下一次完整备份，以便可以看到，越来越多地对数据库更改多个它将标记中差异的位图和连续的差异备份将较大和更大，位图是重置。 最终，如果数据库的大多数更改差异备份可能完全备份一样大。 您可以找到如何大下一次差异备份将使用一个我编写的脚本可以从我的博客文章" 新的脚本： 数据库中有多少以来发生更改上次完全备份吗？." 顺便说一下，此脚本还可了解数据库的改动率例如，在 SharePoint 内容数据库。

作为一方说明，如果您要采取的特殊的完整备份和不具有其重置差异的位图中，您应使用 BACKUP 语句在的 COPY_ONLY 选项。 这是非常有用，否则为下一个差异备份将基于在特殊的完整备份拍摄，而不是常规的 （可能是计划的） 完整备份。 当您试图在进行灾难恢复时，可能导致大问题。

那么为什么是差异备份有用呢？ 我将讨论在备份策略部分中，如差异备份可以真正加快还原操作，从而在还原过程中跳过的多个事务日志备份。 实质上是向前跳使用差异备份比为必须重播事务日志记录大量的时间获取到同一点的时间更快的。

事务日志备份

事务日志备份是只可能满或 $ BULK_LOGGED 恢复模型中，而完全备份和差异备份也是可能在 SIMPLE 恢复模型中。

事务日志备份包含自上次日志备份后生成的所有事务日志记录 （或启动一个日志备份链的完整备份），用于允许数据库恢复到某个特定点的时间 （通常该时间之前灾难 strikes 右）。 这意味着它们是渐进式与不同的是累积性的差异备份。 由于这些增量，如果想要在数据库还原到某一特定点的时间，您将需要对所有事务日志记录最多可重放的数据库更改所需的时间点。 这些都包含在日志备份链中。

日志备份链是包含所有事务日志记录将数据库恢复到一个点的时间所需的日志备份的连续的系列。 链启动使用完整的数据库的备份，并一直内容中断因此防止多个日志备份的另一个完整或差异备份之前的该链。

鎿嶄綔破坏日志备份链鍖呮嫭切换为简单恢复模型，恢复从数据库的快照强制清除使用的 NO_LOG 或 TRUNCATE_ONLY 选项不在 SQL Server 2008 中可用） 的日志。 是中断日志备份链 inadvisable 它强制另一个 （可能大） 完整备份执行。

虽然一个日志备份链拉伸到完整备份，您不必还原恢复过程中的所有这些日志备份。 如果您执行完整备份，说，在星期天晚上和星期三晚上，使用日志备份后星期天晚上，每个半小时然后还原该数据库在发生灾难后的可以使用星期三的完整备份加上所有日志备份后的星期三晚上，而不是一直转回到星期天晚上的完整备份。 （在第二个系列文章中我们将进入深本主题）。

日志备份还需要帮助管理事务日志的大小。 满或 $ BULK_LOGGED 恢复模型中日志备份已执行 （请参见什么日志清除，意味着相应二月份的文章的详细信息），以防止在日志文件增长的控件，必须执行定期日志备份之前将不清除日志。 如果日志不能清除，用尽空间之前，会增加日志。 在这种情况下，如果您不想使用日志备份的时间点恢复，最简单的选项是切换到简单恢复模型，并不使用满或 $ BULK_LOGGED 恢复模型。 我讨论这在日志中更有深度" 正确的事务日志大小管理的重要性."

中作为运行最小日志记录的操作记录仅在页面分配了在不实际的数据插入某些操作，从而提高性能，日志记录时，没有一种特殊情况。 这可以提高操作 （如大容量装载的性能，并且索引重建。 有关该操作不都将在这些情况下，记录，因此备份日志记录不包含完全重播操作的足够信息。 在这种情况下可以还原和恢复可能如何如果没有足够的信息？

答案是一个最小日志记录操作之后第一次日志备份还包含一些数据。 就像前面提到的这些差异位图，没有名为最小日志记录位图 （有时称为更改大容量的映射） 的另一个位图。 此位图跟踪由于最小日志记录操作的已更改的数据文件的扩展盘区。

下一个最小日志记录操作的日志备份将扫描通过这些位图，并还备份那些标记为已更改的数据范围。 该位图会清除后被扫描。 这意味着日志备份有信息不足以完全还原日志备份时重放数据库中, 最小日志记录操作的效果。 还有一个曲折但： 出现在任何特定的数据范围已更改时，该日志备份什么。 使时间段介绍的末尾之外的时间，也包含从最小日志记录操作的数据的日志备份无法还原到任意点 （或以后，如果日志备份是您正在还原从一个日志备份链的一部分）。 因此时切换到 BULK_LOGGED 恢复模式时您可以获得性能改进，, 您必须考虑改为一个临时的操作仅以提高您的批处理过程并且批处理完成后应切换回满尽可能快地执行日志备份。

此外，还有特殊情况的日志备份以允许将日志备份后损害了数据文件的灾难。 这称为尾部的-在的登录 （或日志尾部的） 备份，在数据文件可以损坏或破坏，但到灾难所导致的所有事务日志可以被都备份。 这允许最小的工作丢失 （称为最新的恢复） 随后还原数据库 ； 但是，它支持只在数据库完全恢复模型中运行时。 联机丛书主题中可以找到更多有关这些和最小日志记录操作的限制" 尾日志备份." 第一个屏幕本文附带的强制转换，显示演示尾部的-在的日志备份。

版本 prior to SQL Server 2005 SQL Server 中, 事务日志备份不能执行完整数据库或差异数据库备份与一同 — — 它们会阻止直到完成数据库级备份。 文件和基于文件组备份不会导致阻止日志备份。 时这很复杂的文件和文件组备份恢复过程，它给它们的好处通过不阻止日志备份。 在 SQL Server 2005，所有完全备份和差异备份 （无论组件） 中使用相同的方式 现在，行为是并发事务日志备份完成，但完整前不清除事务日志或差异备份 （即要求日志） 还完成。

规划备份策略

既然确信有关三种类型的备份和它们的工作方式我将向您展示如何您可能将它们放在一起到备份策略。

得到的一个常见问题是如何开始考虑备份策略。 始终要说您不应设计备份策略。 您应该设计还原策略），使您能够还原尽可能小的事件的发生灾难因此您的停机时间尽可能地小，同时仍然保留您的数据。 您已经使用的出后，然后工作出您需要什么需要使您可以执行该还原的备份。 换而言备份策略应允许您以满足您的恢复时间目标 (RTO) 和恢复点目标 (RPO)。

仅包含完全备份的策略与您一定程度上您的与还原可以做什么限制。 基本上，您可以只还原到的 图 2 中的为每个完整备份时间。 如果灾难 strikes 23:59 在星期六时，只是计划下一次完整备份之前，然后自上次完全备份以来的所有工作可能都会丢失。 由于这个原因如果需要避免数据丢失，并且无法重新创建数据日志备份还有包含，如 图 3 所示。

fig02.gif

图 2 仅完全备份的备份策略

fig03.gif

图 3 与完全和日志备份的备份策略

设想一下在进行日志备份的每隔 30 分钟。 只要所有备份可用，这意味着数据库可以还原到任意点的时间。 但是，这仍可能不是最佳的策略。 如果灾难 strikes 23:59 在星期六与此策略的位置吗？ 第一件事就是需要一个尾部的-在的日志备份，并启动还原。

将数据库还原到的灾难意味着还原最后一个星期日的完整备份，然后 336 日志备份 （的六天的每一天，再加上星期六 47 48 日志备份加上尾部的-在的日志备份）。 根据多少改动时在数据库中上一周的大量将需要很长时间才能重播事务日志。 这显然不的最佳恢复策略，但它在字段中看到一个公共策略。 如果您有这样一种策略，请确保您已执行您知道是否可以在发生灾难的满足您的 RTO 这样还原。

缓解此问题，一些策略使用更频繁地完全备份，但这些可能很大，以每一天，为例。 另一种方法是使用差异备份只包含上一次完整备份以来发生更改的数据。 在继续我们的示例该策略是图 4 所示。

fig04.gif

图 4 使用完整、 日志和差异备份的备份策略

这一策略在星期六 23:59 灾难恢复是很多更快。 请记住差异备份是累积，因此恢复策略是星期日完整备份、 00: 00 星期六差异备份，以及从星期六的所有日志备份。 有差异备份从 00: 00 星期六意味着之前的所有日志备份可以跳都过，包含差异备份与还原所有的网络的结果相同日志备份。

这是一个非常简单，并刻意示例，但它清楚地显示每个备份类型的优点。 一旦在设计备份策略确保您的测试以确保它允许您执行您所需的还原。

下面是示例我看到一个客户图符回几年。 在客户有一个损坏的数据库，并想要恢复的零数据丢失。 它们都不愿意使用其备份并尝试运行修复一个数据库副本的但它必须删除这些强制使用其备份的数据。 证明他们必须从一月完整备份加上一个日志备份到四月的每个 half-hour — 超过 5，000 的备份中汇总和磁带上的所有! 我确信您是滚动您的眼睛并且想"我敢打赌它没有运行，"但实际上它是 ； 但是，花费执行该操作的三天 ！ 客户认为它们有一个很好的备份策略 — 完全恢复模型以及日志备份，但其备份策略不允许其执行他们需要在还原的操作。

备份的完整性

这里有备份，如果您发现它们是损坏当您尝试从这些恢复时没有点。 当然，最好检查备份的有效性是其他的服务器上对其进行还原，但 SQL Server 2005 中引入的一项新功能是允许某些备份的完整性检查进行而不必实际将其还原。 可以使用的 CHECKSUM 选项时执行备份 （任何形式）。

这将创建一个校验和整个备份流，存储在备份本身上。 如果备份是一种完整或差异，并且数据库启用页面校验和，然后此选项也会导致所有现有页面校验和与备份过程中读取页进行测试。 如果找到一个坏页校验和是，则备份操作将失败。 这提供对意外备份的已以某种方式损坏数据库的好保护。 （可以找到有关页面校验和的详细信息"前提示的有效数据库维护"文章中从 2008 年 8 月）。

备份完成后它可以验证使用如下命令：

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

这将重新计算整个备份流上的校验和，并对存储在备份中进行比较。 进行完整和差异的备份它还将在备份中测试页面上的任何页面校验和。 如果任何问题找到然后您知道该备份已以某种方式被损坏。

自然，有该例外规则，您可能希望将损坏数据库备份 （如果它的数据库必须和您不得不实例运行修复，仅副本）。 在这种情况下，可以强制使用的 CONTINUE_AFTER_ERROR 选项来完成备份。

可以在找到有关备份有效性的详细信息 备份我的博客上的验证信息然后还观看我演示在第二个屏幕转换本文附带的备份验证的某些方面。

摘要

与任何复杂主题有很多方面的没有空间来覆盖，备份，但现在，包括基础知识，您可以深入一些更深入的信息的联机丛书和网络日志链接。 在联机丛书中启动最佳位置是主题" 备份的概述 （SQL Server）." 在我的博客上您可以从开始， 备份/还原类别.

您可能认为的一个区域是明显的其缺勤是压缩的备份。 这是故意我将被覆盖它 SQL Server 2008 中的所有新压缩技术文章中一年中更高版本。 在此期间可以签出联机丛书主题" 备份的压缩 (SQL Server）还在 我的博客.

如果我不得不在本文中三个项目符号点汇总，它们会：

  • 请确保您有备份。
  • 请确保您有有效的备份。
  • 请确保您具有正确的备份。

换而言采用备份如果您想要还原您的数据库请执行内容以便您了解备份将运行时您需要您可以从备份还原确保满足您的 RTO 和 RPO。

下一个本文我将说明有关从备份还原不同类型的还原操作以及它们如何工作，包括从多个备份和部分数据库可用性还原。

在此期间以及始终，如果有任何反馈或问题，放我行在 Paul@SQLskills.com。

Paul S。 Randal 是在管理 SQLskills.com 主管、 SQL Server MVP 和 Microsoft 区域主管。 他从事 SQL Server 存储引擎小组在 Microsoft 从 1999年 2007年。 Paul 编写 DBCC CHECKDB/修复 SQL Server 2005 但负责，核心存储引擎 SQL Server 2008 开发过程中。 Paul 是灾难恢复、 高可用性和数据库维护方面的专家，常规演示者在世界各地的会议大小写。 在他博客 SQLskills.com/blogs/paul.