行业中似乎一直对业务连续性 (BC) 和灾难恢复 (DR) 流程之间的差别有所混淆。企业们常常使用其中一个术语来指代另一个所描述的动作。许多企业在这两个方面或其中之一上有所欠缺，从而导致了灾难性的结果。谁也不想有灾难，没有企业愿意面临这样的难题：自己的数据中心停止运行或建筑受到破坏时如何保持正常运营？这样的话题令人不悦，而相关的问题更是难以解答。同样烦人的还有如何评估当前薄弱或无效的数据保护方案的实际整体成本问题。通过引入自动化技术，企业则可以有效的解决上述的两大难题，为BCDR做好妥当规划。
让我们从定义BC、DR这两个常常被误解的术语开始说起。
业务连续性(BC)指的是组织因为系统故障、人为错误或其他不可预见原因受到或大或小的破坏时维持运营的能力。全面的BC计划包含一整套资源和物流，它们跨越基础架构、执行流程、供应链物流和员工配备等。在IT中，BC是在发生主系统故障时确保将关键业务服务切换到数据中心各种设施的备用或辅助系统。
灾难恢复(DR)指在主数据中心遭遇灾难导致核心系统或整个物理设施停用时，将IT资源复制到IT业务服务可继续运行的远程站点。完全成熟的DR系统不仅可以故障切换到业务可继续运行的远程站点，还可以将完整的IT服务在故障解除后回切到主站点，只要大部分的“灾难”是短期的，而不是毁灭性的。
显然，BC和DR之间有许多交叉点，在保护关键数据中心功能方面两者是相辅相成的，也都在有效部署和测试演练方面提出了挑战。当IT人员想要通过技术和程序规划来保障业务交易与企业营收时，则会面临两大障碍。
BCDR计划障碍：复杂性
执行BCDR计划可能是颠覆性的。涉及的 IT元素数量太多，使得完整流程的管理几乎是不可能的。此外，用于故障切换和恢复所有这些元素的程序也必须定期进行测试演练。许多数据中心的测试演练频率不足，甚至根本没有这样的测试演练。日前，一份针对CIO所作的调查表明，测试演练的意识正在进步之中，但测试演练的频率并没有增加;54%的受访者表明这样的测试演练一年进行两次左右(请参阅调查简报)。这个频率依然相对低下，而且仅有41%的受访者在其执行的本就不多的测试演练中成功恢复了所有应用程序。
然而，真正的风险在于，这些受访者可能会认为他们已为灾难做好了准备，因为他们做了规划并且偶尔会进行相关的测试演练。在恢复流程中，时间就是一切。恢复的速度越快，省下的钱也就越多(换而言之，财务损失越少)。BCDR计划测试演练对改善恢复时间和确保流程就绪程度来说至关重要。
事实上，测试演练实际故障切换和恢复的复杂性是在降低的，这在一定程度上要归功于广泛采用的虚拟化技术。随着服务器、桌面和存储的虚拟化，跨越距离实现系统和数据的完整移动性的能力得以加强。大多数企业为了整合与灵活性而采用虚拟化技术，而这种灵活性也延伸到危机时刻。人力的移动性可以通过桌面虚拟化轻松解决，这使得一些企业可以让员工在公司设施无法访问时，通过异地维持完整的生产效率。
降低BCDR复杂度的另一项进步是通过自动化来体现的。灾难恢复自动化可以机械化完成主站点IT操作的故障切换和故障回复流程。自动化工具也涵盖了所有数据中心操作，将整个业务应用程序服务(如 ERP和CRM等)作为单个保护和恢复单元进行管理。最有效的自动化解决方案甚至可以映射到操作模式，让IT员工可以定义任何指定业务的不同系统和组件之间的依赖性。这对缩短恢复时间和确保成功完成故障切换或故障回复操作来说意义重大。自动化的BCDR工具还可以提供对业务运行毫无影响的测试演练，这样企业就能更频繁的进行测试演练，为灾难做好更充分的准备。
BCDR计划障碍：成本
企业考虑BCDR计划的成本之前，他们必须先考虑意外停机的成本。ESG近期所发布的调查结果表明，大部分企业发现即使是些许的停机时间也能带来惨重的损失。在ESG调查中，74%的受访者表明他们在开始遭遇营收损失前最多可容忍三小时停机;53%表明即使一小时停机他们也无法承受。没错，BCDR成本很重要，但人们必须考虑到业务流程对IT的依赖程度已在增强，而出现灾难时 BCDR计划不足可能会带来巨大损失。