【Linux-运维-故障恢复】误删crontab的恢复

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

重要的事情说三遍,但总是会有各种意外。这里简单讲一下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执行的每个人物的时间、命令等详细信息都记录在这里,所以可以用这里的信息进行恢复。

猜你喜欢

转载自blog.csdn.net/zd199218/article/details/78022613