未经同意，请勿转载！

本文以Azure Stack Hub 云恢复（Cloud Recovery）为主线 ——从"什么样的灾难需要云恢复"出发，厘清"灾难性数据丢失 vs 硬件不可恢复"两种场景的差异，再到多阶段恢复流程（Phase 0~Phase 4）、部署模式选择（全新安装 vs 恢复模式）、ASDK 测试方法，完整呈现 Azure Stack Hub 在"灾难性数据丢失"场景下的恢复路径。

系列预告：

• 上篇：基础架构备份（Infrastructure Backup）—— 备份什么、怎么配、注意事项
• 本篇：云恢复（Cloud Recovery）—— 灾难后的多阶段恢复
• 第三篇：用户虚拟机保护（IaaS VM Backup / Replication）—— 租户侧 VM 备份与复制方案

版本基础：本文基于azs-1808 至当前主流 azs 版本（覆盖 1808 / 1901 / 2002 / 2005 / 2102 / 2206 / 2301 / 2405 / 2503 等）的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异，当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档为准。

修订说明：

本篇为Azure Stack Hub 备份与灾难恢复系列的第二篇，基于材料《Azure Stack Hub 备份与灾难恢复》整理，按照文档编写准则做工程化改写。

目录

1. 什么是云恢复：定位与适用场景
2. 两种灾难场景：数据丢失 vs 硬件不可恢复
3. 多阶段恢复流程：Phase 0 ~ Phase 4 全景
4. 阶段主导方与依赖关系
5. 部署模式：全新安装 vs 恢复模式
6. 版本匹配：恢复模式下的版本处理逻辑
7. 使用 ASDK 测试基础设施还原
8. 恢复过程中的责任划分
9. 恢复路径决策树
10. 本篇小结

1. 什么是云恢复：定位与适用场景

云恢复（Cloud Recovery）是 Azure Stack Hub 在灾难性数据丢失场景下，由 OEM 主导、用户配合的多阶段恢复流程。

1.1 云恢复的目标

L1 微软硬要求

云恢复的核心目标是：在灾难性数据丢失后恢复 Azure Stack Hub 基础设施和用户配置。这一目标包含两个层面：

1.2 云恢复 vs 普通恢复

关键认知：云恢复不是"重启一下就好"的运维动作，而是"重新搭一台云"的工程动作。它涉及 OEM 工程师上门、硬件验证、软件重新部署、备份还原、租户数据重建等多个环节，通常耗时数天到数周。

1.3 为什么不能"自己恢复"

Azure Stack Hub 是 OEM 集成系统，恢复动作不是管理员能独立完成的：

• ❌管理员不能自行重新部署 Azure Stack Hub—— 部署权限仅 OEM 持有
• ❌管理员不能在 HLH 上自行启动恢复流程—— 恢复模式部署是 OEM 工程师的责任
• ❌管理员不能自行解决硬件不可用—— 必须通过 OEM Support 流程

L1 微软硬要求：OEM 是 Azure Stack Hub 部署服务的唯一授权实体——这一边界决定了云恢复必须由 OEM 主导。

2. 两种灾难场景：数据丢失 vs 硬件不可恢复

云恢复讨论的"灾难"有两种本质不同的场景——它们的恢复路径完全不同。

2.1 场景对比

2.2 场景识别的关键问题

L3 最佳实践

当 Azure Stack Hub 出现故障时，管理员应在升级到 OEM Support 前先回答以下问题：

1. 硬件是否完全可用？

   • 所有 Scale Unit 节点可启动？
   • ToR / BMC 交换机可访问？
   • HLH 可访问？
   • 存储池状态正常？

2. 平台状态是否可恢复？

   • 管理门户是否可登录？
   • 基础设施备份是否可触发？
   • 租户 VM 是否还能访问（即使降级）？

3. 故障的根因是什么？

   • 已知原因（如计划内维护失败）？
   • 未知原因（需要 OEM 工程师现场诊断）？

关键判定：如果硬件可用但平台状态不可恢复，走"数据丢失"云恢复路径；如果硬件不可恢复，则必须先解决硬件问题（订购新设备），再走"重新部署 + 备份还原"路径。

2.3 恢复时间期望

关键含义：云恢复的主体（Phase 0 + Phase 1）由 OEM 主导，耗时通常在数周级别。PaaS / IaaS / 用户数据恢复由用户主导，耗时取决于数据量、备份介质、还原策略。

3. 多阶段恢复流程：Phase 0 ~ Phase 4 全景

Azure Stack Hub 云恢复是一个多阶段、互依赖的过程。每个阶段都有自己的前置条件和主导方，不能跳过，也不能并行。

3.1 五阶段时间线

┌──────┐ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌────────────┐ │Phase │ │ Phase │ │ Phase │ │ Phase │ │ Phase │ │ 0 │ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │硬件 │ → │ 云恢复 │ → │ PaaS │ → │ IaaS VM │ → │ 用户数据 │ │就绪 │ │ │ │ 恢复 │ │ 恢复 │ │ 恢复 │ └──────┘ └──────────┘ └────────┘ └──────────┘ └────────────┘ 数天~数周 < 1 周 数天 数小时~数天 数小时~数周~数月 [主导方] [主导方] [主导方] [主导方] [主导方] Dell Dell 用户 + Dell 用户 用户

3.2 阶段详情

Phase 0：硬件就绪

Phase 1：云恢复

L1 微软硬要求：Phase 1 是 OEM 主导的"重新部署"动作——管理员不能自行启动。即使管理员手上有合法凭据和备份，重新部署动作仍由 OEM 执行。

Phase 2：PaaS 恢复

关键认知：Phase 2 由用户主导——OEM 在 Phase 1 完成了平台恢复，PaaS 服务实例需要用户按业务需求重新创建（详见第三篇关于租户备份的讨论）。

Phase 3：IaaS VM 恢复

Phase 4：用户数据恢复

3.3 阶段间依赖关系

L3 最佳实践

Phase 0 ──→ Phase 1 ──→ Phase 2 ──→ Phase 3 ──→ Phase 4 │ │ │ │ │ ↓ ↓ ↓ ↓ ↓ 硬件就绪 平台个性 PaaS 服务 IaaS VM 业务数据

强依赖关系：

• Phase 1 必须等待 Phase 0 完成
• Phase 2 必须等待 Phase 1 完成（管理平面必须可用）
• Phase 3 必须等待 Phase 2 完成（PaaS 服务可能提供 VM 依赖的能力）
• Phase 4 必须等待 Phase 3 完成（VM 必须可用才能恢复数据）

关键认知：任意阶段的失败都需要回到前序阶段重新执行——这是云恢复流程的"瀑布模型"特征。管理员应在每个阶段完成后立即验证里程碑（见 §8），避免在后续阶段才发现前序阶段的问题。

4. 阶段主导方与依赖关系

明确每个阶段的主导方是云恢复规划的关键前置——它决定了责任划分、资源投入和时间预期。

4.1 主导方矩阵

4.2 责任划分的关键判断

L1 微软硬要求

• Phase 0 + Phase 1 的 OEM 主导地位不可变—— 这是平台架构硬约束
• Phase 2 ~ Phase 4 的用户主导地位由业务架构决定—— 不同业务的恢复策略可能差异巨大
• OEM 在 Phase 2 中是"协助"角色—— OEM 工程师可以提供技术建议，但不主导业务恢复

4.3 管理员的角色定位

管理员在云恢复过程中的角色随阶段变化：

L3 最佳实践：管理员应在云恢复发生前就与 OEM 建立清晰的沟通渠道——包括紧急联系人、升级路径、SLA 期望等。云恢复发生时再建立渠道为时已晚。

5. 部署模式：全新安装 vs 恢复模式

云恢复的核心动作是"重新部署 Azure Stack Hub"。但重新部署有两种不同的模式，适用于不同场景。

5.1 部署模式对比

5.2 模式差异的本质

关键认知

• 全新安装是"无历史"的部署——不存在"之前是谁"的问题
• 恢复模式是"有历史"的部署——部署过程中会指定备份存储位置和凭据，平台从备份中还原"身份"

恢复模式部署的关键差异：

1. 指定备份存储位置—— 在重新部署期间，管理员指定访问备份所需的存储位置和凭据
2. 指定预共享密钥—— 提供解密备份数据的密钥
3. 触发基础设施数据还原—— 部署完成后自动从备份还原 AD / RBAC / Plans 等
4. 版本匹配处理—— Dell 根据"备份时的版本"和"最新受支持版本"做匹配

5.3 何时选择哪种模式

关键认知：云恢复场景下永远是"恢复模式"部署——这不是管理员能选择的选项，而是平台架构的硬约束。

5.4 部署过程中管理员的关键配合动作

6. 版本匹配：恢复模式下的版本处理逻辑

恢复模式部署中，版本匹配是一个容易被忽视的工程细节——它决定了恢复后 Scale Unit 的状态。

6.1 版本匹配的处理逻辑

L3 最佳实践

Dell 在恢复模式下部署 Azure Stack Hub 的版本处理路径：

┌────────────────────────────────┐ │ 可用的最新备份（某个 azs 版本） │ │ 例如：azs-2102 │ └────────────────────────────────┘ ↓ ┌────────────────────────────────┐ │ 备份中的版本 vs 最新受支持版本 │ │ （可能 azs-2102 < 2503） │ └────────────────────────────────┘ ↓ ┌───────────────────────────────────┐ │ Dell 根据备份版本 + 最新受支持版本 │ │ 处理版本匹配要求 │ └───────────────────────────────────┘ ↓ ┌───────────────────────────────────┐ │ 通过更新到最新的受支持版本来完成部署 │ └───────────────────────────────────┘

6.2 版本匹配的可能场景

L0 版本事实：版本匹配的具体规则由 OEM Support Matrix 决定——Dell / Lenovo / HPE 等不同 OEM 在版本处理上可能有差异。当备份版本与本文表述不一致时，以当期 OEM Support Matrix + 微软版本兼容性文档为准。

6.3 版本匹配对恢复时间的影响

L3 最佳实践

关键认知：备份频率高 + 及时更新平台 = 恢复后版本较新 = 恢复时间较短。长期不更新平台会让恢复路径变长。

7. 使用 ASDK 测试基础设施还原

ASDK（Azure Stack Development Kit）是 Azure Stack Hub 的开发工具包版本——它允许管理员在非生产环境中完整测试云恢复流程。

7.1 ASDK 测试云恢复的核心价值

L3 最佳实践

7.2 ASDK 测试云恢复的步骤

L0 版本事实：以下步骤基于 azs ASDK 文档整理，不同 azs 版本下脚本名称和参数可能略有差异。

步骤 1：准备 ASDK 主机服务器

使用当前版本的 Azure Stack Hub准备 Azure Stack Hub 开发工具包（ASDK）主机服务器。

步骤 2：复制备份到 ASDK 本地文件夹

将生产 Azure Stack Hub 的备份复制到 ASDK 上的本地文件夹。

\\production-fileserver\fileshare\AzS-Prod\ ↓ 复制 \\asdk-host\local-folder\AzS-Prod\

步骤 3：在云恢复模式下部署 ASDK

使用Install-AzSDeployment.ps1脚本（也写作Install-AzsPoc.ps1等名称，具体以当期版本为准）在云恢复模式下部署 ASDK：

# 在 ASDK 主机上以管理员身份执行（伪代码示例） cd \AzStackPoc\Tools # 云恢复模式下部署 .\Install-AzSDeployment.ps1 ` -CloudRecoveryMode ` -BackupShare "\\asdk-host\local-folder\AzS-Prod\" ` -BackupCredential (Get-Credential) ` -EncryptionKey (Get-Credential)

步骤 4：使用 Restore-AzSBackup 完成还原

成功部署云恢复后，需要使用Restore-AzSBackupcmdlet 完成还原：

# 在 ASDK 部署完成后执行 # 通过特权终结点（PEP）触发还原 $pepEndpoint = "AzS-ERCS01" $backupLocation = "\\asdk-host\local-folder\AzS-Prod\" Invoke-Command -ComputerName $pepEndpoint -ScriptBlock { Restore-AzSBackup -BackupLocation $using:backupLocation }

7.3 ASDK 测试的边界（关键认知）

L1 微软硬要求

关键认知：ASDK 是验证备份可用性的手段，不是替代生产恢复的手段。即使 ASDK 上完整跑通云恢复流程，生产 Scale Unit 的真正灾难恢复仍必须由 OEM 主导。

7.4 ASDK 测试的推荐频率

L3 最佳实践

关键认知：ASDK 测试是"备份策略的最后一道验证"——如果 ASDK 上都无法还原备份，那么生产 Scale Unit 灾难发生时也无法还原。

特别强调：ASDK与生产的Azure Stack Hub环境是有区别，只作验证使用，不能替代或等同于生产环境中的azure Stack Hub。

8. 恢复过程中的责任划分

云恢复的整个过程涉及多方协作——明确责任划分是 BCP / DR 文档的必要内容。

8.1 三方责任矩阵

8.2 管理员的关键交付物

L3 最佳实践

云恢复过程中，管理员应在每个阶段向相关方交付以下内容：

8.3 灾难沟通的关键时点

L3 最佳实践

云恢复过程中，管理员应在以下时点主动沟通：

1. Phase 0 启动时—— 通知所有相关方（管理层、业务部门、租户）
2. Phase 1 启动时—— 通知 OEM 工程师进度、提供备份信息
3. Phase 1 完成时—— 通知租户"平台已就绪"，启动 Phase 2
4. Phase 2 完成时—— 通知租户"PaaS 服务已恢复"
5. Phase 3 完成时—— 通知租户"VM 已恢复，可启动应用"
6. Phase 4 完成时—— 通知所有方"业务全面恢复"

关键认知：云恢复的耗时通常是"天"到"周"的量级——管理层和租户的预期管理至关重要。主动沟通优于被动响应——即使没有新进展，也应定期（如每 24 小时）同步状态。

9. 恢复路径决策树

当 Azure Stack Hub 出现故障时，管理员可以通过以下决策树判断恢复路径。

9.1 故障识别决策

Azure Stack Hub 故障 │ ↓ ┌────────────────────┐ │ 硬件完全可用？ │ └────────────────────┘ │ ┌─────────┴─────────┐ ↓ ↓ 是 否 │ │ ┌───────┴────────┐ ┌─────┴──────────┐ │ 平台状态可恢复？│ │ 硬件不可恢复 │ └───────┬────────┘ │ 需更换硬件 │ │ └─────┬──────────┘ ┌───────┴───────┐ │ ↓ ↓ ↓ 是 否 ↓ │ │ ↓ Scale Unit 云恢复 云恢复（先解决硬件） 自动恢复 （数据丢失） + 等待新硬件 （分钟级） （数天） （数天~数周）

9.2 决策树关键节点

L3 最佳实践

9.3 升级到 OEM Support 的判定

关键边界

以下情况必须升级到 OEM Support：

• ❗管理门户无法登录
• ❗多节点同时不可用
• ❗Scale Unit 进入降级状态且自动恢复失败
• ❗备份还原失败
• ❗任何"管理员无法自助解决"的故障

L3 最佳实践：不要在"尝试自己修"上花费过多时间。Azure Stack Hub 的故障恢复不是管理员能独立完成的，及时升级到 OEM Support 是正确的工程决策。

10. 本篇小结

本篇以 Azure Stack Hub 云恢复（Cloud Recovery）为主线，完成了从灾难场景识别到多阶段恢复流程的完整图谱。

核心要点回顾：

1. 云恢复是 OEM 主导的多阶段工程—— 不是"重启就好"，而是"重新搭一台云"
2. 两种灾难场景路径完全不同—— 数据丢失（数天）vs 硬件不可恢复（数天~数周）
3. 五个阶段强依赖—— Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4，不可跳过不可并行
4. Phase 0 + Phase 1 由 Dell 主导—— Phase 2~4 由用户主导
5. 恢复模式部署是云恢复的硬约束—— 不是管理员能选择的选项
6. 版本匹配由 OEM 处理—— Dell 根据备份版本和最新受支持版本做匹配
7. ASDK 是验证手段不是替代—— 测试备份可用性的开发工具包，不能替代生产云恢复
8. 责任划分清晰—— Dell / 管理员 / 租户三方在每个阶段的角色明确

第三篇将展开：

• 数据保护和恢复选项全景—— Azure Stack Hub 上可用的备份 / 复制方案总览
• IaaS VM 备份 / 还原方案—— 租户级 VM 备份的产品选择与工程实现
• Azure Site Recovery 复制—— 跨云端的 VM 复制与故障转移
• Azure Backup Server—— 在 Azure Stack Hub 上部署 Azure Backup Server 的工程实践
• 现代应用（容器 / 微服务）的备份策略—— 与传统 VM 备份的本质差异

本系列下一篇：[下篇] Azure Stack Hub 用户虚拟机保护：IaaS VM 备份、Site Recovery 复制与 Azure Backup Server 工程实践