不可预测的毁灭性灾难中，服务器系统应该如何快速恢复？

这种灾难事件，数据中心至少要做成同城容灾才能在较短时间内恢复业务。这个容灾的设计，最终还是和预算有关。

目前采用较多的是基于存储的块级复制和基于应用的复制（如oracle stream），可根据自身要求去选择。

如果基于存储的，需要解决了异构存储的复制接口问题，最好先做整合。

面对应急管理，我觉得有以下几个事情应该做好：

1 应用服务器层面，所有的应用都应该模块化、清晰化。在灾难恢复的时候，尽量能够简单快速完成服务器的重新部署。目前虚拟化平台里面的模板技术、克隆技术都能提供支持。

2 数据库服务器，做好容灾备份工作。远端的容灾，本地的备份。包括数据以及日志等。正确应用好闪回、ADG等类似技术。

3 管理层面，首先所有服务器系统的架构图、规划表、配置表、网络拓扑等都应该正确清晰，使得运维人员从整体和局部都有一个清晰的参照。然后，做好系统运维的自动化管理，尤其是部署自动化、切换自动化。能用脚本完成的批量部署工作，一定不要人工去一条一条敲命令。真正的危机时刻，分秒必争。

采用同城数据级备份可以解决类似的问题，想解决地震这样的问题就需要异地灾备了。

这是数据容灾的层面，考虑两个方面，一个是数据能够恢复，第二是多少时间恢复，通常说就是RTO和RPO。

对中小企业来说，由于预算有限，一般RTO和RPO要求都不是很高，因此可以选用一些相对廉价的做法。最基本的是把数据做离线备份，可以一天或者一周一次。然后数据存放到安全区域，一般原理生产区域。

而是采用一些基本的在线复制方案，此时需要两套以上的存储设备，实施简单的异步复制，目前这种方案成本较低，需要的存储设备仅需要中低端的，有些甚至自身就可以通过IP网络复制，例如V5000。因此成本几乎就是一个额外的数据存储。

当然也可以通过数据库的复制，例如HADR等，方式种类比较多。

而当RTO和RPO的要求变高时，实现方式就变得更为复杂，需要分析的点也就比较多了。