个人认为Percona 对MySQL最大的贡献就是它提供了MySQL 的热备份工具xtrabackup.

      对于V2版本中有一个问题是：从备份文件中恢复数据时，对于备份前新创建的表，是无法完全利用工具恢复.frm表格式文件。（不过这并不影响使用）。（貌似网上有人已经做了修改）

      由于我们默认的存储引擎是InnoDB,所以直接使用Innobackup 工具，每天凌晨两点备份。今天发现备份目录中都没有.frm文件。

      第一步：查看备份日志

      对于备份是否成功，我们通过邮件通知。db server 上有详细的日志：

      innobackupex: Backing up file '/usr/local/mysql/data//wpf/abc_after.TRN'
      innobackupex: Backing up file '/usr/local/mysql/data//wpf/abc.frm'
      innobackupex: Backing up file '/usr/local/mysql/data//wpf/db.opt'

      日志中有详细拷贝.frm文件的记录。而且没有任何Warning和Error。

      第二步：日志没有可用信息，查看监控记录

      翻看zabbix中的历史记录没有异常，查看pt-stalk中的记录，和以前相比，没有异常。

      第三步：没有可用记录，怀疑备份文件是否有问题

      如果备份文件有问题的话，可以直接报bug啦。对备份文件拷贝至其他机器进行恢复，并添加好.frm文件。对某张特殊表 进行时间戳，重复线上的查询。。结果没有问题。

      第四步：查看其他crontab 程序

      由于在使用xtrabackup 之前已经经过测试，也怀疑过脚本的问题。但已经报告备份成功而且能成功恢复。只有一个del程序。是删除15天之前的备份文件。程序内容大致为：

      find  path  -mtime +15 | xargs rm -rf 

      但为什么只删除表结构文件呢，不删除数据文件？难道.ibd 对于find来说是特殊文件不删除（这个是不可能的）。备份文件的时间不一致？ 同时备份的怎么会不一致呢？结果发现时间真的不一样。 数据文件是 ibbackup 程序拷贝，时间戳是备份的时间。而 .frm文件是innobackupex程序 未修改文件“最后修改时间”而copy至备份文件夹。

       幸好发现的早！

       del 删除程序改为：

      find  path -name "2*" -mtime +15 | xargs rm -rf