灾难恢复、业务连续性、数据备份等术语通常可以互换使用。然而，这些术语是不一样的，如果组织想要正确地保护其数据和任务关键型业务系统，就须了解它们之间的区别。
　　以下将详细讨论每个概念，并研究如何将基于云计算的灾难恢复即服务(DRaaS)纳入其中。
　　·业务连续性(BC)–业务连续性计划描述了组织将如何应对灾难以及如何从灾难中恢复。
　　·灾难恢复(DR)–灾难恢复是更大的业务连续性计划的要素之一。它通常涉及信息技术(IT)解决方案，以确保组织的数据和关键系统的安全，以便在灾难发生后可以对其进行恢复。
　　·备份–应用程序和数据备份可能是灾难恢复解决方案的一部分，但传统上它们并不是自动进行应用程序恢复的，这是数据备份和复制技术之间的根本区别。
　　以上每种都可以帮助组织制定灾难恢复，这是业务连续性(DRBC)策略的主要区别和注意事项。
　　业务连续性计划：第一步
　　业务连续性计划及其相关讨论始于组织的执行管理团队。他们须了解关键系统的脱机对业务的影响，这一点至关重要。组织须应对以下一些典型的问题：
　　•需要什么系统才能继续以可接受的水平交付产品或服务?哪些系统是不必要的?
　　•如果应用程序不可用，会继续产生收入吗?
　　•将如何应对自然灾害、网络安全威胁或内部员工破坏等破坏性事件?
　　•如果无法进入办公室，员工将如何继续工作?是否需要考虑采用业务连续性套件?
　　回答这些问题有助于定义哪些系统和数据是关键任务，需要多久备份一次，以及在出现故障时需要多长时间恢复一次。
　　组织的业​​务连续性计划如何?大约25%的组织制定了灾难恢复或业务连续性的正式计划。这包括定义和记录首先需要恢复的系统，并描述灾难将对收入产生的影响。
　　另外75%的组织缺乏业务连续性计划，与第三方合作进行正式的影响分析将会显著受益。
　　业务连续性计划是制定全面灾难恢复策略的第一步。不幸的是，大多数业务连续性计划经常被搁置一旁，并且其重要性只有在灾难发生之后才能得到充分认识。
　　灾难恢复计划：下一步
　　假设组织有25%的部门制定业务连续性计划，那么下一步应该是继续实施灾难恢复计划。这应该从业务级别开始，并且不仅仅属于IT部门的权限。
　　灾难恢复计划先要确定支持组织的应用程序和基本数据所需的内容。灾难恢复专家可以使用各种工具和平台来回答以下问题：
　　•组织的服务器或虚拟机正在运行什么操作系统(OS)?
　　•有多少计算资源绑定到该服务器?
　　•正在使用多少存储空间?
　　•硬件版本是否相关，如果相关，它们是什么?
　　•组织可以使用哪些技术来复制所需的工作负载?
　　在此阶段，有必要记录服务器和虚拟机之间的依赖关系。一个应用程序可以完全驻留在一个系统上。但是，在某些情况下，一个应用程序驻留在多个虚拟机或服务器上，从而很大地影响了灾难恢复过程。
　　备份还是复制还是两者兼而有之?
　　组织是否有定期的数据备份时间表?它是由组织IT部门在本地执行的，还是在托管数据中心的异地执行的?还是组织依靠云计算提供商来为其执行此操作?
　　许多组织仅根据其应用程序的恢复时间目标(RTO)和恢复点目标(RPO)错误地选择了数据复制还是传统备份。但是，数据备份不应该是组织的独立灾难恢复解决方案。
　　复制包括软件、平台和提供程序，它们具有到新位置的近实时数据复制。通过复制，数据可以在15分钟内恢复，并可以增强组织的策略。
　　当组织因数据复制而遭受灾难时，会发生什么?组织和IT部门将立即着重于从上一个恢复点检索数据。但是，许多组织和IT部门每天都要运行备份，这会增加丢失数小时数据(