所以我正在做数据库的自动备份.备份脚本在我手动运行时以及Cron运行计划的每小时和每日备份时都能正常运行.但是,备份在每周和每月备份上失败.
我(显然)不确定,但我想我的问题是cron配置.也许是冲突因为脚本在午夜多次运行？我不确定这是否可能,但如果是这样,我会感谢有关微调我的crontab的说明.
我的crontab：
# * * * * * user-name command to be executed 00 * * * * /data/backup.sh -h #hourly 00 00 * * * /data/backup.sh -d #daily 00 00 * * 6 /data/backup.sh -w #weekly 00 00 1 * * /data/backup.sh -m #monthly
编辑：我更新了我的crontab以交错分钟,但它仍然无效：
# * * * * * user-name command to be executed 00 * * * * /data/backup.sh -h #hourly 05 00 * * * /data/backup.sh -d #daily 10 00 * * 6 /data/backup.sh -w #weekly 15 00 1 * * /data/backup.sh -m #monthly
我通过这个命令访问这些：
sudo crontab -u my_user_group_name -e
linux版本：
$cat /proc/version Linux version 3.10.0-514.6.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Wed Jan 18 13:06:36 UTC 2017
当作为手动shell脚本运行时,备份脚本可以自行运行,并带有任何标志(-h,-d,-w,-m).它工作没有失败.它是一个wordpress备份脚本,使用wp-cli,它基本上序列化了MariaDB数据库.为了完整起见,我在本问题的最后加入了脚本.
我已经仔细检查了一般cron troubleshooting advice from this answer,但我认为没有任何适用于我的问题：
>我认为问题不在于备份脚本本身,因为问题只发生在cron运行期间,而不是直接在shell中运行.很高兴有人证明我错了.
>我认为问题不在于更广泛的环境,而在于与cron配置本身有关(上图),因为问题仅在某些cron运行期间发生,但其他人执行成功.例如,Crontab没有错误名称,它具有正确的权限等.
> cron的回答没有说明cron运行的频率,运行之间的冲突,或者我认为可能在问题背后的其他动态.
以下是有问题的备份目录的权限(在/ data / backup /中.如您所见,每小时和每周目录具有相同的权限.
drwxr-xr-x. 2 libsys libsys 4096 Feb 20 00:05 daily drwxrwxr-x. 2 root backup 4096 Feb 20 10:00 hourly -rw-rw-r--. 1 root backup 35644 Feb 20 10:00 log.txt drwxrwxr-x. 2 root backup 4096 Feb 13 11:23 manual drwxrwxr-x. 2 aBerry3 aBerry3 4096 Feb 6 10:36 monthly drwxrwxr-x. 2 aBerry3 aBerry3 4096 Feb 6 10:36 weekly
我只是注意到每日权限没有组写;我会解决这个问题,并在一周内回来查看.然而,这可能是一个红鲱鱼;我的问题不在于每日备份,它可以正常工作：只有每周和每月备份不会发生.
这是备份脚本：
#!/bin/bash # Usage # This script will make a backup of the wordpress database,into the # defined backup directory,"/data/backups". # Options are -hdwm,for "hourly","daily","weekly","monthly"; these # simply put the backups into different subdirectories. Running the script # without options creates four backups,one in each directory. # The script also "cleans up" the directories afterward. # constants WP_DIR=/var/www/wordpress/docroot data_dir=/data/backups LOG=$data_dir/log.txt # vars TIMESTAMP=$(date +%Y-%m-%d.%H-%M-%s) # run all commands from WP root directory cd $WP_DIR # the meat of the backup script backup () { # arguments: "hourly","monthly","manual" INTERVAL=$1 BACKUP_DIR=$data_dir/$INTERVAL # create directory hierarchy if not exists mkdir -p $BACKUP_DIR # create backup FILENAME=$(printf "%s/wp-mariadb-%s.sql" "$BACKUP_DIR" "$TIMESTAMP") /usr/local/bin/wp db export $FILENAME # make sure backup happened if [ -s $FILENAME ] then echo "√ backup OK $TIMESTAMP $INTERVAL" >> $LOG else echo "!!! backup FAIL $TIMESTAMP $INTERVAL" >> $LOG exit 1 # terminate and indicate error fi # clean up backup directory BACKUP_FILES=$BACKUP_DIR/*.sql case $INTERVAL in "hourly") KEEP=24 ;; "daily") KEEP=7 ;; "weekly") KEEP=4 ;; "monthly") KEEP=12 ;; "manual") KEEP=999 # don't automatically delete manual backups ;; esac # evaluate which files to delete from directory for BACKUP in $BACKUP_FILES; do # if (BACKUP_FILES quantity > KEEP) # and if (BACKUP age in minutes) > (minutes ago) # delete backup ARR=($BACKUP_FILES) # convert to array LEN=${#ARR[@]} # length of array # if we have too many backups... if (($LEN > $KEEP)); then # ...delete the backup. rm $BACKUP fi done } # run particular backup scripts depending on options while getopts "hdwma" arg; do case $arg in h) backup "hourly" ;; d) backup "daily" ;; w) backup "weekly" ;; m) backup "monthly" ;; a) # a stands for all; backup everywhere backup "hourly" backup "daily" backup "monthly" ;; *) echo "Error: command not recognized" echo "!!! backup FAIL $TIMESTAMP illegal option in '$1'" >> $LOG ;; esac done
... √ backup OK 2017-02-17.22-00-01 hourly √ backup OK 2017-02-17.23-00-01 hourly √ backup OK 2017-02-18.00-00-02 hourly √ backup OK 2017-02-18.00-05-01 daily !!! backup FAIL 2017-02-18.00-10-02 weekly √ backup OK 2017-02-18.01-00-01 hourly √ backup OK 2017-02-18.02-00-02 hourly √ backup OK 2017-02-18.03-00-02 hourly √ backup OK 2017-02-18.04-00-02 hourly √ backup OK 2017-02-18.05-00-01 hourly √ backup OK 2017-02-18.06-00-01 hourly √ backup OK 2017-02-18.07-00-01 hourly √ backup OK 2017-02-18.08-00-02 hourly √ backup OK 2017-02-18.09-00-02 hourly √ backup OK 2017-02-18.10-00-01 hourly √ backup OK 2017-02-18.11-00-04 hourly √ backup OK 2017-02-18.12-00-03 hourly √ backup OK 2017-02-18.13-00-02 hourly √ backup OK 2017-02-18.14-00-02 hourly √ backup OK 2017-02-18.15-00-01 hourly √ backup OK 2017-02-18.16-00-02 hourly √ backup OK 2017-02-18.17-00-04 hourly √ backup OK 2017-02-18.18-00-02 hourly √ backup OK 2017-02-18.19-00-02 hourly √ backup OK 2017-02-18.20-00-02 hourly √ backup OK 2017-02-18.21-00-02 hourly √ backup OK 2017-02-18.22-00-03 hourly √ backup OK 2017-02-18.23-00-02 hourly √ backup OK 2017-02-19.00-00-03 hourly √ backup OK 2017-02-19.00-05-02 daily √ backup OK 2017-02-19.01-00-03 hourly √ backup OK 2017-02-19.02-00-02 hourly √ backup OK 2017-02-19.03-00-01 hourly ...
这个命令：
sudo crontab -u my_user_group_name -e
结合备份目录的各种用户和组所有权：
drwxr-xr-x. 2 libsys libsys 4096 Feb 20 00:05 daily drwxrwxr-x. 2 root backup 4096 Feb 20 10:00 hourly -rw-rw-r--. 1 root backup 35644 Feb 20 10:00 log.txt drwxrwxr-x. 2 root backup 4096 Feb 13 11:23 manual drwxrwxr-x. 2 aBerry3 aBerry3 4096 Feb 6 10:36 monthly drwxrwxr-x. 2 aBerry3 aBerry3 4096 Feb 6 10:36 weekly
看起来很腥.我猜测实际用户 – 假设你真的没有名为my_user_group_name的用户 – 不是aBerry3.如果我采取疯狂猜测,我会说libsys正在运行脚本谁是备份的成员,但不是aBerry3组的成员.
原文地址：https://www.jb51.cc/centos/373339.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
