为什么备份脚本与cron失败？

所以我正在做一个数据库的自动备份。备份脚本可以正常运行，无论是手动运行还是Cron运行计划的每小时和每日备份。但是，备份会在每周和每月的备份中失败。

我（显然）不知道，但我想我的问题是与cronconfiguration。也许冲突，因为剧本是在午夜多次运行？我不确定这是否可能，但如果是这样，我会很感激微调我的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 ([email protected].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疑难解答的build议，但我没有看到任何适用于我的问题：

我不认为这个问题与备份脚本本身有关，因为问题只发生在cron运行期间，而不是直接在shell中运行。很高兴有人certificate我错了。
我不认为这个问题与更广泛的环境有关，而是与cronconfiguration本身（上面）有关，因为问题只发生在某些cron运行期间，而另一些则成功执行。例如，Crontab没有错误，它有正确的权限等。
cron答案中没有提到cron运行的频率，运行之间的冲突或者我认为可能出现的其他dynamic。

以下是有关备份目录的权限（在/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", "daily", "weekly", "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

看起来很腥。我猜的实际用户 – 假设你真的没有一个名为aberry3的用户 – 不是aberry3 。如果我libsys猜测，我会说libsys运行的脚本谁是backup的成员，但不是aberry3组的成员。

由于您是在脚本中创build目录，请尝试重命名现有的目录，并让脚本使用运行该脚本的实际用户的所有者/组创build它们。

尝试，

sudo chown root：每周备份

向脚本添加更多日志logging。

将“-x”添加到脚本的第一行。

#!/bin/bash -x

这应该给您在发送到“MAILTO”cron选项中指定的地址的电子邮件中脚本的更详细的输出。

另外，根据文档（ https://wp-cli.org/commands/db/export/ ），您可以将“–debug”添加到“wp db export”命令中。像这样尝试。

/usr/local/bin/wp db export --debug $FILENAME

您可以发布脚本失败时将收到的邮件内容，这应该能够为您提供足够的数据来查明问题。