带 Marketplace 产品代码的虚机还原到 AWS 或 Azure 失败：撞上的是许可墙

症状：还原失败，日志指向市集

把虚拟机还原到 AWS 或 Azure，任务失败。翻日志，部分条目显示与无效 Marketplace 部署、产品代码限制相关的 API 错误。换个本地平台还原同一份备份却一切正常——问题不在备份链路上。

根因：云商给市集实例的重设置了卡

这类问题的源头虚拟机，通常是从 AWS Marketplace 或 Microsoft Marketplace 部署的，实例身上带着产品代码。云服务商对基于 Marketplace 的实例如何重新创建有严格限制：跨平台还原、走自定义路径重建这类动作，会被直接阻止。换句话说，失败不是故障，是许可层面的墙——备份侧再怎么重试也翻不过去。

责任边界：两句话读清

群晖官方在这件事上划了两条线，做容灾方案前应该抄进方案里：

• 免责线：对无法还原、激活或维持第三方 Marketplace 软件的计费与授权状态，群晖不承担责任；数据还原成功，也不构成对第三方软件任何合法使用权的转让或授予。
• 用户责任线：从云平台与第三方软件商处获得、接受并维持所有必要的许可、法律条款、同意和权限，是使用者自己的事——备份、还原、重新部署的每一步都建立在这个前提上。

处置思路

与其反复重试同一条还原路，不如先确认源机的来路：系统盘来自市集镜像的，按云商允许的市集路径重建实例，别走跨平台克隆；自建镜像或可替换的部分，用合规镜像重建实例后，把数据盘内容恢复回去。拿不准许可口径，带着日志与镜像来源去问云商支持，比换工具硬试省事得多。

小结

云还原能不能成，一半取决于技术，一半取决于许可。备份工具管得了前一半，管不了后一半——把这一条写进容灾预案，演练当晚就少一次意外。

诚鑫致达科技盘云上资源时，会给 Marketplace 来源的实例单独打一个标——还原方案评审看到这个标就绕行，许可墙不硬碰，演练照常走得通。