有人可能认为根本不需要写这么一章。你可能觉得自己已经知道为什么要备份数据了,所以不需要别人告诉自己,数据备份是一件很重要的事。然而有一些促使我们备份数据的原因,你以前未必想过。所以我们不妨从这样一个问题开始讨论,这个问题就是:“为什么要把这么多钱投到备份与灾难恢复上?”
没人关心你能不能备份。我们只关心你能不能从备份中恢复数据。
本章会讲解需要做备份与灾难恢复(Disaster Recovery, DR;灾备)的各种情况,笔者按照发生概率从高到低的顺序罗列它们。首先我们看看,在什么情况下,你最有可能会急着去查备份手册。这种情况,指的就是有人做错了事情的时候。这不太可能是由自然灾害造成的,它更有可能是由于人为错误而发生的。
“你是说这个东西我们根本就没备份下来?”这句话我至今都忘不了。那时自己刚负责备份工作才两个月,我一听到这句,就知道完蛋了。6个星期之前,我们把一款Oracle应用程序从一台服务器迁移到另一台,然而在迁移过程中,笔者疏忽了一个重要的因素。当年我还不太懂数据库的备份问题,后来才知道,备份Oracle数据库之前必须先把数据库关掉。这项操作是由运行在旧服务器上的一个cron job(定时任务/计划任务)负责完成的,但我当时根本就没意识到那台服务器里面有这样一个cron job。等到新服务器的磁盘出现故障时,我才发现这回事,也就是说,迁移时其实并没有把旧服务器的数据库正确地备份下来。(第7章会详细讲解Oracle的备份问题。)
他们又说:“那就把最近一次的完整备份给我们好了。”于是我开始查日志,此时我发现这里面有错误。然而我说:“没问题。我把稍微旧一点的备份拿出来。”其实早前的日志也不太好,于是我赶紧接着往前查,一个日志一个日志地看,最后总算找到一个似乎还行的备份。这个备份距离现在的时间应该刚刚超过6个星期。但我把备份拿过来之后,才想起我们每6个星期就会循环一轮(把6星期前的对应备份覆盖掉),所以这个备份其实是两天前做的,它把那个看起来还行的备份覆盖掉了。
整个事情就是这样!那一刻我知道自己得另找工作了。这是一个存放销售信息的数据库,在这样一个几十亿级别的企业里面,这意味着将近两个月的采购订单都不见了。
我把这件事告诉老板时,对方讲了故事开头的那句话:“你是说这个东西我们根本就没备份下来?”我至今还记得“这个东西”的名字,那个地方的其他系统叫什么,我现在都已经记不清了,但只有这个名字我记得相当清楚。我当时特别羞愧,恨不得钻到那种装4毫米磁带的盒子里面。所幸系统管理员最后把问题解决了,那时我认为这简直是个奇迹。管理员把坏掉的磁盘修好了,而且直接从磁盘里面把数据恢复了出来。所以,最后其实只丢了几天的数据。我们部门给整个公司写了一份备忘录,意思是说,过去两天录入的采购订单现在必须重新录入。笔者应该将这份备忘录装裱起来,提醒自己注意,如果不认真对待工作,会有什么后果。其实也不用真的装裱啦,因为这件事情已经印在我的脑中了。
有一位评阅本书的人看到我这么写,就说:“你可真敢写啊!这是一本谈备份的书,但你一上来就讲了一个自己怎么把备份搞砸的事情。你可真行!”我为什么要写这个故事呢?因为这些年来,虽然还遇到过很多问题,但这一次的印象实在是太深了。
而且,这可能是其中唯一的一个真正触动到我的事例。假如不是那位叫作Joe Fitzpatrick的管理员神奇地修好了磁盘,我的数据保护工作可能还没起步,就已经结束了。总之,我在这里讲这个故事,有以下几个原因:
·这是改变我职业方向的一件事。
·我从这件事里面得到了许多教训,这会在本书后面讨论到。
·假如当初我能读到这样一本书,那就可以避免这个问题了。
·这确实是一件相当可怕的事情。