记Linux正在log的日志备份

MySQL的慢查询日志在日积月累下 达到了40G的大小，磁盘瞬间被占满，应用也开始集体出现SQL异常。
于是手动将慢日志清空，部分应用进行重启。使得整个系统得到恢复。
为了避免这种情况，就开始百度如何使用shell脚本进行日志备份。
最终找到如下脚本

cp /pathToFile/log.log /pathTobackupFile/log.`date +%Y%m%d`.log> /dev/null 2>&1 &
cat /dev/null > /pathToFile/log.log

使用IO流重定向进行正在log的日志进行备份。
关键性脚本找到了，开始编写定时任务。总不能隔几天手动执行一次，万一时间长了忘记执行那不是就GG了么

开始编写脚本

首次编写脚本如下

cd $target_dir
cp $source_dir/$file_name $target_dir/$source_file > /dev/null 2>&1 &
cat /dev/null > $source_dir/$file_name
tar zcfv $tar_file $source_file
find $target_dir -mtime +7 | grep "tar.gz" | xargs rm -f

执行上面备份日志的核心脚本，并进行压缩，删除7天之前的备份。

执行脚本

看起来没有什么问题，于是信心满满的执行。
结果非常的amazing啊，在备份目录下的备份文件什么内容都没有。
这就让人很迷惑了，手动一条一条的执行上述脚本均没有任何问题。正在log的日志文件也正常的进行备份了，只是出现了如下的提示

[root@i]# cp /pathToFile/log.log /pathTobackupFile/log.`date +%Y%m%d`.log> /dev/null 2>&1 &
[1] 32372
[root@i]# cat /dev/null > /pathToFile/log.log
[1]+  Done  cp -i /pathToFile/log.log /pathTobackupFile/log.`date +%Y%m%d`.log> /dev/null 2>&1 &

由此我大胆的猜测，在脚本中 cp命令没有执行完成。于是将脚本改成如下

cd $target_dir
cp $source_dir/$file_name $target_dir/$source_file > /dev/null 2>&1 &
sleep 1
cat /dev/null > $source_dir/$file_name
tar zcfv $tar_file $source_file
find $target_dir -mtime +7 | grep "tar.gz" | xargs rm -f

再次执行脚本，OK了
具体原因，后续在查资料，先写到这里

---

增加一个说明

2020-06-12 10:40:38

• 此脚本不要用在crontab中,会将部分重定向的io流中的内容覆盖到crontab的配置中，导致所有的crontab异常