通過上述架構描述，可以分析出ERP系統容災的要點在數據庫上。
Web服務器和應用服務器上因為沒有存放業務數據，只需要提供冗余即可，不管是本地高可用集群（HA Cluster）、遠程高可用集群、還是基于負載均衡器的服務器冗余（負載均衡集群），都是成熟的解決方案，企業可用根據自身情況選擇合適的解決方案。
在數據庫的數據容災方面，由于采用磁帶備份的冷備份方式基本不能滿足RPO要求，所以本方案重點討論聯機數據復制技術。根據數據復制的發起點不同，有多種主流技術，如基于存儲的磁盤級容災，基于存儲網絡的容災，基于主機的容災和基于數據庫的容災，可參考下圖：
一般來說，級別越低的技術，通用性越強，實施越簡單，對硬件要求越高，備份系統可用性越低，反之，級別越高的容災技術，技術實現越復雜，對硬件依賴性越小，但備份系統可用更好。
實際上，磁盤級容災、存儲網絡級容災和主機級容災都是基于數據塊復制的技術，數據量和占用帶寬比較大，實際傳輸數據量在交易數據量的8-10倍左右，并要求主機或存儲同構，而數據庫級容災是基于數據庫日志的容災技術，數據量和占用帶寬比較小，對硬件平臺沒有要求。
但是，這并不是最重要的。最重要的是數據庫系統對數據的一致性和完整性是有嚴格要求的，為了提高備份系統的可用性，必須保證備份數據庫是隨時可以打開的，必須完整復制交易數據，保證交易數據一致性。而基于存儲或基于主機的數據復制技術，好處是對應用透明，但壞處就是無法區分數據的內容，只能對數據塊和邏輯卷進行復制，難以保證容災備份數據庫在所有檢驗時間點的一致性，有可能出現單次檢驗失敗的情況，或者出現災備數據庫無法打開的情況。
還有一個對數據庫容災有影響但通常被忽略的問題是緩存問題，在存儲系統中，緩存（Cache或Buffer）幾乎無處不在，文件系統有緩存，存儲有緩存，RAID控制器上有緩存，磁盤上也有緩存。由于數據庫采用了預寫式日志（Write Ahead Logging）技術，在發出Commit指令更新數據庫表中的數據時，實際上只是把內存中的日志緩存寫到存儲上，并沒有實際更新數據，見下圖所示：
為了保證數據的一致性，對于數據庫日志（Redo Log）采用了Direct IO，跳過了操作系統中文件系統的緩存，但是依然可能寫在存儲的緩存上。而實際更新數據（Data Block）時，很有可能寫在存儲系統的緩存上就返回了，而且更新數據是按數據頁（Page）更新的，“臟數據”也會同時更新到磁盤上，數據庫能通過Redo Log來保證數據一致性的問題。
這就導致只有Redo Log的數據是最新的、準確的，這也是數據庫保證數據一致性的基礎，通過邏輯卷復制或存儲復制的數據復制技術，即使采用的是同步復制技術，也存在沒有復制緩存數據的問題，而就是復制了緩存數據，因為數據庫的本身機制就決定了磁盤上存在“臟數據”，依然只能通過數據庫來保證數據的一致性。
基于上述分析，我們認為數據庫數據容災最適合的技術就是數據庫級容災技術，基于對數據庫日志的捕獲、重做來保證數據一致性。