周五收到开发同学通知，由于程序bug导致误更新了用户的数据，需要将21号的数据拿出来分析，然后重新插入进去。当时就咨询了苏普同学，问问他们该怎么恢复，由于我们数据采用的是xtrabackup方式来备份数据，在恢复数据的时候需要将备份数据拷贝到另外一台机器上，在把数据还原出来。但是不幸的是我们的备份有问题，苏普同学恢复了两次也没有恢复成功，难道真的要面临数据丢失了吗，开发同学不停的在旺旺上问恢复好没有，在这个时候你能说我们的备份有问题吗，不能!
这个时候突发想到了开发同学在给我用户id查看更新后数据的时候，发现该记录的创建时间和更新时间分别为：
root@dc_pages_bak 06:06:37>select gmt_created,gmt_modified
-> from tfs_0007
-> where user_id = 217101303
-> and gmt_created <= ‘2011-4-23’
-> and gmt_created >= ‘2011-4-19’;
+———————+———————+
| gmt_created | gmt_modified |
+———————+———————+
| 2011-04-21 17:29:39 | 2011-04-22 18:01:21 |
该用户的记录是在4-22号被更新的，但是创建时间是在4-21,这个时候仿佛看到了曙光，因为今天4-22,那么昨天做的插入在binlog中还有保留的一份的吧，我们的binlog保留的时间为一周，于是找到备份目录中在4-21 ，17点30左右的binlog，然后用mysqlbinlog分析日志，找到插入的语句；在分析了两份binlog后，终于找到了21号插入的这条数据：
INSERT INTO tfs_0007 (user_id, *,*,*,*,gmt_created, gmt_modified)
VALUES (217101303, *,*,*,*,now(),now());
数据找到了，换另一种方式来解决问题，虽然有一定的局限性，但是成功了如果早一点想到该办法，也不会给用户带来那么多的不爽的体验；
至于为什么我们的xtrabackup为什么恢复会出现问题，还需要和苏普他们确认一下，这个问题不小啊。
