自从人们开始依靠技术来运营业务以来，备份，业务连续性(BC)和灾难恢复(DR)已经成为30年来IT团队工作的重要组成部分。传统解决方案是针对内部部署基础架构和结构化应用程序和关系数据库而设计的，但IT世界正在发生变化。在数字化转型的时代，人们需要重新思考和重塑基础备份和恢复架构的工作量，这些工作负载转移到了云端，并在云端诞生了应用程序。
改变了什么?备份与恢复
自从计算技术突飞猛进以来，应用程序和数据平台发生了巨大的转变。这其中有几种因素：
- 新的应用。第三代应用程序是地理分布式的，跨越多个系统进行扩展，始终处于开放状态，通常部署在云端模式中。
- 现有的应用程序正在转向云端。他们没有消失，但企业正在将部分或全部应用移动到云端。他们还需要备份和恢复。
- 恢复时间目标(RTO)和恢复点目标(RPO)窗口正在缩小：企业希望“永远在线”，而不是每天都进行夜间备份。
- 规模较小的企业将全面采用公共云。中小型企业不希望因为IT业务影响主要业务。他们一直在推动云应用和平台的快速发展。
- 企业将构建混合云。企业将通过内部部署和公共云环境部署应用程序和数据。而规模，合规性和其他因素，意味着他们需要在系统内部保留一些系统。
- 每个组织都会使用多个云。没有人会愿意将他们的业务绑定在一个云端或一个提供商。即使现在，企业正在分散云计算和本地的工作负载。企业的开发和测试的业务可能只使用一个云端，而同一应用程序可能部署在私有云或不同的公共云中。
云计算对备份，恢复和连续性的影响
云计算为组织提供了更多的灵活性，运营节省和按需付费模式。公共云提供商也可以构建更具弹性的基础架构。亚马逊公司确保EC2的99.95%的可用性和S3的99.99%的可用性; S3设计用于11个9的数据安全和可靠性，具有多个可用区域。因为云计算是如此可靠，并且成本低廉，它很快成为本地数据的备份目标。但是，当企业在云端中运行应用程序时，这不应该让企业相信备份和恢复是“内置的”。亚马逊公司甚至建议为所有AWS本机应用程序和云数据库提供备份服务。
虽然服务可用性和数据恢复能力解决了基础架构业务连续性和灾难恢复，但它不提供备份和恢复的时间点恢复或应用程序级智能。与云计算平台一样，它们不会防止逻辑错误。而研究显示，10个错误中有8个是逻辑错误，数据损坏，用户错误。
现有备份产品和云计算
如上所述，传统的备份和恢复产品不能满足云应用的需求，即使是移动到云端的现有应用，而不仅仅是因为它们建立在不同的时代。此外，云计算和分布式架构还面临其他挑战：
- 云计算打破了基于媒体服务器的传统解决方案架构。云计算的应用程序和数据没有驻留在特定的阵列或磁盘上，因此用户无法轻松备份所看不到的内容。备份也不能捕获云中的配置数据，例如AWS Cloud Formation模板。
- 云计算不会以相同的语言沟通。传统解决方案采用磁带，磁盘或虚拟磁盘。在云中的备份和恢复意味着采用正确的集成协议，例如S3 API或谷歌云存储。
- 备份设备无法移动到云端。现有的备份设备(如EMC Data Domain或NetBackup)在内部工作得非常好，无法被拾取并移动到云端。
- 传统备份代理不会扩展。如果用户可以获得在云中运行的备份代理，则可能会在数十个或可能数百个节点之间进行扩展。
- 虚拟机不是正确的抽象层次： Datos IO CODR架构的核心原则是可扩展的以应用为中心的数据管理和数据保护视图，需将其与传统方法区分开来。这就是为什么CODR架构反思应用数据，并使用全局语义重复数据删除来实现存储效率的原因，而不是依靠将数据视为不透明对象(如VM或LUN)的传统重复数据删除技术。采用这种方法的好处是可以通过网络链接覆盖云层的精细粒度和高空间效率的数据保护。
- 云计算网关或迁移服务：仅限于单向。
数据保护必须重新发布
云应用的备份和恢复问题很新颖，因为云计算备份和恢复架构应该具有三个关键因素：
- 弹性计算。架构应该在弹性计算实例上有效地扩展。服务器或设备不应有任何资本支出费用。
- 没有媒介服务器。备份大型的横向扩展的数据库需要直接的并行流架构，以便在数据库和辅助存储之间进行数据移动。传统的备份架构依赖于迅速成为阻塞点的媒介服务器。直接并行流并允许数据以原生格式保持可用。
- 语义重复数据删除横向扩展应用程序数据库通常具有3倍的复制因子。如果用户备份单个节点或甚至管理整个数据库的快照，则三分之二的备份数据是多余的。随着时间的推移，备份将不会在分布式架构中运行语义，其重复数据删除效率达到75%至80%。
