APM2.0：如何规划 AWS、Azure、SaaS 与本地工作负载备份？

概述

2026 年 9 月更新：APM 2.0 为混合云备份带来什么？

Synology 于 2026 年 9 月 3 日正式发布 ActiveProtect Manager 2.0。它把五类本地与云端工作负载纳入同一套管理体系。同时维护本地虚拟化、AWS 与 Azure 的 IT 团队，可以围绕同一份 RPO/RTO 清单规划混合云备份和灾难恢复，过去散落在几套任务记录里的状态，也能收进同一张管理视图。

周一早上的备份例会，基础设施组查看本地虚拟机，云平台主管核对 Amazon EC2 和 Azure VM，协作平台管理员再汇报 Google Workspace。异地副本可能还在 NAS 或对象存储里。平时各套任务分别运行，现场很少觉得麻烦；站点故障、云账号异常或勒索事件发生后，恢复人员却要在有限时间内找齐恢复点、目标资源、网络和账号。这时，业务优先级比任务数量更重要。

APM 2.0 将保护范围扩展到五类工作负载：

• Amazon EC2
• Azure VM
• Proxmox VE
• Nutanix AHV
• Google Workspace

跨平台恢复给故障接管和基础设施迁移增加了目标选择；Azure Blob Storage 则提供了一条保存异地版本、长期版本的远程路径。两项能力落到项目里，都要先确定 APM 版本、源与目标平台支持范围、云账户权限、网络、资源配额和恢复方式。立项时把软件规格、Release Notes 与支持矩阵固化成版本基线，再拿代表性工作负载验证，后续升级也有据可查。

APM 负责把保护计划、保留规则、备份副本、告警和恢复操作收进一个管理入口。平台账号、接口、网络和目标环境由相应团队准备。日常管理由此集中起来，各平台的技术边界也保持清楚。

截至 2026 年 9 月 7 日的版本边界

Proxmox VE、Nutanix AHV、Amazon EC2、Azure VM、Google Workspace、跨平台恢复、Azure Blob Storage 目标和卷级软件加密属于 APM 2.0 已发布范围。AI/ML 异常检测、恢复前恶意软件扫描和 Auto Fallback 属于后续版本或路线图关注方向，记录在 APM 2.1 后续评估项中；APM 2.0 当前验收只覆盖已经发布的功能。

混合云备份为什么不能只看“备份是否成功”？

任务状态变绿，说明这次数据已经按计划写入备份位置。到了恢复现场，还要看恢复点能否读取、目标资源是否就绪、账号权限是否够用、网络能否互通，以及应用能否按顺序启动。缺少其中一环，业务恢复时间就会被拉长。

ERP 往往依赖数据库和身份服务，MES 还连着生产网络及接口服务；文件服务恢复后要保住原有权限关系；云虚拟机离不开订阅、IAM、安全组和区域资源；Google Workspace 数据则受管理员授权、用户范围和内部流程约束。备份系统保存数据、编排任务，恢复手册负责把这些业务关系交代清楚。

一条完整的恢复路径，至少要回答下面这些问题：

• 目标平台是否已经准备好计算、存储和网络资源？
• 云账户、订阅、IAM 或管理员角色是否覆盖备份与恢复操作？
• VLAN、安全组、路由、DNS 和 IP 地址怎样重建或切换？
• 身份服务、数据库、中间件和应用服务器按什么顺序启动？
• 驱动、镜像格式、许可证和资源配额是否满足目标环境要求？
• 恢复完成后，由谁验证数据时间点、应用功能和上下游连接？

RPO 描述企业能接受多大的数据回退，RTO 说明业务要在多长时间内恢复可用。业务影响、数据变化频率、人员响应和基础设施条件共同决定这两个目标，备份策略与恢复资源负责把目标落地。核心生产、研发测试和长期归档的要求相差很大，保护等级自然也要分开。

先定义恢复目标：RPO、RTO 与业务优先级

这张表最好在产品选型前完成。工作负载、业务负责人、保护计划和验收方式摆在一起，备份频率对应 RPO，预留资源、网络和操作流程则对应 RTO。

表里的目标由业务负责人确认。备份管理员据此制定频率、保留规则和副本计划，基础设施团队准备目标环境，应用负责人检查数据与功能。演练结束后，把实际耗时和发现的问题填回表中。RPO、RTO 与资源配置便有了下一轮调整的依据。

APM 2.0 如何覆盖混合云工作负载？

过去，本地集群、云上业务和协作数据往往分别登记在不同工具里，任务状态和恢复流程也各自维护。APM 2.0 把这三类来源统一收进同一个管理中心，用同一套统一策略和统一监控覆盖本地虚拟化、公有云虚拟机和 Google Workspace 协作数据，管理员不需要在多个控制台之间切换核对状态。

本地集群按各自虚拟化平台的接口和网络模型运行，云上业务保留原有账户和区域边界，协作数据延续原有的管理员授权体系；APM 2.0 统一收拢的是保护计划、任务状态、告警和恢复入口，让这些差异化的底层平台共用同一套管理与恢复流程。

统一策略让业务等级相近的工作负载可以共用备份频率和保留规则，统一监控把本地集群、云上业务和协作数据的任务健康度汇总在同一个界面里，管理员一次查看即可核对全部状态。

下面按工作负载类别分别说明接入 APM 2.0 时各自需要核对的技术细节。

本地虚拟化与私有云

不少企业的 VMware 和 Hyper-V 已经运行多年，Proxmox VE 与 Nutanix AHV 则逐渐出现在工厂、边缘站点、私有云或基础设施调整项目中。纳入 APM 2.0 后，管理员可以在 Management Center 里查看这些工作负载、保护计划、任务状态和恢复活动。

管理入口集中起来，底层差异依然存在。四类平台各有管理接口、变更跟踪机制、网络模型和虚拟磁盘约束。选型时要逐项核对可保护对象、支持版本、增量机制以及完整恢复、即时恢复的适用范围。试点先从一台接近生产配置的虚拟机开始，测出首次完整备份、后续增量任务和恢复过程对源平台及网络的影响。

当保护范围还包括国产数据库、国产服务器或其他超融合平台时，可参考国产数据库与超融合备份实践，把备份软件的工作负载保护职责与 NAS 的存储、副本职责分别规划。

AWS、Azure 与 Google Workspace

Amazon EC2、Azure VM 和 Google Workspace 纳入 APM 2.0 后，云虚拟机与协作数据可以沿用同一套策略框架和告警流程。过去分散在几套工具里的任务，更容易按业务等级归到一起。

云平台原生高可用处理其服务范围内的基础设施故障。企业自己的恢复方案还要照顾误删、账号异常、跨区域事件、应用配置损坏和历史版本回溯。AWS 一侧要登记账户、区域、IAM、实例磁盘、网络和目标资源；Azure 一侧要核对租户、订阅、资源组、区域、虚拟网络与配额；Google Workspace 则要明确管理员授权、用户与共享数据范围、离职账号处理和恢复责任人。

业务等级相近的工作负载可以共用备份频率与保留规则，账户边界、区域差异和数据主权要求分开记录。采购或上线前，团队先用支持矩阵确定保护对象、恢复粒度和目标范围，再在自己的云账户里跑通一次。

跨平台恢复：为恢复与迁移增加选择，但不替代验证

灾难发生时，跨平台恢复可以把合格的恢复点送往已经准备好的备用环境。基础设施调整前，同一能力也能用来验证工作负载在目标平台上的启动和运行状态。无论用于接管还是迁移，源与目标的映射都要提前做好。

恢复方案应确认：

1. 当前 APM 版本是否支持源工作负载、目标平台和计划使用的恢复方式。
2. 目标账户、订阅或集群账号是否具备创建资源、挂载磁盘和配置网络的权限。
3. 目标平台是否准备好计算、存储、区域和资源配额。
4. 安全组、VLAN、路由、IP、DNS 和负载均衡配置如何调整。
5. 操作系统驱动、启动方式、镜像或磁盘格式及应用许可证是否适配。
6. 身份服务、数据库、中间件、应用服务器和外部接口按什么顺序恢复。
7. 隔离启动、数据一致性检查、业务验收和正式切换由谁执行。

恢复流程从选定的恢复点出发，先完成目标映射，再按场景把工作负载送往原平台、其他云或其他平台；三条路径重新汇合到隔离启动，验证通过后才进入正式的业务切换。

检查结果写入恢复手册，隔离演练会把驱动、网络、权限和应用依赖问题提前暴露出来，也能测出这套架构实际达到的 RTO。

实施工程师依据产品支持矩阵和现场验证结果整理路径评估报告，业务方从中选定正式使用的恢复路径。

隔离启动环境通常复用与生产隔离的测试网段，验证数据库、应用和身份服务都能正常拉起后，才把访问入口切换到恢复后的环境；这一步验证通过，才是判断业务连续性达标的依据。

混合云备份副本架构如何选择？

副本放在哪里，取决于它准备应对什么问题。本地版本服务日常快速恢复，异地副本留给站点级故障，长期版本用于审计、追溯和合规保留，隔离或不可变副本则为勒索事件多留一条恢复路径。企业通常会组合使用几种位置，同时核算保留策略、恢复时间、网络连通性、对象存储取回模式、加密、密钥与演练成本。

这张表用于架构初选。到了部署阶段，每个目标都要回到 APM 版本、支持矩阵和现场拓扑，确认配置方法与恢复范围。接入 Azure Blob Storage 前，同一 ActiveProtect 站点内参与任务的备份服务器都要完成存储账户端点连通性测试，并覆盖 DNS、代理、防火墙、路由和访问控制。

主保护、副本和分层的整体设计可结合企业备份系统解决方案进一步梳理，重点核对副本独立性、保留规则和恢复目标是否匹配业务等级。

Azure Blob Storage 与分层策略：适合解决什么问题？

在 ActiveProtect 架构里，Azure Blob Storage 可以作为远程存储、备份副本或分层目标，用来承接异地版本、长期版本和云上灾难恢复的数据路径。目标类型、认证方式、任务范围与恢复方式，都要与部署时的软件规格对应。

快速恢复副本与长期保留副本分开设计

以 DP7200 / DP5200 这类本地设备为例，近期恢复点可以留在承担日常恢复任务的近期版本设备上，读取路径短、恢复速度快；较旧的版本随数据年龄增长逐步迁往远端设备或对象存储，本地容量随之释放出来接收新的备份任务。

昨夜的恢复点和一年前的恢复点，使用频率差别很大。近期版本常用于处理误删、升级失败和虚拟机故障，留在靠近生产环境的备份服务器上，读取路径更短。旧版本访问较少，移入远程存储后，可以腾出本地空间继续接收新备份。两类版本完全可以采用不同的目标、保留期和恢复窗口。

对象存储的账单由存储等级、最低保留要求、取回速度、API 请求、网络带宽和数据出入共同构成，加密与合规要求也会影响方案。分层改变的是数据在本地与远端的分布，费用和恢复时间仍取决于版本数量、变化率、去重效果、网络以及云端计费方式。容量初估可以从源数据量、每日变化率、本地与远端保留版本数开始，再用试点测得的去重效果和恢复耗时修正。

容量释放的效果会随分层比例、去重能力和历史版本保留策略变化，规划阶段建议先用一段有代表性的数据做小规模验证，再扩大到全量迁移。

Data Tiering 与 Tiering Plans 的配置逻辑

ActiveProtect 的 Data Tiering 按版本年龄把符合条件的旧版本迁往远程存储，近期版本继续留在备份服务器。Tier after 控制版本何时进入分层判断；业务恢复窗口、保留要求、数据变化和可用网络窗口共同决定这个值。测试环境可以先用一组示例参数观察机制，生产环境再根据实测结果定值。

管理逻辑可以按以下顺序执行：

1. 在 Infrastructure > Remote Storage 添加 Azure Blob Storage、Amazon S3、运行 ActiveProtect Vault 的 Synology NAS，或当前版本支持的其他远程目标。
2. 完成账号、存储目标和网络连接测试；Azure Blob Storage 还要逐台验证相关备份服务器至存储账户端点的连通性。
3. 在 Plans > Protection Plans 中设置备份副本，在 Plans > Tiering Plans 中建立分层计划。
4. 根据近期恢复窗口设置 Tier after、目的地、时区和任务检查时间，并评估首轮数据迁移对出口带宽的影响。
5. 在 Management Center 观察副本或分层任务状态，再从 Recovery Portal 浏览远端版本并执行下载或当前工作负载支持的恢复测试。

分层后的版本继续由 APM 管理，不过本地与远端版本走的是不同读取路径。恢复手册要写清对象存储不可用、认证失效或网络中断时如何处置。Amazon S3、Azure Blob Storage、ActiveProtect Vault 和 Synology NAS 放在哪一层，最终看站点位置、数据规模、取回要求与合规策略。

虚拟化接入参考：Proxmox VE 与 Nutanix AHV

下面按管理顺序梳理接入过程。界面字段、支持版本、保护对象和恢复方式，以部署时采用的软件规格与支持矩阵作为实施基线。

两类平台的接入流程基本一致：先在 Management Center 添加平台，再选择需要保护的虚拟机，为其配置保护计划，最后执行一次恢复测试确认可用。

首轮备份完成后要紧接着做恢复测试，用能否成功恢复来检验这轮保护是否真正生效——这是接入新虚拟化平台时最容易被跳过的一步。

下面分别说明 Proxmox VE 与 Nutanix AHV 在这套流程里各自需要额外核对的技术细节。

Proxmox VE 保护与恢复注意事项

APM 2.0 将 Proxmox VE 上的 QEMU/KVM 虚拟机纳入保护范围，增量任务通过 QEMU dirty bitmaps 识别变化数据。接入前先登记 Proxmox VE 版本、集群与资源池结构、虚拟机操作系统、磁盘格式、标签、网络、管理凭据和恢复目标，再与 APM 支持矩阵逐项核对。

管理流程通常包括：

1. 在 Management Center 的 Infrastructure > Hypervisors 中添加 Proxmox VE，配置服务器地址和管理凭据。
2. 在 Machines > Virtual Machines 中选择虚拟机、承载任务的备份服务器和保护计划；批量纳管可结合服务器、资源池或标签规划自动保护规则。
3. 运行首次完整备份，观察源主机、网络和备份服务器负载，再根据实际变化量安排后续窗口。
4. 在 Recovery Portal 中验证文件恢复、完整虚拟机恢复，以及当前版本支持的即时恢复或跨平台恢复路径。

当前软件规格把虚拟化层保护对象限定在受支持版本的 QEMU/KVM 虚拟机。LXC 容器和链接克隆要单独记入保护缺口，再按数据类型选择已经验证的其他方式。采用 raw 磁盘镜像时，虚拟机关机或重启可能影响 changed block bitmap 的持续性，下一次任务可能转为完整备份。网络容量和备份窗口需要预留这部分波动。

恢复演练要覆盖目标集群容量、桥接网络或 VLAN、IP、DNS、启动方式、驱动和应用依赖。跨平台恢复则从支持矩阵列明的组合中选择，并在自己的环境中跑通。

Nutanix AHV 保护与恢复注意事项

Nutanix AHV 通常通过 Prism Central 或受支持的集群管理地址接入，APM 使用 Changed Region Tracking（CRT）读取虚拟机的变化数据。AOS、Prism Central、虚拟机操作系统和恢复方式各有兼容范围。版本、访问权限、证书、网络路径和计划启用的保护功能，都要写进项目基线。

参考流程如下：

1. 在 Infrastructure > Hypervisors 中选择 Nutanix AHV，填写 Prism Central 或集群地址及管理账号。
2. 在 Machines > Virtual Machines 中选择需要保护的虚拟机、备份服务器和保护计划；自动保护规则可以按当前版本支持的集群、Prism Central 或 Category 范围设计。
3. 运行首次完整备份并观察快照、网络和备份窗口，后续任务通过 CRT 读取变化区域。
4. 在隔离网络执行文件、完整虚拟机及当前版本支持的即时恢复测试，检查应用启动、数据库一致性和上下游连接。

Nutanix 的网络和附加配置会直接影响恢复完整性。当前软件规格列出的网络配置备份范围是 VLAN 型子网关联。挂载到虚拟机的 Volume Group、VM-Host Affinity，以及 VPC overlay 子网、私有 IP 和浮动 IP，要在恢复手册中单独登记，并安排重建。跨 VLAN、跨 VPC 或跨环境恢复时，目标网络、IP、路由、安全策略和 DNS 切换都要提前准备。

验收时，基础设施团队检查虚拟机、磁盘、网络和主机资源，应用团队再检查数据库、中间件、身份认证、许可证与业务数据。两组结果合在一起，才能确认业务已经恢复可用。

接入新的虚拟化或云平台之后，工作重心会从“完成首轮备份”逐步转向日常运行：备份任务持续执行，告警和异常需要有人处理，恢复演练要按周期安排，业务验收结果要留痕。

备份任务是这个闭环的起点，告警处理紧随其后，当天把失败任务、容量预警和权限变更这类信号消化掉，避免积压到下一次巡检。

恢复演练把“备份成功”兑现成“确实能恢复”，业务验收由使用方确认数据和功能都可用，作为IT团队之外的独立确认环节；两步验证结果反过来决定下一轮备份策略是否需要调整，形成持续验证。

下面的检查清单，就是把这套闭环拆解成上线前可以逐项核对的具体条目。

上线前：混合云备份架构检查清单

• 已识别本地虚拟化、AWS、Azure、SaaS、文件服务和长期归档的保护对象，并标明业务负责人。
• 已为每一类业务设置 RPO、RTO、恢复优先级和验收责任人。
• 已定义应用恢复顺序、依赖系统、DNS、IP、身份认证、VLAN、安全组和网络要求。
• 已核对云账户、订阅、IAM、管理员角色、资源配额、目标区域和恢复资源创建权限。
• 已验证 Proxmox VE、Nutanix AHV、VMware、Hyper-V 及计划使用的目标环境版本兼容性。
• 已规划主保护位置、副本位置、对象存储分层、不可变保留和版本保留策略。
• 已验证 Azure Blob Storage 或其他远程存储目标的端点、DNS、路由、防火墙及认证连通性。
• 已评估加密、密钥托管、不可变性/WORM、RBAC、日志、SNMP trap、Syslog 和恢复审批要求。
• 已定义备份失败、对象存储不可用、云账户权限异常和目标环境资源不足时的处置流程。
• 已执行文件、整机、云上或跨平台恢复演练，并覆盖隔离启动和业务验证。
• 已记录恢复点、实际恢复时间、数据一致性、依赖问题、业务验收结果和改进项。
• 已建立变更管理，覆盖 APM 版本、代理、云权限、网络、保留策略、分层目标和恢复手册。

安全与审计配置要落到日常值班流程里。卷级软件加密配套密钥保管、恢复使用和人员交接制度；RBAC 划分总部管理员、站点运维、审计人员与恢复操作员的权限；SNMP trap、Syslog、邮件和日志平台把任务失败、容量变化及系统事件送入现有告警渠道。WORM、不可变保护、异地副本和隔离恢复环境负责保住恢复点，演练再检验这些恢复点能否支撑业务。

成都及西南企业怎样咨询 ActiveProtect Manager 2.0 部署？

评估可以从一张资产与恢复目标表开始：先写入本地虚拟化、AWS、Azure、Google Workspace、NAS 和长期归档数据，再补上业务负责人、RPO、RTO、恢复顺序、主保护位置、副本位置与演练方式，项目组从中选一项有代表性的业务做试点。

美步科技作为群晖 Synology 授权代理与方案集成商，可协助西南地区企业梳理工作负载兼容性、ActiveProtect 站点拓扑、对象存储副本、分层策略和恢复验证范围。沟通前准备好平台及版本清单、数据规模、每日变化情况、现有网络、云账户边界、保留要求和目标恢复位置，评估会更具体。

获取ActiveProtect Manager 2.0部署与架构评估建议

本文资料来源：Synology 官方发布公告、ActiveProtect Manager 软件规格与知识库文档综合整理，具体功能以 DSM 实际版本界面为准。详细引用清单详见文末“参考来源”区块。