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 Backup1.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硬件就绪数天到数周DellOEMPhase 1云恢复 1 周DellOEMPhase 2PaaS 恢复数天用户 DellPhase 3IaaS 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 具备重新部署的硬件条件主导方OEMDell 等动作• 评估现有硬件可用性 • 订购更换硬件如不可用 • 上架 / 加电 / 接线 • 验证硬件完整性耗时数天硬件可用时到数周需订购新硬件时依赖无云恢复的起点管理员职责配合 OEM 工程师、提供机房访问、必要时协调硬件采购流程Phase 1云恢复项目内容目标还原 Azure Stack Hub 的个性身份 / 部署参数 / 基础设施配置主导方OEMDell 等动作• 在恢复模式下重新部署 Azure Stack Hub • 指定备份存储位置和凭据 • 触发基础设施数据还原 • 验证管理平面可用耗时 1 周依赖Phase 0 完成硬件就绪管理员职责提供备份存储 UNC 路径 / 凭据 / 预共享密钥详见上篇 §8 / §9 / §10L1 微软硬要求Phase 1 是 OEM 主导的重新部署动作——管理员不能自行启动。即使管理员手上有合法凭据和备份重新部署动作仍由 OEM 执行。Phase 2PaaS 恢复项目内容目标还原 PaaS 资源和数据SQL / MySQL / App Service 等主导方用户管理员 / 租户 OEM 协助动作• 重新创建 PaaS 服务实例 • 从租户备份还原数据 • 验证服务可用性耗时数天依赖Phase 1 完成管理平面可用管理员职责协调租户、提供 PaaS 资源创建所需的 Plan / Offer关键认知Phase 2 由用户主导——OEM 在 Phase 1 完成了平台恢复PaaS 服务实例需要用户按业务需求重新创建详见第三篇关于租户备份的讨论。Phase 3IaaS 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 0Dell用户提供机房 / 采购流程硬件评估、更换、上架Phase 1Dell用户提供备份信息重新部署、备份还原Phase 2用户Dell 协助重建 PaaS 实例、还原数据Phase 3用户—还原 IaaS VMPhase 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 VMPhase 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 测试基础设施还原ASDKAzure 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-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 测试生产云恢复目的验证手段恢复手段环境单服务器 / 开发工具包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 三方责任矩阵阶段DellOEM管理员Azure Stack Hub Operator租户Phase 0硬件就绪主导评估 / 订购 / 上架配合机房 / 采购无Phase 1云恢复主导重新部署 / 备份还原配合提供备份信息无Phase 2PaaS 恢复协助主导重建 PaaS 实例配合数据还原Phase 3IaaS VM 恢复无主导协调 VM 还原主导VM 内数据Phase 4用户数据恢复无支持基础设施主导业务数据8.2 管理员的关键交付物L3 最佳实践云恢复过程中管理员应在每个阶段向相关方交付以下内容阶段交付物接收方Phase 0机房访问授权、机柜布局图、网络配置文档Dell 工程师Phase 1备份 UNC 路径、访问凭据、预共享密钥Dell 工程师Phase 2PaaS 资源配额审批、Plan / Offer 配置租户Phase 3IaaS VM 网络 / 存储配额、可用订阅列表租户Phase 4基础设施支持如租户需要额外配额租户8.3 灾难沟通的关键时点L3 最佳实践云恢复过程中管理员应在以下时点主动沟通Phase 0 启动时—— 通知所有相关方管理层、业务部门、租户Phase 1 启动时—— 通知 OEM 工程师进度、提供备份信息Phase 1 完成时—— 通知租户平台已就绪启动 Phase 2Phase 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 工程实践