crontab的mysqldump備份任務未能完全正確執行的故障處理

  crontab是每個運維一線人員必須掌握的技術，熟練運用crontab可以自動幫助我們執行重覆性的工作，提高運維的工作效率。它就像一個鬧鐘，在特定的時間，準時響應並執行相應的任務。如果你的工作經常與Linux打交道，那麼你可以繼續往下看，瞭解crontab的一般性故障排查。

  本次的故障發生在生產環境的一臺雲伺服器上，每日凌晨2點15執行資料庫的mysqldump備份任務，保留最近的三天備份，刪除之前多餘的備份文件。當第四天執行完計劃任務的時候發現本地備份目錄中居然還存留三天前的壓縮備份文件，調試腳本檢查並無問題後，手動執行crontab的腳本，發現crontab能完全正確執行，而第二天再次通過crontab的方式執行發現仍然多保留了一天的壓縮備份文件。（這裡可以通過touch命令新建空文件或者修改文件時間來模擬）

  通過與其他同行溝通並谷歌或百度搜索，發現了兩種解決這種問題的方案，如下是我的本次故障的排查流程。因故障發生於阿裡雲的生產伺服器，故障排查的現象過程不便於重現，敬請諒解，對於生產伺服器我們還是應當謹慎的操作，不便於做測試任務。

【故障情景】

  一臺阿裡雲的雲伺服器，crontab手動和自動均能執行備份任務，自動執行後備份的文件相對只保留三天卻多保留一天，而手動執行卻能保存三天的備份，而本地的物理機就能成功執行，只有雲伺服器多保留一天的備份。

#刪除未壓縮的備份目錄
function rm_oldfile()
{
  cd $backupdir
  find ./ -type f -mtime +2 -exec rm {} \;
}

#需要清理備份的時候把下麵註釋去掉，天數可以自行修改
rm_oldfile;

【故障分析】

  crontab出現故障，會有兩個原因，一個是命令路徑的問題，另一個就是環境變數的問題。

#!/bin/bash
. /etc/profile
. ~/.bash_profile

  第二種解決辦法：加if判斷，檢查備份文件的數量，如果大於正常值，則再執行find ./ -type f -mtime +2 -exec rm {} \;命令。

function rm_agofile()
{
cd $backupdir
if (($(ls -lh /opt/dump_ibg_mall/|grep ".*.tar.gz"|wc -l) > 3))
then
        find ./ -type f -mtime +2 -exec rm -rf {} \;
else
        echo "there is no more than 3" >>/tmp/dump_ibg_mall_result.log
fi
}
#rm_agofile;

【故障總結】