NetApp Disaster Recovery 是一种基于云的灾难恢复服务，可通过 NetApp Console 访问，可自动执行 VMware 和 Kubernetes 环境的灾难恢复工作流程。它将运行 ONTAP 存储的本地 VMware 工作负载或运行 Trident 管理的 ONTAP 存储的 Kubernetes 工作负载复制到另一个站点作为灾难恢复目标。该服务使用 ONTAP SnapMirror 技术，结合原生 VMware 编排或 Trident Protect 编排，在保留 ONTAP 存储效率（例如压缩和重复数据删除）的同时保护工作负载。

灾难恢复不需要任何单独的启用。它会自动显示在 NetApp Console 左侧导航栏的*保护* > *灾难恢复*下。要访问 NetApp Console，请在浏览器中输入： "https://console.netapp.com/"。

要进行完整、持续的访问，需要 Disaster Recovery 许可证。在购买许可证或订阅之前，您可以通过 30 天的免费试用来试用该服务。有关详细信息，请参阅 "设置 Disaster Recovery 许可"。

灾难恢复支持以下保护目标:

对于 VMware 工作负载，Disaster Recovery 支持以下数据存储类型：

对于 Kubernetes 工作负载，NetApp Disaster Recovery 保护通过 NetApp Trident 在 ONTAP 存储上配置的持久卷。

灾难恢复提供以下许可选项：

当至少有一个虚拟机或 Kubernetes 资源具有复制计划时，灾难恢复费用基于源站点上数据存储的已用容量。

对于 BYOL，如果数据超出允许的容量，则在您获得额外的容量许可证或在 NetApp Console 中升级许可证之前，服务中的操作将受到限制。

免费试用结束后，您仍然可以查看和删除工作负载和复制计划等资源，并运行在试用期间创建的所有计划操作。要继续使用具有完整功能的服务，您需要从云提供商处获取 PAYGO 订阅，或从 NetApp 购买 BYOL 许可证。

您可以随时购买许可证或订阅，在 30 天试用期结束之前，我们不会向您收取费用。

灾难恢复支持以下拓扑：

有关完整列表，请参见 "灾难恢复先决条件"。

控制台代理是一种软件组件，使 NetApp Console 能够与您的 ONTAP 存储和 VMware vCenter 集群进行通信。这是灾难恢复正常运行所必需的。代理驻留在您的专用网络（本地数据中心或云 VPC）中，并与您的 ONTAP 存储实例和 vCenter 集群进行通信。

对于本地到本地灾难恢复，请在灾难恢复站点中安装本地控制台代理。对于本地到 AWS，请在 AWS VPC 中安装 AWS 控制台代理。源和目标 vCenter 集群都应使用相同的控制台代理。灾难恢复仅适用于标准模式代理部署。

每个 Kubernetes 集群都必须安装 NetApp Trident、配置 ONTAP 后端和存储类，并安装卷快照 CRD 和控制器。应用程序必须使用通过 Trident 存储类配置的永久卷。当您将 Kubernetes 集群添加为站点时，Disaster Recovery 将指导您在该集群上安装和注册 Trident Protect。有关分步命令和验证检查，请参阅 "Kubernetes 集群的灾难恢复要求"。

站点是一个逻辑容器，通常与物理数据中心或云位置相关联，托管一个或多个 vCenter 集群或 Kubernetes 集群。在创建复制计划之前，需要添加源（生产）站点和目标（灾难恢复）站点。

资源组是一个逻辑容器，允许您将多个虚拟机、数据存储区或 Kubernetes 命名空间和资源作为一个单元进行管理，从而可以使用通用快照对其进行保护。一个虚拟机一次只能属于一个资源组。您可以为要保护的每个应用程序或工作负载创建一个资源组，虚拟机根据您在组中配置的引导顺序启动。

复制计划是关于备份发生频率和如何处理故障转移事件的一组规则。它选择源站点和目标站点，分配资源组，定义恢复映射，并配置开机行为。计划通过数据复制的频率定义恢复点目标 (RPO)。

恢复点目标 (RPO) 是在发生灾难时可接受的最大数据丢失量；它由复制计划的复制频率或时间表定义。恢复时间目标 (RTO) 是从灾难中恢复可接受的最长时间；它取决于故障切换到灾难恢复站点并重新启动所有虚拟机或应用程序所需的时间。

有关步骤，请参见 "在 Disaster Recovery 中添加站点"。

默认情况下，Discovery 每 24 小时运行一次；您可以自定义计划以适应您的环境。最小间隔为 30 分钟，最大间隔为 24 小时。NetApp 建议先执行一些手动发现以获取最新信息，然后将计划设置为自动运行。新添加或删除的资源将在下一次计划或手动发现时被识别。

不可以。在同一数据存储区上托管受保护和未受保护的虚拟机可能会导致问题。也就是说，如果数据存储进行了故障转移，则故障转移后，其上的任何未受保护的虚拟机都不再存在于源处，并且 Disaster Recovery 将不会在故障转移站点启动它们。

在部署 Disaster Recovery 之前，应组织资源，以便受保护和未受保护的工作负载使用单独的数据存储子集，并确保单个数据存储不受多个复制计划的保护。

如果您计划使用平台托管（ONTAP 托管）备份，请使用 MirrorAll 策略。MirrorVault 和 Asynchronous 是可接受的替代方案，但必须确保在故障转移或故障回复期间选择的快照在源卷和目标卷上都存在，否则操作将失败并出现"未找到通用快照"错误。MirrorLatest 不建议使用，因为它仅为故障转移留下一个通用快照。对于 NetApp Disaster Recovery 管理的 SnapMirror 关系，请勿在服务之外为其计划更新，因为 NetApp Disaster Recovery 负责管理复制计时。

是。如果受保护数据存储的源卷和目标卷之间已存在 SnapMirror 关系，灾难恢复将对所有复制操作使用该关系，而不是创建新关系。

是的。您可以使用为迁移配置的复制计划，将 VMware 应用程序从源站点迁移到另一个站点。启动迁移后，服务会每 30 分钟验证一次迁移是否按计划进行；您可以在“作业监控”中监控进度。目前不支持对基于 Kubernetes 的工作负载进行迁移。请参见 "将应用程序迁移至其他站点"。

可以。在测试故障转移期间，Disaster Recovery 将从选定快照的新 FlexClone 卷创建临时虚拟机，并将临时 FlexClone 支持的数据存储映射到 ESXi 主机。这不会消耗额外的物理容量，不会修改原始源卷，也不会中断 SnapMirror 关系或生产工作负载，这些工作负载将继续正常复制。测试完成后，使用 清理故障转移测试 操作清理测试环境。请参阅 "将应用程序故障转移到远程站点"。

可以。默认情况下，所有虚拟机并行启动，但可以为每个虚拟机分配一个顺序编号（例如 1、2、3）来控制启动顺序，也可以将相同的编号分配给多个虚拟机以同时启动。您还可以为每个虚拟机设置启动延迟（0–10 分钟）以错开启动时间，这有助于确保高优先级虚拟机在低优先级虚拟机启动之前已处于运行状态。

故障回切在灾难解决后将操作返回到原始源站点。从已故障切换到目标的关系开始，NetApp Disaster Recovery 将任何更改重新同步回原始源 VM 或 Kubernetes 集群，然后再反转复制方向。流程：

请参阅 "将应用程序回切至原始源"。

使用 Disaster Recovery Dashboard 查看站点和计划是否正常、断开连接或降级；查看最近的警告和失败的作业；识别受保护和未受保护的工作负载；并一目了然地查看容量。请参阅 "查看灾难恢复计划运行状况"。

使用 Job monitoring 来查看作业时间戳、状态和发起者（或"系统"，如果 Disaster Recovery 启动了它）。您可以从"操作"菜单中取消"正在进行"或"已排队"的作业，这在作业停滞或需要优先执行其他操作时非常有用。请参阅 "监视灾难恢复作业"。

您可以生成适用于 VMware、Kubernetes 或所有工作负载的报告，包括复制计划详细信息、合规性状态和作业摘要。报告可以下载为 PDF、HTML 或 JSON 文件。它们涵盖一到七天的时间段。有关详细信息，请参见 "在 Disaster Recovery 中创建报告"。

AppVault 是 Trident Protect 保存 Kubernetes 保护数据的云存储目标。您在配置 Kubernetes 复制计划时创建 AppVault。