Azure Stack Hub 云恢复：从灾难性数据丢失到 Scale Unit 重建的多阶段实战

未经同意，请勿转载！

本文以 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 备份与灾难恢复》整理，按照文档编写准则做工程化改写。

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

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

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

1.1 云恢复的目标

L1 微软硬要求

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

层面	含义
基础设施	Scale Unit 重新具备 Azure Stack Hub 平台能力（计算 / 网络 / 存储 / 管理平面）
用户配置	还原基础架构"个性"（订阅 / Plans / Offers / RBAC / Key Vault 等）------ 这一部分依赖上篇介绍的 Infrastructure Backup

1.2 云恢复 vs 普通恢复

维度	云恢复	普通故障恢复
触发场景	灾难性数据丢失（多节点 / 多组件故障导致平台状态不可恢复）	单组件故障（节点重启 / 磁盘更换 / 网络切换）
执行主体	OEM 主导（Dell / Lenovo / HPE 等）	Scale Unit 自动恢复（多副本机制）
耗时	数天到数周	分钟级
数据来源	Infrastructure Backup 还原	实时副本 / 镜像
租户影响	长时间不可用（数小时到数天）	短暂降级或零影响
重新部署	是（必须重新部署 Azure Stack Hub）	否

关键认知 ：云恢复不是"重启一下就好"的运维动作，而是"重新搭一台云"的工程动作 。它涉及 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 场景对比

维度	灾难性数据丢失	硬件不可恢复
触发条件	多节点 / 多组件同时故障导致平台状态不可恢复	关键硬件（HLH / BMC / Scale Unit 节点 / ToR）物理损坏
硬件状态	硬件仍然可用	硬件不可用（需更换）
恢复路径	重新部署 + 从备份还原	更换硬件 + 重新部署 + 从备份还原
所需时间	数天（不含硬件等待）	数天到数周（含硬件订购 + 物流 + 上架）
业务影响	Scale Unit 重建期间业务不可用	Scale Unit 重建期间业务不可用 + 新硬件到位前的等待期

2.2 场景识别的关键问题

L3 最佳实践

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

硬件是否完全可用？
- 所有 Scale Unit 节点可启动？
- ToR / BMC 交换机可访问？
- HLH 可访问？
- 存储池状态正常？
平台状态是否可恢复？
- 管理门户是否可登录？
- 基础设施备份是否可触发？
- 租户 VM 是否还能访问（即使降级）？
故障的根因是什么？
- 已知原因（如计划内维护失败）？
- 未知原因（需要 OEM 工程师现场诊断）？

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

2.3 恢复时间期望

阶段	时间量级	主导方
Phase 0：硬件就绪	数天到数周	Dell（OEM）
Phase 1：云恢复	< 1 周	Dell（OEM）
Phase 2：PaaS 恢复	数天	用户 + Dell
Phase 3：IaaS VM 恢复	数小时到数天	用户
Phase 4：用户数据恢复	数小时到数周到数月	用户

关键含义 ：云恢复的主体（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：硬件就绪

项目	内容
目标	让 Scale Unit 具备重新部署的硬件条件
主导方	OEM（Dell 等）
动作	• 评估现有硬件可用性 • 订购更换硬件（如不可用） • 上架 / 加电 / 接线 • 验证硬件完整性
耗时	数天（硬件可用时）到数周（需订购新硬件时）
依赖	无（云恢复的起点）
管理员职责	配合 OEM 工程师、提供机房访问、必要时协调硬件采购流程

Phase 1：云恢复

项目	内容
目标	还原 Azure Stack Hub 的"个性"（身份 / 部署参数 / 基础设施配置）
主导方	OEM（Dell 等）
动作	• 在恢复模式下重新部署 Azure Stack Hub • 指定备份存储位置和凭据 • 触发基础设施数据还原 • 验证管理平面可用
耗时	< 1 周
依赖	Phase 0 完成（硬件就绪）
管理员职责	提供备份存储 UNC 路径 / 凭据 / 预共享密钥（详见上篇 §8 / §9 / §10）

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

Phase 2：PaaS 恢复

项目	内容
目标	还原 PaaS 资源和数据（SQL / MySQL / App Service 等）
主导方	用户（管理员 / 租户） + OEM 协助
动作	• 重新创建 PaaS 服务实例 • 从租户备份还原数据 • 验证服务可用性
耗时	数天
依赖	Phase 1 完成（管理平面可用）
管理员职责	协调租户、提供 PaaS 资源创建所需的 Plan / Offer

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

Phase 3：IaaS VM 恢复

项目	内容
目标	还原用户 IaaS VM
主导方	用户（管理员 / 租户）
动作	• 从租户备份还原 VM • 重新连接网络 / 磁盘 • 验证应用可用性
耗时	数小时到数天
依赖	Phase 2 完成（PaaS 服务可用）
管理员职责	协调租户、提供必要的网络 / 存储配额

Phase 4：用户数据恢复

项目	内容
目标	恢复应用层数据（数据库 / 文件 / 对象存储等）
主导方	用户（租户主导业务恢复）
动作	• 恢复数据库 • 恢复文件存储 • 验证业务数据完整性
耗时	数小时到数周到数月
依赖	Phase 3 完成（VM 可用）
管理员职责	通常不直接参与；按需提供基础设施支持

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 主导方矩阵

阶段	主导方	配合方	关键动作
Phase 0	Dell	用户（提供机房 / 采购流程）	硬件评估、更换、上架
Phase 1	Dell	用户（提供备份信息）	重新部署、备份还原
Phase 2	用户	Dell 协助	重建 PaaS 实例、还原数据
Phase 3	用户	---	还原 IaaS VM
Phase 4	用户	---	恢复业务数据

4.2 责任划分的关键判断

L1 微软硬要求

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

4.3 管理员的角色定位

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

阶段	管理员角色	关键动作
Phase 0	协调者	配合 OEM 现场工作、提供机房访问、必要时协调采购
Phase 1	信息提供者	提供备份存储位置、凭据、密钥等关键信息
Phase 2	主导者（与租户协同）	重新创建 PaaS 实例、协调租户还原数据
Phase 3	主导者（与租户协同）	协调租户还原 IaaS VM
Phase 4	支持者	按租户业务需求提供基础设施支持

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

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

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

5.1 部署模式对比

部署模式	起点	终点	适用场景
全新安装	初始配置	Dell 部署 Azure Stack Hub 并更新到最新的受支持版本	新部署、灾备新建
恢复模式	初始配置	Dell 在恢复模式下部署 Azure Stack Hub 并根据可用的最新备份处理版本匹配要求，Dell 通过更新到最新的受支持版本来完成部署	云恢复（灾难性数据丢失后）

5.2 模式差异的本质

关键认知

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

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

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

5.3 何时选择哪种模式

场景	部署模式
新部署 Azure Stack Hub	全新安装
现有 Scale Unit 灾难性数据丢失	恢复模式
现有 Scale Unit 硬件不可恢复 + 新硬件到位	恢复模式
测试云恢复流程	恢复模式（在 ASDK 上，详见 §7）

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

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

时机	管理员动作	关键性
部署前	验证备份共享可访问、凭据正确、密钥有效	关键------备份不可用意味着恢复失败
部署期间	配合 OEM 提供所需的备份信息	关键------信息错误会导致恢复失败
部署后	验证管理平面可用、Phase 1 里程碑达成	关键------避免在后续阶段才发现问题

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

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

6.1 版本匹配的处理逻辑

L3 最佳实践

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

复制代码

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

6.2 版本匹配的可能场景

场景	含义	影响
备份版本 = 最新受支持版本	备份时已经是最新版本	部署完成即可用，无需大规模更新
备份版本 < 最新受支持版本	备份时是早期版本	部署后需要补齐多次更新才能达到最新版本
备份版本 > 当前部署时支持的版本	备份来自比当前 OEM 支持矩阵更新的版本	OEM 评估是否可恢复------通常需要降级处理或 OEM 评估兼容性

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

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

L3 最佳实践

备份版本与最新版本差距	恢复时间影响
1~2 个版本差距	+数小时（更新耗时）
3~5 个版本差距	+1~2 天（多次更新 + 验证）
6+ 个版本差距	+数天（多次更新 + 兼容性风险）

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

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

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

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

L3 最佳实践

价值	说明
零风险验证	在开发工具包上测试完整云恢复流程，不影响生产
流程熟悉	管理员在真正灾难发生前已经走通整个流程
备份验证	验证生产备份在恢复模式下确实可用
时间预估	获得真实的恢复时间数据，用于 BCP 文档
培训价值	OEM 工程师和内部运维团队都可以在 ASDK 上练习

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-AzSBackup cmdlet 完成还原：

复制代码

# 在 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 测试	生产云恢复
目的	验证手段	恢复手段
环境	单服务器 / 开发工具包	OEM 集成系统
主导方	用户（管理员自行执行）	OEM 主导
耗时	数小时到 1 天	数天到数周
硬件要求	普通服务器即可	OEM 集成系统
网络要求	简化网络（ASDK 默认配置）	生产级网络

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

7.4 ASDK 测试的推荐频率

L3 最佳实践

频率	价值
每季度 1 次	验证备份持续可用、流程熟悉
每次平台重大更新后	验证更新后备份仍可还原
每次备份策略变更后	验证新策略的有效性
年度 BCP 演练	纳入企业 BCP 流程，作为 DR 演练的一部分

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

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

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

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

8.1 三方责任矩阵

阶段	Dell（OEM）	管理员（Azure Stack Hub Operator）	租户
Phase 0：硬件就绪	主导（评估 / 订购 / 上架）	配合（机房 / 采购）	无
Phase 1：云恢复	主导（重新部署 / 备份还原）	配合（提供备份信息）	无
Phase 2：PaaS 恢复	协助	主导（重建 PaaS 实例）	配合（数据还原）
Phase 3：IaaS VM 恢复	无	主导（协调 VM 还原）	主导（VM 内数据）
Phase 4：用户数据恢复	无	支持（基础设施）	主导（业务数据）

8.2 管理员的关键交付物

L3 最佳实践

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

阶段	交付物	接收方
Phase 0	机房访问授权、机柜布局图、网络配置文档	Dell 工程师
Phase 1	备份 UNC 路径、访问凭据、预共享密钥	Dell 工程师
Phase 2	PaaS 资源配额审批、Plan / Offer 配置	租户
Phase 3	IaaS VM 网络 / 存储配额、可用订阅列表	租户
Phase 4	基础设施支持（如租户需要额外配额）	租户

8.3 灾难沟通的关键时点

L3 最佳实践

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

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

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

9. 恢复路径决策树

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

9.1 故障识别决策

复制代码

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

9.2 决策树关键节点

L3 最佳实践

节点	判断标准	决定
硬件可用性	所有节点可启动、ToR / BMC / HLH 可访问	是 → 继续；否 → 走硬件更换路径
平台状态	管理门户可登录、备份可触发、租户 VM 可访问	是 → Scale Unit 自恢复；否 → 走云恢复
数据丢失严重程度	单节点 vs 多节点；可恢复 vs 不可恢复	决定云恢复的紧急程度

9.3 升级到 OEM Support 的判定

关键边界

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

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

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

10. 本篇小结

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

核心要点回顾：

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

Azure Stack Hub 云恢复：从灾难性数据丢失到 Scale Unit 重建的多阶段实战

修订说明：

目录

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

1.1 云恢复的目标

1.2 云恢复 vs 普通恢复

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

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

2.1 场景对比

2.2 场景识别的关键问题

2.3 恢复时间期望

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

3.1 五阶段时间线

3.2 阶段详情

Phase 0：硬件就绪

Phase 1：云恢复

Phase 2：PaaS 恢复

Phase 3：IaaS VM 恢复

Phase 4：用户数据恢复

3.3 阶段间依赖关系

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

4.1 主导方矩阵

4.2 责任划分的关键判断

4.3 管理员的角色定位

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

5.1 部署模式对比

5.2 模式差异的本质

5.3 何时选择哪种模式

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

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

6.1 版本匹配的处理逻辑

6.2 版本匹配的可能场景

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

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

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

7.2 ASDK 测试云恢复的步骤

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

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

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

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

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

7.4 ASDK 测试的推荐频率

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

8.1 三方责任矩阵

8.2 管理员的关键交付物

8.3 灾难沟通的关键时点

9. 恢复路径决策树

9.1 故障识别决策

9.2 决策树关键节点

9.3 升级到 OEM Support 的判定

10. 本篇小结