SnapRestore
建议更改
PDF
通过 NetApp SnapRestore 技术从快照中快速还原 ONTAP 数据，可以即时还原 AFF 卷或 ASA LUN 的状态。
当关键数据集不可用时、关键业务运营将中断。磁带可能会中断、甚至从基于磁盘的备份中恢复的速度也可能很慢、无法通过网络传输。SnapRestore通过近乎即时地还原数据集来避免这些问题。即使是PB级数据库、也只需几分钟的时间即可完全还原。
虽然基本技术在 AFF 和 ASA 平台上是相同的，但它们的使用略有不同。
AFF 概述
AFF 系统上有两种形式的 SnapRestore - 基于文件和基于卷：
-
无论是 2TB LUN 还是 4KB 文件，各个 AFF 文件、LUN 和命名空间以及各个 ASA LUN 和命名空间都可以在几秒钟内恢复。
-
无论是 10GB 还是 100TB 的数据，AFF 卷的完整内容都可以在数秒内还原。
SnapRestore 之所以能够如此快速高效地工作，是因为快照的性质，它本质上是特定时间点上卷、LUN 或命名空间内容的并行只读视图。活动块是可以更改的真实块，而快照是创建快照时组成文件和 LUN 的块状态的只读视图。
ONTAP 仅允许对快照数据进行只读访问，但可以使用 SnapRestore 重新激活数据。快照将作为数据的读写视图重新启用，从而将数据返回到先前的状态。SnapRestore 可以在卷、文件、LUN 或命名空间级别操作。该技术本质上是相同的，但行为略有不同。
AFF 卷 SnapRestore
基于卷的 SnapRestore 将整个卷的内容返回到早期状态。此操作不需要数据移动，这意味着还原过程基本上是即时的，尽管 API 或 CLI 操作可能需要几秒钟才能处理。还原 1GB 数据并不比还原 1PB 数据更复杂或耗时。此功能是许多企业客户迁移到 ONTAP 存储系统的主要原因。即使是最大的数据集，它也能提供以秒为单位的 RTO。
基于卷的SnapRestore的一个缺点是、卷内的更改会随着时间的推移而累积。因此、每个快照和活动文件数据都取决于到那时为止所做的更改。将卷还原到早期状态意味着、系统将会先对数据进行所有后续更改、然后再进行相应的更改。但是、不太明显的是、这包括随后创建的快照。这并不总是可取的。
例如、数据保留SLA可能指定30天的夜间备份。如果将数据集还原到五天前使用卷SnapRestore创建的快照、则会丢弃前五天创建的所有快照、从而违反SLA。
有许多选项可用于解决此限制：
-
可以从先前的快照复制数据、而不是对整个卷执行SnapRestore。此方法最适合较小的数据集。
-
快照可以克隆、而不是还原。此方法的限制是、源快照是克隆的依赖项。因此、除非同时删除克隆或将其拆分成独立的卷、否则无法将其删除。
-
使用基于文件的SnapRestore。
AFF 文件 SnapRestore
基于文件的 SnapRestore 是一种更精细的基于快照的还原过程，用于 AFF 卷。而不是还原整个卷的状态，还原单个文件、LUN 或命名空间的状态。无需删除任何快照，此操作也不会对先前的快照创建任何依赖关系。文件或 LUN 将立即在活动卷中可用。
在文件或 LUN 的 SnapRestore 恢复期间无需进行数据移动。但是，需要进行一些内部元数据更新，以反映还原数据中的底层块现在同时位于快照和活动卷中这一事实。不会对性能产生任何影响，但此流程会阻止创建快照，直到流程完毕为止。根据恢复的文件总大小，处理速率约为 5GBps（18TB/小时）。
ASA LUN/命名空间恢复
在 ASA 上恢复数据类似于 AFF SnapRestore。只需将数据还原到早期状态。此过程几乎是即时的，不需要数据移动。它还具有相同的限制，包括恢复快照导致删除随后删除的快照的要求。如果这有问题，有两种选择。首先，可以从较早的快照克隆 LUN/命名空间，同时保持源卷不变。这是一个即时且节省空间的过程。它本质上对快照中的块创建只读指针的读写副本。第二个选项是通过 REST API，它可以使用 AFF 系统中使用的相同的单文件 SnapRestore 逻辑。结果是使用快照中的数据即时恢复 LUN/命名空间，并保留所有快照。