通过

在发生灾难性数据丢失后进行恢复

  • 项目

Azure Stack Hub 在数据中心运行 Azure 服务，并且可以在如同安装在单个机架中的四个节点那样小的环境中运行。 同时，Azure 也可以在 40 多个地区中的多个数据中心内运行，并且每个地区中可以有多个区域。 用户资源可以跨多个服务器、机架、数据中心和地区。 目前，在使用 Azure Stack Hub 时只能选择将整个云部署到单个机架上。 此限制会使你的云面临数据中心发生灾难性事件或由于主要产品 bug 而发生故障的风险。 当灾难发生时，Azure Stack Hub 实例会进入脱机状态。 可能无法恢复所有数据。

根据数据丢失的根本原因，可能需要修复单个基础结构服务或还原整个 Azure Stack Hub 实例。 你甚至可能需要还原到同一位置或其他位置中的其他硬件。

此方案解决了在出现故障时恢复整个安装以及重新部署私有云的问题。

方案 数据丢失 注意事项
在由于灾难或产品 bug 而发生灾难性数据丢失后进行恢复。 所有基础结构及用户和应用数据。 可以还原到其他 OEM。
可以还原到不同代系的硬件。
可以还原到不同计数的缩放单元节点。
用户应用和数据与基础结构数据分开进行保护。

工作流

保护 Azure Stack Hub 的历程从分别备份基础结构和应用/租户数据开始。 本文档介绍了如何保护基础结构。

Azure Stack Hub data recovery workflow - Deployment

在所有数据均丢失的最差情况中，恢复 Azure Stack Hub 是还原与 Azure Stack Hub 的该部署相关的基础结构数据和所有用户数据的过程。

Azure Stack Hub data recovery workflow - Redeployment

还原

如果发生灾难性数据丢失，但硬件仍然可以使用，则需重新部署 Azure Stack Hub。 在重新部署期间，可以指定存储位置和访问备份所需的凭据。 在此模式下，不需要指定需要还原的服务。 基础结构备份控制器将控制层状态插入为部署工作流的一部分。

如果发生导致硬件不可用的灾难，则只能在新硬件上重新部署。 因为要订购更换硬件并等待硬件到达数据中心，所以重新部署可能会花费数周时间。 可以在任何时间还原控制层数据。 但是，如果重新部署的实例的版本比上次备份中使用的版本高一个版本，则不支持还原。

部署模式 起点 终点
全新安装 基线版本 OEM 部署 Azure Stack Hub，并将其更新到最新的受支持版本。
恢复模式 基线版本 OEM 在恢复模式下部署 Azure Stack Hub 并根据可用的最新备份来处理版本匹配要求。 OEM 通过更新到最新的受支持版本来完成部署。

备份中的数据

Azure Stack Hub 支持称为云恢复模式的部署类型。 只有当灾难或产品 Bug 导致解决方案不可恢复后，你选择恢复 Azure Stack Hub 时才使用此模式。 此部署模式不会恢复解决方案中存储的任何用户数据。 此部署模式的作用域仅限于还原以下数据：

  • 部署输入
  • 内部标识服务数据
  • 联合标识配置（ADFS 部署）。
  • 内部证书颁发机构使用的根证书。
  • Azure 资源管理器配置用户数据，如订阅、计划、套餐、资源组、标记、存储配额、网络配额和计算资源。
  • Key Vault 机密和保管库。
  • RBAC 策略分配和角色分配。

在部署期间不会恢复任何用户基础结构即服务 (IaaS) 或平台即服务 (PaaS) 资源。 这些丢失包括 IaaS VM、存储帐户、blob、表、网络配置等。 云恢复的目的是为了确保操作员和用户在部署完成后可以重新登录回门户。 重新登录回来的用户不会看到其任何资源。 用户将还原其订阅以及由管理员定义的原始计划、套餐和策略。重新登录回系统的用户在灾难发生前原始解决方案施加的相同约束下操作。 在云恢复完成后，操作员可以手动还原增值 RP 和第三方 RP 以及关联的数据。

验证备份

可以使用 ASDK 来测试备份，以确认数据有效且可用。 有关详细信息，请参阅使用 ASDK 验证 Azure Stack 备份。

后续步骤

了解使用基础结构备份服务的最佳做法。