現在災備領域有一個明顯的趨勢就是云提供商開始采用負載均衡數據中心而非冷熱通道型數據中心。一些企業正在部署私有云來平衡承擔災備需求的各數據中心間的負載。假如某個數據中心遭遇災難，其他數據中心便可接續運營。

但是負載均衡數據中心也存在著諸多挑戰。例如，要跟蹤某個應用場景基礎設施的各種配置就非常棘手。每個應用都會創建服務器的名稱，選擇開放的IP地址，解決DNS映射，定義物理和虛擬服務器，創建防火墻規則，定義SAN和NAS配置，實施負載均衡規則，定義數據庫集群。

所有這些要素都存在于每一環境的每一應用中，例如開發、測試和生產環境。這些應用配置中有很多是由多個Web應用來維護的。而這些維護型應用均未集成，因此元數據應用配置也自然沒有集中化。更糟糕的是，很多管理上的變更都是在產品實施期間出于各種急迫的理由做出的，例如SAN子系統的各種變更，就未曾被變更管理系統所捕獲。因此說，元數據庫中的配置數據往往也是過時的。

如果能有一個工具將某個數據中心的配置克隆到與其進行負載均衡的其他數據中心那就好了。這一配置需要唯一的服務器名稱，和新的IP地址。如果其他數據中心崩潰，那么在其他數據中心所建立的對稱應用模式也能及時提供必需的基礎設施服務。但考慮到需要配置的所有產品的有效參數排列，所以要創建這樣一種工具或者導航程序是相當困難的。

所以，基礎設施配置元數據的集中管理至關重要。如果不對參數進行集中管理，不對部署應用的參數集進行版本控制，那么它所支持的基礎設施就會隨著時間的推移而發生微小的變化。這些微小的變化都有可能會在主負載均衡數據中心和次負載均衡數據中心內引起各種問題。如果配置數據未進行版本控制，那么要想讓數據中心在某個變化直接導致生產失誤時再返回某個穩定狀態就會非常困難。

另外，認證體系架構的各種關鍵要素也是十分必要的。企業應制定策略，說明只有經過測試的生產配置，例如在內核軟件或操作系統上的虛擬機版本才可在數據中心內進行部署。只有特定版本的防火墻硬件才能在各種數據中心內部署。另一個危險是缺少各種基礎設施組件的選項，例如單一來源的軟件或硬件。假如硬件存在某個常見漏洞，或者軟件存在bug，都有可能在多個數據中心引發重大失誤。

總而言之，企業可通過在負載均衡體系架構中部署各種應用來解決災難恢復問題。但是這種方法無法防范人工失誤，尤其是配置失誤。

企業可能會轉向一些經過認證的組件，例如特定的虛擬機，或者負載均衡，以避免某些因未經測試的配置或缺少配置元數據的版本控制而出現的災難。配置元數據需要以集中方式存儲，并進行版本控制，只有這樣才能在錯誤發生時讓應用回歸到某個可信任的配置狀態。