在灾备领域，一个越来越明显的趋势就是云提供商开始采用负载均衡数据中心而非冷热通道型数据中心。一些企业正在部署私有云来平衡承担灾备需求的各数据中心间的负载。假如某个数据中心遭遇灾难，其他数据中心便可接续运营。
但是负载均衡数据中心也存在着诸多挑战。例如，要跟踪某个应用场景基础设施的各种配置就非常棘手。每个应用都会创建服务器的名称，选择开放的IP地址，解决DNS映射，定义物理和虚拟服务器，创建防火墙规则，定义SAN和NAS配置，实施负载均衡规则，定义数据库集群。
所有这些要素都存在于每一环境的每一应用中，例如开发、测试和生产环境。这些应用配置中有很多是由多个Web应用来维护的。而这些维护型应用均未集成，因此元数据应用配置也自然没有集中化。更糟糕的是，很多管理上的变更都是在产品实施期间出于各种急迫的理由做出的，例如SAN子系统的各种变更，就未曾被变更管理系统所捕获。因此说，元数据库中的配置数据往往也是过时的。
如果能有一个工具将某个数据中心的配置克隆到与其进行负载均衡的其他数据中心那就好了。这一配置需要唯一的服务器名称，和新的IP地址。如果其他数据中心崩溃，那么在其他数据中心所建立的对称应用模式也能及时提供必需的基础设施服务。但考虑到需要配置的所有产品的有效参数排列，所以要创建这样一种工具或者导航程序是相当困难的。
所以，基础设施配置元数据的集中管理至关重要。如果不对参数进行集中管理，不对部署应用的参数集进行版本控制，那么它所支持的基础设施就会随着时间的推移而发生微小的变化。这些微小的变化都有可能会在主负载均衡数据中心和次负载均衡数据中心内引起各种问题。如果配置数据未进行版本控制，那么要想让数据中心在某个变化直接导致生产失误时再返回某个稳定状态就会非常困难。
另外，认证体系架构的各种关键要素也是十分必要的。企业应制定策略，说明只有经过测试的生产配置，例如在内核软件或操作系统上的虚拟机版本才可在数据中心内进行部署。只有特定版本的防火墙硬件才能在各种数据中心内部署。另一个危险是缺少各种基础设施组件的选项，例如单一来源的软件或硬件。假如硬件存在某个常见漏洞，或者软件存在bug，都有可能在多个数据中心引发重大失误。
总而言之，企业可通过在负载均衡体系架构中部署各种应用来解决灾难恢复问题。但是这种方法无法防范人工失误，尤其是配置失误。企业可能会转向一些经过认证的组件，例如特定的虚拟机，或者负载均衡，以避免某些因未经测试的配置或缺少配置元数据的版本控制而出现的灾难。配置元数据需要以集中方式存储，并进行版本控制，只有这样才能在错误发生时让应用回归到某个可信任的配置状态。
