快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

数据库部分备份和还原

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

在他的《 SQL备份和还原》一书的本示例章节中,Shawn McGehee讨论了部分备份,如何使用它们以及如何从部分备份进行还原时避免潜在的问题。

部分备份与文件和文件组备份相似,因为它们允许我们仅备份组成数据库的数据文件的一部分。但是,尽管文件和文件组备份允许我们备份特定的单个文件和文件组,但是部分备份将为主文件组和所有读/写文件组进行备份,默认情况下会省略任何指定为READONLY的文件组。这意味着部分备份仅与包含只读文件组的数据库有关。否则,部分备份将捕获与等效的完整数据库备份完全相同的数据和对象。

部分备份在SQL Server 2005及更高版本中可用,旨在减少包含大量只读数据的大型数据库的备份占用空间。毕竟,为什么每天晚上知道已知数据都无法更改(因为它处于只读状态)时才备份相同的数据?我们不会或不应该定期备份该段数据。

在本文中,我们将讨论:

  • 为什么部分备份适用于备份方案和还原方案
  • 如何执行部分和差异部分备份
  • 如何还原采用部分备份策略的数据库
  • 部分备份的潜在问题以及如何避免它们

为什么要进行部分备份?

部分备份使我们能够定期备份数据库中仅读写对象和数据。默认情况下,部分备份中不会捕获存储在只读文件组中的任何数据和对象。我们可以通过捕获每个读写文件组的单独文件备份来实现此效果。但是,假设我们有一个不需要时间点还原支持的数据库。无论如何,在执行基于文件的备份时都需要事务日志备份,因此这可能表示不必要的复杂备份和还原过程。

对于部分备份,我们仅在需要进行时间点恢复时才需要进行事务日志备份,因此它们非常适合与SIMPLE恢复模型数据库一起使用,以将数据库备份缩减为更易于管理的大小。 ,而不会增加日志备份的管理开销。注意,部分备份对以任何恢复模式运行的数据库均有效;只是它们是专门为简化包含很大一部分只读数据的大型SIMPLE恢复模型数据库的备份而设计的。

那么,在什么情况下我们想对基础架构中的数据库采用部分备份?假设我们有一个针对社区中心及其公共类的SQL Server支持的应用程序。该数据库保存学生信息,班级信息,成绩,付款数据和有关课程的其他数据。在每个季度末,一组课程完成,然后开始一组新课程。一旦将当前季度课程的所有信息输入系统后,在整个课程生命周期中就只能轻而易举地处理数据。讲师可能每周更新几次成绩和出勤率,但是数据库在一天中不是很活跃。当前课程完成后,在本季度末,信息将被存档,并保留以用于历史和审计目的,但不会进行任何进一步的更改。

这种数据库是部分备份的理想选择。“实时”课程数据将存储在读写文件组中。每三个月,可以将这些数据附加到一组存档表中,以供将来报告和审核,并存储在一个只读文件组中(此文件组将暂时切换为读写状态,以运行存档过程)。我们可以通过将所有数据从活动表移动到存档表中的方式,以传统的数据附加方式执行此归档,也可以通过使用分区功能来简化此过程。

存档过程完成并且导入了新的课程数据后,我们可以对整个数据库进行完整备份并将其存储在安全的位置。从那时起,我们可以采用一个时间表,例如每周部分备份和每天的差异部分备份。这样,我们不会浪费任何空间或时间来备份只读数据。

同样,以SIMPLE恢复模型操作此数据库也是可以接受的,因为我们知道,一旦加载了初始课程数据,就不会对实时课程数据进行更改,因此可以忍受一天的潜在数据丢失。

在我们的示例中,每三个月只进行一次完整备份似乎不太常见。相反,我们可以考虑每月进行一次完整备份,以提供一些额外的保险,并简化还原过程。

执行部分数据库备份

在大多数DBA的工作场所中,部分备份将是所有备份类型中使用最少的,因此,我们无需遍历两个单独的示例,一个用于本机SQL Server备份命令,一个用于SQL Backup,我们仅通过一个示例进行工作。使用本地T-SQL命令进行部分备份和还原的方法,因为SSMS或维护计划向导均不支持部分备份。将介绍与SQL Backup(我的组织用于备份的工具)等效的命令,但不在完整示例的上下文范围内。

准备部分备份

清单1显示了使用多个数据文件创建DatabaseForPartialBackups数据库的脚本。主要数据文件将保存我们的读写数据,而次要数据文件将在名为Archive的文件组中保存我们的只读数据。创建数据库后,我们立即使用SIMPLE恢复模型对其进行更改。

清单1:创建DatabaseForPartialBackups测试数据库

该脚本非常简单。最后,Archive文件组将设置为只读,但是首先我们需要在该文件组中创建一些表,并用数据填充其中的一个表,如清单2所示。

清单2:创建MainData和ArchiveData表并填充MainData表

本示例的最后准备步骤是模拟归档过程,将数据从MainData表复制到ArchiveData表,将Archive文件组设置为只读,然后从MainData删除已归档的数据,然后插入下一组“实时”数据。

在运行清单3之前,请确保没有其他查询窗口连接到DatabaseForPartialBackups数据库。如果存在,则辅助文件组到READONLY的转换将失败,因为在更改文件组状态之前,我们需要对数据库具有独占访问权限。

清单3:数据归档和辅助数据加载

最后,在进行第一次部分备份之前,我们希望捕获整个数据库的一个备份副本,包括只读数据,作为任何后续还原操作的基础。我们可以在进行完整的数据库备份之前进行部分备份,但是在启动部分备份例程之前,我们确实要确保数据库具有可靠的还原点。因此,清单4对我们的DatabaseForPartialBackups数据库进行了完整的数据库备份。这样做之后,它还会向MainData中插入更多数据,以便我们在以后的部分备份中可以捕获新数据。

清单4:DatabaseForPartialBackups的完整数据库备份,以及第三次数据加载

完整数据库备份的输出如图1所示。请注意,正如预期的那样,它将处理我们的两个数据文件以及日志文件。

图1:完整数据库备份的输出

使用T-SQL进行部分数据库备份

现在,我们准备执行我们的第一次部分数据库备份,该备份将捕获在我们的第三次数据加载中插入的数据,如清单5所示。

清单5:DatabaseForPartialBackups的部分备份

此备份命令与清单4所示的完整数据库备份命令之间的唯一区别是增加了READ_WRITE_FILEGROUPS选项。该选项使SQL Server知道该命令是部分备份,并且仅处理数据库中包含的读写文件组。

输出应类似于图2所示。注意,这次仅处理主数据文件和日志文件。这正是我们期望看到的:由于我们不处理任何只读数据,因此我们不应在第二个备份命令中看到该数据文件正在被访问。

图2:部分​​备份结果

使用T-SQL的差异部分备份

就像我们可以有差异数据库备份(指的是基本完整数据库备份)一样,我们也可以进行差异部分数据库备份(指的是基础部分数据库备份),并且仅捕获读写数据文件中更改的数据。 ,因为已进行基本部分备份。

在运行差异部分备份之前,我们需要处理一些新数据。

清单6:第四次数据加载,为部分差异备份做准备

清单7显示了运行我们的部分差异备份的脚本。一个重要的区别是包含了WITH DIFFERENTIAL选项,该选项将命令从完全部分备份转换为差异部分备份。

清单7:执行部分差异备份

完成此命令后,继续并检查“消息”选项卡中命令的输出,以确保仅处理了正确的数据文件。现在,我们已经完成了部分备份,现在可以继续进行还原示例。

执行部分数据库还原

我们将执行两个还原示例;一种是使用完整数据库和完整的部分备份文件将DatabaseForPartialBackups数据库恢复到第三次数据加载之后的状态,另一种是使用完整数据库的完全部分备份将数据库恢复到第四次数据加载之后的状态和差异部分备份文件。

恢复完整的部分备份

清单8显示了还原过程中的两个简单步骤。第一步是还原完整的数据库备份文件,该文件将还原读写文件组和只读文件组中的数据和对象。在此步骤中,我们包括NORECOVERY选项,以便SQL Server使数据库处于可以应用更多文件的状态。这很重要,因此在应用部分备份之前,我们不会关闭在线且可用的数据库。

第二步还原完整的部分备份文件。这将用备份文件中的数据覆盖现有数据库中的读写文件,该文件将包含我们插入主数据文件中的所有数据,直到并包括第三次数据加载。我们指定使用RECOVERY完成此还原操作。

清单8:恢复部分完整的数据库备份

运行此脚本的输出如图3所示。我们应该看到在第一个命令中正在处理所有文件,而在第二个命令中仅修改了读写和事务日志文件。

图3:部分数据库备份还原输出

一切看起来都很好,并且完全符合预期,但是让我们再次戴上“ Paranoid DBA”帽子,并检查恢复的数据库是否包含正确的数据。

清单9:检出我们新恢复的数据

希望我们将在ArchiveData表中看到三行数据,在读写表MainData中看到六行数据,如图4所示。

1472-image001.png

图4:在新还原的数据库上的数据检查结果

恢复差异部分备份

这次的还原操作非常相似,只是我们需要处理所有三个备份文件,以使数据库在最终数据加载后恢复到其状态。您可能想知道为什么在这种情况下有必要处理完整的部分备份,而不是仅执行完整的备份,然后再执行差异部分备份。实际上,完整数据库备份不能作为差异部分备份的基础;只有完整的部分备份可以作为差异部分备份的基础,就像只有完整的数据库备份可以作为差异数据库备份的基础一样。每个差异部分备份都保留自基础部分备份以来的所有更改,因此,如果我们有一系列差异部分备份,则只需还原该系列中的最新备份。

清单10显示了脚本;我们将还原完整数据库和完整部分备份,使数据库处于还原状态,然后应用差异部分备份并恢复数据库。

清单10:恢复部分差异备份文件

再次检查脚本的输出,以确保一切看起来都应该正确,然后重新运行清单9,以验证MainData表中现在是否还有三行,总共有9行,但仍然只有三行在ArchiveData表中。

特例部分备份还原

在这里,我们将快速浏览一种特殊的还原操作,我们可以将其称为“部分在线零碎还原”,它将通过仅还原数据库中的只读文件组来使数据库联机(需要企业版)。 ,如清单11所示。如果完整文件备份包含主文件组以及数据库系统信息,则可以使用完整部分备份和完整文件备份来完成这种类型的还原。如果我们需要恢复读写文件组中存在的特定表,或者想要在不还原整个数据库的情况下查看备份的内容,这将非常有用。

清单11:执行部分在线还原

现在,我们应该有一个可以联机使用并且可以使用的数据库,但是该数据库只能访问读写文件组,我们可以通过一些简单的查询来进行验证,如清单12所示。

清单12:从我们部分还原的数据库中选择数据

该脚本尝试查询两个表,并且输出如图5所示。

1472-image002.png

图5:无法从存档表中提取信息

我们可以看到我们确实从MainData表中提取了6行,但是当我们尝试从ArchiveData表中提取数据时,我们收到了一个错误,因为该文件组不属于我们在还原操作中使用的文件的一部分。我们可以看到该表存在,甚至可以看到它的结构(如果倾斜的话),因为所有这些信息都存储在系统数据中,该数据已通过主文件组进行了恢复。

SQL备份部分备份和还原

在本节中,我们将不重新开始整个示例,而是研究SQL Backup中等效的完全部分备份和差异部分备份命令,如清单13所示。

清单13:用于完整部分和差异部分备份的SQL Backup脚本

清单14显示了部分备份的等效还原命令。同样,它们与我们之前在其他还原脚本中看到的非常相似。我们将还原最后一次完整的数据库备份,使数据库可以处理更多文件。这将还原所有只读数据,并使数据库保持还原状态,以准备应用部分备份数据。然后,我们应用完整的部分和差异部分备份,并恢复数据库。

清单14:用于完整和差异部分还原的SQL Backup脚本

部分备份和还原的可能问题

使用部分备份还原数据库时,最大的问题是只读数据的存储和管理。导入数据后,立即在完整的数据库备份中捕获此数据,然后不再进行备份。因此,它的存在很容易从DBA的头脑中溜走。但是,仅仅因为数据库的这一部分备份的频率降低了,并不意味着它的重要性就降低了。它仍然是恢复策略不可或缺的一部分,因此请仔细管理备份策略中的每个文件,并确保完整的数据库备份不会在归档丛林中丢失。

在备份策略包括后续部分备份的数据库上执行完整数据库备份之一时,最好对该完整数据库备份执行校验和。这可能并且很可能会减慢备份速度,但是如果您受到打击,可以放心,此完整备份是有效的,因为它很少被捕获。当然,使用新创建的完整备份文件执行测试还原会更好!

如果确实发现完整的数据库备份未正确存储或文件已因某种原因损坏,该怎么办?好吧,不是很多。希望针对这种情况,您有多个副本存储在不同的位置。在处理不定期备份的数据时,将副本保存在长期存储中以及将其保留在健壮的磁盘上是其他好主意。在管理备份文件时要勤奋。请记住,您的数据就是您的工作!

SLA中的部分备份和还原

像文件备份和还原一样,部分备份和还原很可能只占整体可恢复性策略的一小部分。在某些情况下,部分备份是一种非常有用且省时的工具,但是在大多数情况下,它们不太可能成为“转到”备份类型,这主要是因为大多数数据库根本不包含很大一部分只读数据。

但是,如果涉及部分备份的策略似乎很适合数据库,那么在该数据库的SLA中,您需要考虑以下问题:

  • 刷新完整数据库备份的频率
  • 完全部分备份和差异部分备份的频率
  • 仍然需要事务日志备份吗?

如前所述,在设计部分备份时要考虑SIMPLE恢复模型数据库。当以这种方式应用时,这意味着我们只能还原到上次执行的备份,很可能是完全部分备份或差异部分备份,因此,例如在中午失败。您必须权衡数据库还原需求,以决定这种类型的备份是否适合您。像其他所有类型的备份一样,权衡利弊,以查看哪种类型或类型的组合最适合您的数据库。

仅仅因为这种备份主要是针对SIMPLE恢复模式数据库设计的,并不意味着我们只能在这种情况下使用它。对于FULL恢复模型数据库,其数据丢失可接受范围的窗口要小得多(例如一个小时),但确实包含很大一部分的只读数据,因此这种备份类型仍然可以发挥我们的优势。但是,除了部分完全差异和部分差异之外,我们还需要进行事务日志备份。在紧急情况下,这将为备份和还原过程增加更多的复杂性,但将启用时间点还原。

强迫失败的乐趣

我不喜欢以失败告终,这有时是DBA的大部分时间。及时处理故障,了解故障原因,并采取措施以确保故障不再发生。考虑到这一点,让我们来看一个注定要失败的部分备份方案。看一下清单10.15中的脚本,最后一次,在运行它之前尝试找出问题所在。

清单15:使用部分数据库备份还原强制执行还原错误

你发现错误了吗?图6显示了产生的SQL Server错误消息。

1472-image003.png

图6:强制失败查询结果

执行脚本时遇到的第一个错误是错误“ File DatabaseForPartialBackups处于不正确的状态,无法对其应用差异备份。”这告诉我们,数据库不准备使用差异部分备份文件来处理我们的第二个还原命令。

原因是我们忘记了处理部分完整的备份文件。由于部分完整文件(而不是完整数据库文件)是部分差异的基础,因此如果没有它,我们将无法处理部分差异。这就是为什么我们的数据库未处于正确状态以处理该差异备份文件的原因。

摘要

现在,您应该熟悉如何执行部分完全和部分差异备份,并可以轻松还原这种类型的备份文件。

备份数据库和执行还原应该是所有DBA定期执行的工作。该技能对DBA至关重要,我们应该继续努力,直到主题成为第二自然,这样,当灾难袭击数据库时,无论采用何种形式,经过仔细记录和测试的还原策略都将使您获得成功。数据库恢复在线状态,数据丢失水平可以接受,并且停机时间最少。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638