一旦遭遇灾难，响应必须敏捷、快速。火灾、洪水或勒索软件，给企业造成的损失无比高昂，急需以现代的灾备手段应对。

传统的厂商私有+高度定制系统，现代的工业标准化+开箱即用模块，所能提供的灾备能力大相径庭。云上的即开即用方式基于工业标准化，能提供额外的强大保护能力。

多中心化，是灾备的一种模式，其思路是一个中心数据丢失不可怕，另一中心立刻启用就行。因此，站点位置相距越远越好。

可多中心的最大问题是成本。每增加一镜像中心，根据备份的数据量多少，IT基础架构支出会多出50%-100%，这还不算额外的能源消耗、设备养护、人员维系等负担。私有系统+二次开发的模式，势必导致这种局面。

磁带备份，是传统灾备选项之一。数据到磁带虽然方便，但耗时良久（几小时-几天）。因此，备份到云，而非磁带，也适合一些希望拿来就用的企业。

云更方便灾备

因为云，开箱即用型方案能让灾备更温馨。私有云内的多数应用都运行于虚拟机，因此向公有云迁移不是难题。

实现这个有几种方法。其一是选择弹性云，当产生额外的负载时云自动匹配新资源。作者申明，数据托管对RTO非常重要，但本文不会讨论数据托管的任何细节。

此外，终端备份系统会拷贝近期数据和运行实例，以便灾备时快速恢复。然而使用了公共云，这种开销则无需维持了，因为公共云可在几分钟内在生产系统上准备好近期数据和实例，立刻可用。Docker容器比传统的hypervisor快很多，是未来的RTO热点。

灾备的重点，不是优化备份工具，而是如何快速恢复数据，这个从来都不简单。保证文件存在于正确的地方，保证恢复文件的途径始终正确，这个非常棘手。灾备实施团队所面临的，永远都是10年一遇的问题。

细分灾备方案

将讨论的是“灾备即服务（DRaaS）”。管理层需要明确，业务连续性的计划实施，是自行处理还是托付于人。无论选择哪条路，机会成本都很大，因为导致业务中断的损失是天文数字。

选择哪条路，需要很好的TCO分析。单个产品也许无法适配，混搭方案也许行之有效。

如下情况，可选择云备份：

• 业务不急着取用数据。本地的冷存储方案，及任何对RTO不敏感的需求，都适合此用例。
• 在公共云中重建实例/镜像不复杂。
• 公司有专门的DR人才，并且至少每半年愿意进行灾备测试。

如下情况，“灾备即服务”是更好的选择：

• 管理层不懂技术。
• RTO要求很短。
• 应用基础架构很负责。

通常DRaaS成本远远超过单独的备份。但DRaaS供应商按需使用的能力，也以为着其成本能大大降低。当然，详细的TCO分析是决策的必要前提。

最后提提备份/灾备的工具。许多云工具方便了备份，其中最优秀的工具甚至省却了大量的二次开发工作，同时允许从节点到数据中心级的数据恢复。这些工具都具有良好的接口和管理方法，在恢复过程始终保持各恢复对象的一致性。