一个SBOP的灾难恢复场景分享

上周接到一个客户的求救电话，客户一台BO的服务器，硬盘损坏，数据全丢，需要马上进行系统恢复。接到电话，马不停蹄赶到现场。

到达现场，对实际情况进行了初步了解：

1.客户这套SAP的BO产品在09年实施，版本是3.1，操作系统redhat 4.6，Oracle 10.2.0.4。

2.分布式部署架构，DB和应用分别部署在不同的硬件服务器上，索性DB的服务器尚在，但是大家都知道，BO的DB作用仅限于存放用户，权限及其对应关系等一些CMSDB的内容，report等报表数据，而是存放在OS上的。所以，DB尚在，如果没有OS或者CMC导出的备份，也是没有办法进行完全恢复的。好消息是，备份存放在应用本地，随着磁盘损坏，一同损坏了。

3.没有任何DR机制，这种灾难性，没有任何容灾能力的环境，在灾难出现的时候，客户必须的接受数据丢失的后果。

4.09年安装所使用那份介质也彻底丢失，而SMP发布最早的版本，也比当初实施的版本要新。

凌晨到达客户现场，捋了一下，按照如下步骤实施：

1.由于新实施的BO版本变化了，那么第一件要做的事，就是OS,DB和新BO的兼容性。我们要注意，SAP产品上下兼容时间区间一般为3-5年，超过这个时间段就要非常注意了。

2.查到能够在REDhat 4.6上实施SBOP XI3.1最新的版本为SP4，超过SP4就不再兼容。我们选择SAP发布的SP A（至今没弄懂，这个SPA究竟是什么版本）。

3.OS重新安装，iso刻光盘，OS重置，安装必须的rpm包，然后安装Oacle（注意了，linux上安装oracle之前，gcc等一系列必须的包，一定要提前装好）。

4.部署好我们的BO系统，然后cmsdbsetup修改数据源，将我们的DB连接到原来未损坏的DB上。（这种源的修改是不限数据库类型的，只要兼容即可）

5.所幸的是，我们的客户手上保留了一个年初的cmc导出备份，我们登录到CMC上，导入这个备份，那么剩余的报表，只能靠我们手工录入了。

整理一下，我们在遇到灾难事件的时候，首先要做的，就是了解清楚现场情况，然后一定要制定一套完善的解决方案，需要考虑到每一个环节，尤其是风险，恢复失败的回退机制，最坏的打算和结果。不要慌，任何技术问题，都是可以通过人的手解决的，最重要的是心态。