有关将快照用作数据保护策略的一个常见问题是、"实际"数据和快照数据位于同一个驱动器上。丢失这些驱动器将导致主数据和备份均丢失。

这是一个合理的问题。本地快照用于满足日常备份和恢复需求、在这方面、快照是备份。在NetApp环境中、几乎99%的恢复方案都依靠快照来满足最苛刻的恢复时间要求。

但是、本地快照绝不是唯一的备份策略、这就是NetApp提供SnapMirror和SnapVault复制等技术来快速高效地将快照复制到一组独立驱动器的原因。在采用快照和快照复制功能且架构合理的解决方案中、磁带的使用量可以降至最低、甚至可以每季度归档一次、也可以完全避免。

使用ONTAP Snapshot副本保护数据有多种选择、快照是复制、灾难恢复和克隆等许多其他ONTAP功能的基础。本文档不会介绍有关Snapshot技术的完整问题描述、但以下各节将提供一般概述。

创建数据集快照的主要方法有两种：

崩溃状态一致的数据集备份是指在一个时间点捕获整个数据集结构。如果数据集存储在单个卷中、则此过程非常简单；可以随时创建Snapshot。如果数据集跨越多个卷、则必须创建一致性组(CG)快照。创建CG快照的选项有多种、包括NetApp SnapCenter软件、本机ONTAP一致性组功能以及用户维护的脚本。

当备份点恢复足以满足要求时、主要使用崩溃状态一致的备份。当需要更精细的恢复时、通常需要应用程序一致的备份。

"应用程序一致"中的"一致"一词通常用词不当。例如、将Oracle数据库置于备份模式称为应用程序一致的备份、但数据不会以任何方式保持一致或处于静态。数据在整个备份过程中持续更改。相比之下、大多数MySQL和Microsoft SQL Server备份确实会在执行备份之前将数据置于静噪状态。VMware可能会使某些文件保持一致、也可能不会使其保持一致。

术语"一致性组"是指存储阵列能够将多个存储资源作为一个映像进行管理。例如、一个数据库可能包含10个LUN。阵列必须能够以一致的方式备份、还原和复制这10个LUN。如果LUN的映像在备份时不一致、则无法还原。复制这10个LUN要求所有副本之间完全同步。

ONTAP 始终能够捕获一致的本地和复制的数据映像。虽然 ONTAP AFF/FAS 系统上的各种卷通常不被正式描述为一致性组，但这就是它们的本质。该卷的快照是一致性组映像，该快照的恢复是一致性组恢复，SnapMirror 和 SnapVault 都提供一致性组复制。

AFF 系统还包括更广泛类型的一致性组。多个卷可以定义为 ONTAP 中的 CG。然后可以在 CG 级别配置快照、克隆和复制。这简化了数据保护策略，因为它允许在数据集上设置策略，而不仅仅是单个卷或 LUN。ASA 系统中也存在 CG。可以将多个 LUN 或命名空间绑定在一起作为 CG，然后可以使用快照、复制、还原或克隆来保护该 CG。

一致性组（CG）快照是基本 ONTAP Snapshot 技术的扩展。标准快照操作会为单个 AFF/FAS 卷或 ASA LUN/命名空间中的所有数据创建一致的映像，但有时需要跨多个存储资源甚至跨多个存储系统创建一组一致的快照。这样就会生成一组快照，这些快照的使用方式与仅一个卷的快照的使用方式相同。它们可以用于本地数据恢复，出于灾难恢复目的进行复制，或作为一个一致的单元进行克隆。

CG 快照的扩展性非常好。已知 CG 快照的最大使用案例是用于跨越 12 个控制器、大约 1PB 大小的数据库环境。在此系统上创建的 CG 快照已用于备份、恢复和克隆。

大多数情况下，当数据集跨越多个 AFF 卷或 ASA LUN/命名空间且必须保留写入顺序时，可以简单地定义 ONTAP 一致性组，并且可以本地管理该组卷、LUN 或命名空间以创建快照。如果使用管理软件，则应检测对 CG 快照的需求并调用所需的 API。

在这种情况下，无需了解 CG snapshot 的技术细节。但是，在某些情况下，复杂的数据保护要求需要详细控制数据保护和复制过程。自动化工作流或使用自定义脚本调用 CG snapshot API 是一些选项。要了解最佳选项和 CG snapshot 的作用，需要对该技术进行更详细的解释。

创建一组一致性组快照分为两步：

串行建立写隔离。这意味着当隔离流程跨多个存储目标设置时，写入 I/O 会冻结在序列中的第一个对象上，因为它会继续冻结在列表中稍后出现的目标上。这最初似乎会违反保留写入顺序的要求，但它仅应用于主机上异步发出的 I/O 且不依赖于任何其他写入。

例如、数据库可能会对大量异步数据文件更新进行问题描述、并允许操作系统重新排列I/O、然后根据自己的计划程序配置完成这些更新。无法保证此类I/O的顺序、因为应用程序和操作系统已释放保留写入顺序的要求。

作为反例，大多数数据库日志记录活动都是同步的。在 I/O 被确认之前，数据库不会继续进行日志写入，并且必须保留这些写入顺序。如果日志 I/O 到达隔离的 LUN，则不会进行确认，应用程序会阻止进一步写入。同样，文件系统元数据 I/O 通常是同步的。例如，不得丢失文件删除操作。如果具有 xfs 文件系统的操作系统删除了文件，并且更新 xfs 文件系统元数据以删除对该文件的引用的 I/O 落在隔离的 LUN 上，则文件系统活动将暂停。这保证了 CG 操作期间文件系统的完整性。

在目标上设置写入隔离后，它们就可以用于创建快照了。无需精确地同时创建快照，因为从依赖写入的角度来看，目标的状态是冻结的。为了防止创建 CG 快照的应用程序出现缺陷，初始写入隔离包括一个可配置的超时时间，在此时间内，ONTAP 会自动释放隔离并在定义的秒数后恢复写入处理。如果所有快照都是在超时期限结束之前创建的，则生成的一组快照将是有效的一致性组。

基于快照的备份有两种主要方法：

崩溃状态一致的数据库备份是指在单个时间点捕获整个数据库结构，包括数据文件、重做日志和控制文件。如果数据库存储在单个卷、LUN 或命名空间中，则过程很简单；可以随时创建快照。如果数据库跨越 AFF 卷或 ASA LUN/命名空间，则必须创建一致性组 (CG) 快照。有几个选项可用于创建 CG 快照，包括 NetApp SnapCenter software、本机 ONTAP 一致性组功能和用户维护的脚本。

在备份点恢复即可满足要求的情况下，主要使用崩溃一致的快照备份。在某些情况下可以应用存档日志，但当需要更精细的时间点恢复时，最好使用在线备份。

基于快照的联机备份的基本操作步骤如下所示：

此操作步骤将生成一组快照、其中包含处于备份模式的数据文件以及处于备份模式时生成的关键归档日志。这是恢复数据库的两项要求。为方便起见、还应保护控制文件等文件、但唯一的绝对要求是保护数据文件和归档日志。

虽然不同的客户可能有非常不同的策略、但几乎所有这些策略最终都基于下面所述的相同原则。

在设计 Oracle 数据库的存储布局时，第一个决定是是否使用基于卷的 NetApp SnapRestore (VBSR) 技术，这是用于还原 AFF 卷和 ASA LUN/命名空间的底层技术。

VBSR 允许数据几乎立即还原到更早的时间点。由于还原时会影响所有数据，VBSR 可能不适合所有用例。例如，如果包括数据文件、重做日志和归档日志在内的整个数据库都存储在单个 AFF 卷上，并且此卷通过 VBSR 还原，则数据会丢失，因为更新的归档日志和重做数据会被丢弃。这也适用于 ASA 数据。如果整个数据库都存储在单个 ASA 一致性组中，并且该 CG 还原到较早的状态，则会丢失一些较晚的归档日志和重做数据。

还原不需要 VBSR。许多数据库可以通过使用基于文件的单文件 SnapRestore (SFSR) 或简单地将文件从快照克隆回活动文件系统来恢复。

如果数据库非常大或必须尽快恢复，最好使用 VBSR，且使用 VBSR 需要隔离数据文件。在 NFS 环境中，给定数据库的数据文件必须存储在未受任何其他类型文件影响的专用卷中。在 SAN 环境中，数据文件必须存储在专用 LUN 或命名空间中。如果使用卷管理器（包括 Oracle Automatic Storage Management [ASM]），磁盘组也必须专用于数据文件。

以这种方式隔离数据文件可以将其还原到早期状态，而不会损坏其他文件系统。

对于 AFF SAN 环境中包含 Oracle 数据的每个卷， percent-snapshot-space 应设置为零，因为在 LUN 环境中为 Snapshot 预留空间是没有用的。如果分数预留设置为 100，则包含 LUN 的卷的 Snapshot 需要卷中足够的可用空间（不包括 Snapshot 预留）来吸收所有数据的 100% 周转。如果分数预留设置为较低的值，则需要相应较小的可用空间量，但它始终排除 Snapshot 预留。这意味着 LUN 环境中的 Snapshot 预留空间被浪费。

在NFS环境中、有两种选择：

使用第一个选项时、 percent-snapshot-space 设置为非零值、通常约为20%。然后、此空间将对用户隐藏。但是、此值不会对利用率造成限制。如果预留百分比为20%的数据库的周转率为30%、则快照空间可能会超出预留百分比的界限并占用未预留空间。

将预留设置为20%这样的值的主要优势是、验证某些空间始终可用于快照。例如、预留为20%的1 TB卷仅允许数据库管理员(Database Administrator、DBA)存储800 GB数据。此配置可确保至少为快照占用200 GB的空间。

时间 percent-snapshot-space 设置为零时、卷中的所有空间均可供最终用户使用、从而提高可见性。数据库管理员必须了解、如果发现1 TB卷利用快照、则这1 TB空间将在活动数据和Snapshot周转率之间共享。

最终用户之间没有明确的首选方案一和备选方案二。

Oracle文档ID 604683.1介绍了第三方快照支持的要求以及可用于备份和还原操作的多个选项。

第三方供应商必须保证公司的快照符合以下要求：

ONTAP和NetApp Oracle管理产品符合这些要求。