技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战！

当您需要实施某种基于云的系统恢复技术时,您有两种路线可以选择，但费用和风险各不相同。

备份通常都是个很好的策略。您需要有能力在某个地方备份数据和应用程序，以便在某些自然或人为灾难的情况下依旧可以保持业务的运行，避免关键系统的崩溃。

我们拥有提供备份站点和备份技术的完整解决方案。它们可以是被动式的，这意味着您可以在短时间内恢复站点并重新开始运营。或者也可以是主动式的(成本更高)，这意味着可以在用户不知情的情况下，用当前的数据和代码重新发布和接管被禁用的系统。

在云计算的环境中，灾难恢复包含了一组新的选项，它们看起来与您在本地系统中拥有的选项大不一样。您最终采取的方法应该与应用程序和数据集对业务价值的大小相匹配。我建议您仔细考虑所有这些操作选项的实用性，确保您的花费不会超过灾难恢复配置所带来的价值。

选项1：区域到区域的灾难恢复

您可以在同一个公共云提供商中设置两个或更多区域来提供灾难恢复能力。所以，如果Virginia区域被移除，那么该国其他地区就可以接管。

你可以花钱将数据和应用程序的精确副本复制到备份区域，这样它们就可以无缝地接管(即主动恢复)。或者你可以使用更经济有效的方法，比如按计划备份到被动式大容量存储器，以便快速地在另一个区域重新开始运营(即被动恢复)。

选项2：云到云的灾难恢复

我遇到的最常见的问题是：如果整个公共云提供商被摧毁或长期停运时，我们该如何保护自己?

例如，使用一个公共云来提供对另一个公共云的备份，可以让您使用Amazon Web服务来备份Azure，或者反过来，或者做一些其他的配对。

虽然这似乎是灾难恢复的终极目标——也是规避风险的终极目标——为了支持灾难恢复，多云计算意味着需要保留两个不同的技能集，拥有两个不同的平台配置，以及其他成本和风险。

然而,进行云对云的系统复制(又称云间复制)大大增加了出错的可能性。尤其是在尝试复制主备份平台时，这绝对不是您所希望看到的。虽然并非不可能，但云间复制可能比在同一供应商内的云内复制困难五倍。这就是为什么除了少数例子之外，支持云间复制的机构几乎不存在的原因。

【编辑推荐】