王大锤：看到金仓的数据恢复方案，我彻底服了

有一种惨，叫做人还在，数据没了

对，说的就是我......

大家好，我叫王大锤，一个平平无奇的IT打工人，就职于一家创业公司。

说起来是创业公司，其实主要业务是为一家北美商务公司提供电子商务平台开发和运维的外包服务。

作为一名初窥门径的数据库DBA，我深知数据备份的重要性。毕竟，小到病毒，电源故障乃至意外操作失误，大到自然灾害，都会影响系统的正常运行，甚至造成系统完全瘫痪。因此，机智如我，对正在开发和维护的电子商务平台数据库每周一备，力图做到有备无患。

可万万没想到，数据丢失的鬼故事依旧上演了，而我正是故事的主角......

电子商务平台使用了IBM的Informix数据库。这款数据库在美国还算流行，它运行稳定，性能也很不错。公司的CTO对这款数据库很是喜欢，可能这和他之前的美国留学经历有关吧。但这款数据库在国内使用的人数不是很高，网上实用的资料更是少之又少。

因此，相关的数据库运维知识只能靠自学。好在我勤学苦练，之前公司也出现过由于服务器磁盘损坏而导致的数据库故障，但均被我通过备份数据进行恢复，其间未丢失任何数据。工作之余，我也常常在笔记本上使用Informix数据库模拟数据演练，运用基于时间点的恢复将数据库恢复到数据被破坏前的时刻，熟练数据还原操作，以备不时之需。

然而，就在系统准备上线试运行的前一天，有研发人员反馈，数据库的一个表不见了，希望我尽快通过备份找回表数据。

作为创意小王子，我立即就有了一个绝佳的idea，这不就是我平时玩的基于指定时间点的不完全恢复嘛，解决这个问题so easy。

我当即尝试使用onbar工具进行基于指定时间点的数据恢复，可是恢复的结果不尽如人意，不是依旧找不到丢失的表，就是所找到的表中的数据不完整。

与平时演练完全不同（我在删除表时记录了操作时间），此时的我完全不清楚丢失的表究竟是什么时候被删除的！

通过几次数据恢复操作，可以确定在昨天下午15点时表还存在，但在凌晨12点时，这个表已经丢失了。通过不停地恢复尝试（每次约半小时），可以缩小表被删除的时间范围。但问题关键在于，此时已经没有更多的时间让我慢慢尝试了。测试团队希望能在5个小时内解决这个问题，否则后续的一些测试工作将无法完成。

没有困难的工作，只有勇敢的打工人

在我发觉仅凭个人能力无法在短短5小时之内找回丢失的数据表后，我决定寻求外援。然而，询遍同学及大学老师，都没有得到可行的解决办法，这个数据库在国内的用户很少，我的大学老师甚至都没用过。上网查询解决方法，有网友说可以通过审计日志查看表的删除时间，可Informix的审计功能有140多项，当时看的我头大，根本来不及配置审计。