目前为止，大多数的业务连续性(BC)策略是以服务器及主机为核心的。实际上，整个IT系统以及基础通信设施也同样重要，其中包括语音及无线通信、E-mail、办公空间以及基础网络等物理设备等。业务连续性是一种预防性机制。它明确一个机构的关键职能以及可能对这些职能构成的威胁，并据此采取相应的技术手段，制定计划和流程，确保这些关键职能在任何环境下都能持续发挥作用。业务连续性包含三个领域:业务状态数据的备份和复制、业务处理能力的冗余和切换、外部接口冗余和切换。

       行业中似乎一直对业务连续性(BC)和灾难恢复(DR)流程之间的差别有所混淆。企业们常常使用其中一个术语来指代另一个所描述的动作。许多企业在这两个方面或其中之一上有所欠缺，从而导致了灾难性的结果。谁也不想有灾难，没有企业愿意面临这样的难题：自己的数据中心停止运行或建筑受到破坏时如何保持正常运营？这样的话题令人不悦，而相关的问题更是难以解答。同样烦人的还有如何评估当前薄弱或无效的数据保护方案的实际整体成本问题。通过引入自动化技术，企业则可以有效的解决上述的两大难题，为BCDR做好妥当规划。
　　
        灾难恢复（DR）指在主数据中心遭遇灾难导致核心系统或整个物理设施停用时，将IT资源复制到IT业务服务可继续运行的远程站点。完全成熟的DR系统不仅可以故障切换到业务可继续运行的远程站点，还可以将完整的IT服务在故障解除后回切到主站点，只要大部分的“灾难”是短期的，而不是毁灭性的。
　　
        显然，BC和DR之间有许多交叉点，在保护关键数据中心功能方面两者是相辅相成的，也都在有效部署和测试演练方面提出了挑战。当IT人员想要通过技术和程序规划来保障业务交易与企业营收时，则会面临两大障碍。
　　

        BCDR计划障碍：复杂性
　　
        执行BCDR计划可能是颠覆性的。涉及的IT元素数量太多，使得完整流程的管理几乎是不可能的。此外，用于故障切换和恢复所有这些元素的程序也必须定期进行测试演练。许多数据中心的测试演练频率不足，甚至根本没有这样的测试演练。日前，一份针对CIO所作的调查表明，测试演练的意识正在进步之中，但测试演练的频率并没有增加；54%的受访者表明这样的测试演练一年进行两次左右（请参阅调查简报）。这个频率依然相对低下，而且仅有41%的受访者在其执行的本就不多的测试演练中成功恢复了所有应用程序。
　　
       然而，真正的风险在于，这些受访者可能会认为他们已为灾难做好了准备，因为他们做了规划并且偶尔会进行相关的测试演练。在恢复流程中，时间就是一切。恢复的速度越快，省下的钱也就越多（换而言之，财务损失越少）。BCDR计划测试演练对改善恢复时间和确保流程就绪程度来说至关重要。
　　
        事实上，测试演练实际故障切换和恢复的复杂性是在降低的，这在一定程度上要归功于广泛采用的虚拟化技术。随着服务器、桌面和存储的虚拟化，跨越距离实现系统和数据的完整移动性的能力得以加强。大多数企业为了整合与灵活性而采用虚拟化技术，而这种灵活性也延伸到危机时刻。人力的移动性可以通过桌面虚拟化轻松解决，这使得一些企业可以让员工在公司设施无法访问时，通过异地维持完整的生产效率。
　　
        降低BCDR复杂度的另一项进步是通过自动化来体现的。灾难恢复自动化可以机械化完成主站点IT操作的故障切换和故障回复流程。自动化工具也涵盖了所有数据中心操作，将整个业务应用程序服务（如ERP和CRM等）作为单个保护和恢复单元进行管理。最有效的自动化解决方案甚至可以映射到操作模式，让IT员工可以定义任何指定业务的不同系统和组件之间的依赖性。这对缩短恢复时间和确保成功完成故障切换或故障回复操作来说意义重大。自动化的BCDR工具还可以提供对业务运行毫无影响的测试演练，这样企业就能更频繁的进行测试演练，为灾难做好更充分的准备。