很多企业制定了多云备份策略，但这并不意味着应该这样做。企业需要权衡这种方法带来的挑战和潜在收益。
如果企业希望将其备份策略扩展到云端，则多云灾难恢复可能不是首选。云计算或私有数据中心发生故障的风险是引起多云架构关注的主要因素。虽然一般来说，数据备份是一种降低风险的行之有效的策略，但有时它可能带来比解决方案更多的问题。企业管理员需要权衡风险，并询问自己多云灾难恢复计划是否适合其工作负载。
故障注意事项
关于复杂系统的可靠性，有一个简单的经验法则：如果两个元素可以执行相同的任务，则它们可以互相备份。这降低了故障的综合风险。相反，如果两个要素都必须积极工作才能使复杂的系统正确运行，则发生故障的风险会更高。
因此，要使两个云平台比一个云平台更可靠，每个云平台必须是一个独立的资源池，能够支持针对备份的应用程序。对于选择多云灾难恢复策略的组织来说，这会深刻影响架构选择、成本和其他因素。
此外，企业不太需要多云提供的灾难恢复冗余服务，因为单个故障导致数据中心和云计算瘫痪或中断的可能性非常小。减轻风险的一种更简单的方法是使用一个云平台进行备份，并在整个可用区域中分配。然后，构建混合云体系结构(云计算灾难恢复的首选方法)的企业可以使其数据中心和云计算环境相互备份。
幸运的是，无论架构师为混合云灾难恢复还是多云灾难恢复而构建，应用程序更改和云计算服务选择都基本相同。
为了使用多云灾难恢复，企业需要能够跨边界(包括跨云平台和本地数据中心)无缝移动工作负载。必须将应用程序构建为可在任何地方运行，并且运营团队需要将所有托管资源视为一个资源池。对这两种做法的任何限制都会减少多云灾难恢复的好处并增加成本。
企业还需要考虑公共云服务的两个级别以及每个级别对多云备份策略的影响：
- IaaS托管。云计算提供商在不同地理位置为虚拟机提供每个虚拟机不同的资源和不同的服务级别协议。尽管云计算提供商的运营实践通常有所不同，但适应这些差异并不复杂。
- 增强Web服务的托管。企业通过一组API使用高级功能。通常，由于功能和编程方面的差异，必须为每个云平台自定义使用Web服务的应用程序。这使开发负担加倍，也可能增加许可和运营成本。
容器和微服务
如果将每个云平台为多云计划的一部分进行单独管理，则在没有人工干预的情况下，很难在环境之间进行故障转移。
企业有两种选择可以缓解这个问题。首先是放弃云计算提供商的运营工具。例如，放弃托管的Kubernetes，转而使用Red Hat OpenShift或VMware vSphere等工具从数据中心运行Kubernetes生态系统。另一个选择是通过联合方法将企业的云计算提供商托管服务与诸如Google Cloud Anthos或IBM的Kabanero之类的工具连接起来。
使用微服务和服务网格(例如Istio或Linkerd)构建支持多云的应用程序更加容易。但是，这种方法要求软件重建对于某些组织来说可能是一个巨大的飞跃。如果企业选择这种方法，则需要将服务网格与操作工具集成在一起。服务网格包括跨云分布的组件发现以及工作负载平衡。
成本要求
企业必须权衡多云灾难恢复的成本和它将增加的可靠性。不幸的是，几乎不可能对这些因素进行精确的分析，因为为多云灾难恢复准备应用程序的成本取决于所涉及的应用程序数量及其设计方式。
与弹性应用程序部署和重新部署相关的成本取决于这些相同的因素，而企业的操作实践决定了恢复对问题的响应速度，这是获得可靠性的重要因素。
不管可靠性如何，多云灾难恢复无疑将增加托管成本。如果企业的备份资源无法将工作从另一个发生故障的托管点转移到灾难恢复中，则没有任何价值，因此企业将必须在每个云中保留一些容量以支持任何故障转移。这可能会使企业的云计算托管成本增加至少25%，并且如果企业所有的应用程序都无法忍受很少的停机时间，甚至可能会使成本翻倍。
唯一的例外是无服务器。由于它遵循按使用付费的定价模式，因此无论企业的组件运行哪种云平台，其费用都趋于相同。但是需要记住，无服务器可能是一个更昂贵的托管选项，特别是对于需要经常运行的应用程序，并且它需要更专业的应用程序设计。
多云不只是灾难恢复
对于大多数企业来说，多云发现可能不会带来回报，但这并不意味着使用多云是一个坏主意。许多企业依靠多云技术为全球运营提供有效的云计算服务定位。有些应用程序需要特殊功能，而不是由所有云计算提供商提供，因此它们最终会为不同的应用程序使用不同的云平台。
规划多云意味着企业正在为任何云平台做好准备。始终保持选择的开放是明智之举，尤其是在公共云提供商的格局不断发生变化的情况下。
