测试和发布前一定要备份！测试和发布前一定要备份！测试和发布前一定要备份！

重要的事情说三遍，但总是会有各种意外。这里简单讲一下crontab误删后的恢复。

起因

当年做的傻逼操作覆盖的文件，含着泪也要复原

在测试环境做测试，没有对测试环境的crontab进行备份。脚本误将crontab复写，原本的定时任务被清零。
虽然是测试环境，但是还是有一些特殊的心跳上报、性能监控、信息同步等任务。
所以需要将没有备份的crontab复原

复原方法

这里只讲述不存在备份，用日志的方法恢复crontab的方法。

系统：Linux（其他系统做法类似）

• 确定要恢复的日志存在

ll /var/log/cron*
【备注】这里的crontab日志是所有用户的日志

• 通过日志过滤需要的例行命令信息

我的Linux机器中crontab的日志信息主要如下：
Oct 9 03:28:01 Stor-Test CROND[7987]: (root) CMD (/home/scripts/check_alive.sh)
我们现在的关键任务是将CMD后面的命令提出出来，并确定诶条命令的执行周期

获取日志信息的命令

cat /var/log/cron | grep -i "whoami" > grep "CMD" | awk -F '(' '{print $3}' | awk -F ')' '{print $1}' | sort -u > cmd_tmp

解释：
grep -i "whoami" ：是为了过滤其他用户的信息
grep "CMD" ：是需要过滤非命令行
awk -F '(' '{print $3}'：是以'('为分隔符，提取第三个元素。这里结果为“/home/scripts/check_alive.sh)”
awk -F ')' '{print $1}'：是以')'为分隔符，提取第一个元素。这里结果为“/home/scripts/check_alive.sh”
这时，我们已经提取到自己所需要的命令了，但由于crontab定时触发，会有大量重复。后面需要进行去重
sort > cmd_tmp：去重后输出至cmd_tmp文件
后续根据提取出来的命令再去 /var/log/cron文件中确认一下时间间隔，按照指定的方式恢复至/var/spool/cron/
至此crontab恢复完毕

事后反思和总结

反思

以后测试和发布内容之前一定要备份！！！为了防止类似事件再次发生，写一个自动化脚本是很有必要的。这里简单实现一个每天对crontab进行备份的脚本（备份最近7天的数据，每天定期删除7天前的数据）

#!/bin/bash
# 每天对crontab 进行备份 ，同时删除7天前的数据
DATE=$(date +%Y%m%d)
crontab -l > /home/work/bak/crontab_$DATE.bak
find /home/work/bak/ -mtime +7 -name '*.bak' -exec rm -rf {} ;

复原原理

没有备份文件，crontab的复原方法

• 我们要恢复crontab，恢复的文件是哪个？
  Linux下会根据用户的登录名，在/var/spool/cron下生成对应的文件。平时我们执行的crontab -e操作的文件时，编辑的文件就是/var/spool/cron/user_name
  例如：root用户操作的是/var/spool/cron/root，其他用户同理
• crontab的日志保存在哪里？
  保存在/var/log/下
• 为什么/var/log/cron文件可以恢复crontab？
  这里的/var/log/cron文件其实是crontab的日志，crontab执行的每个人物的时间、命令等详细信息都记录在这里，所以可以用这里的信息进行恢复。