今天上班的路上收到一条短信，显示线上所有实例备份都失败了。备份失败是大事，于是到公司的第一件事儿就是排查备份失败的原因。
这两天迁移了数据库管理平台，当然涉及到数据库备份功能，备份失败肯定和平台迁移有一定关系，我们先聊聊线上备份方案：
目前线上的备份方案是：
1、有一个前端页面可以配置备份任务
2、备份任务配置好了，会自动刷新到系统的crontab定时通过ansible远程执行。
排查过程：
1、查看备份报告，显示所有的备份文件大小都是0，初步估计是备份失败了而不是元数据没有更新的问题。
2、去机器上面查看备份日志：
从日志上面查看是备份已经成功，但是去过去备份文件大小的时候抛文件不存在的异常。
不知道大家有没遇到这种情况，不过问看到这种现象首先想到的是有多个任务在跑，上一个备份还没完成就被另外一个备份任务将备份文件删除了。方面就初步出来了，就是要找到另外一个任务是怎么来的。
3、我先挑选了一个比较小的非核心集群，尝试了手动执行了crontab里面的备份命令，备份成功(这只是确认一下，因为平台迁移后测试过备份任务是没有问题的)
4、由于每一个集群的备份全部失败了，也就是说，两个备份任务能连接到线上所有的mysql机器，有这权限的只有3台服务器，于是去查了这三台服务器是否有重复的定时任务。结果只有一台机器上面才定时任务。
5、上面的尝试也没找到原因，就只能继续尝试，将备份任务的时间修改为当前时间+2分钟，让它定时执行看是否正常。
结果和晚上备份情况一样还是失败。
6、到这个时候我已经有点懵了，感觉这个太不科学了，期间还让开发平台的同事帮忙查看了代码里面生成crontab部分是否有问题，比如在其他机器上同时有生成，结果都是大失所望。
7、继续其他尝试，对比手动执行和定时任务产生的进程：
在目标机器使用ps -ef |grep backup.sh
a) 手动执行的时候：为2个进程
b) crontab定时执行的时候：为4个进程，
这个还是只能肯定定时任务有问题，并不能说明什么原因造成这个现象的。
只能继续蒙圈…………
8、在不知道怎么排查问题的时候，我做了一个新的尝试。
在配置好定时任务的时候，在中控机上使用service crond stop 将定时服务给停了，如果备份成功了那说明需要在其他机器找问题
9、这次尝试确实后备份确实成功了，但是在其他机器也找不到原因，这时候 已经很抓狂了，完全不知道什么情况了。
在准备放弃的时候，我在中控机上面使用 ps -ef |grep crond 查看crond 服务的情况。尼玛，内心10000个草泥马飞奔，居然还有有一个crond服务！！
使用service crond start 启动crond，
居然有两个服务。
看到这里终于可以松口气，看来问题就在这里了，
于是将多余的crond 服务 kill掉后备份就正常。
ps：crond 这个服务个人确实从来没发现可以启动两个的，后面我做了各种尝试，最终还是只有一个服务，至今也不知道这个第二个crond服务怎么起来的。
遇到自己感觉灵异的问题，我们要相信机器不会撒谎，我们要保持清晰的思路，坚持下去，终究能找到问题所在的。
话是这么说，但是事实上做起来还是很难的，我差点就放弃，准备将这套备份系统直接下了，用自己新写的一套来替代，本地已经测试ok，只要上线跑跑就可以了。不过还是挺庆幸当时没有放弃，如果放弃了，那么我也就错过了crond服务还有可能出现两个的奇观了！
嘿嘿，提个问题，如果你们遇到这种情况，会用什么思路来排查呢？