通过上述架构描述，可以分析出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的数据是最新的、准确的，这也是数据库保证数据一致性的基础，通过逻辑卷复制或存储复制的数据复制技术，即使采用的是同步复制技术，也存在没有复制缓存数据的问题，而就是复制了缓存数据，因为数据库的本身机制就决定了磁盘上存在“脏数据”，依然只能通过数据库来保证数据的一致性。
基于上述分析，我们认为数据库数据容灾最适合的技术就是数据库级容灾技术，基于对数据库日志的捕获、重做来保证数据一致性。