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