Назад | Перейти на главную страницу

Почему скрипт резервного копирования не работает с cron?

Итак, я делаю автоматическое резервное копирование базы данных. Сценарий резервного копирования работает правильно, как когда я запускаю его вручную, так и когда 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

Сценарий резервного копирования отлично работает сам по себе при запуске в качестве ручного сценария оболочки с любым из флагов (-h, -d, -w, -m). Работает в обязательном порядке. Это сценарий резервного копирования Wordpress, использующий wp-cli, который по сути сериализует базу данных MariaDB. Для полноты картины я включил сценарий в конце этого вопроса.

Я внимательно изучил генерала совет по устранению неполадок cron из этого ответа, но я не вижу ничего подходящего к моей проблеме:

Я не думаю, что проблема связана с самим сценарием резервного копирования, поскольку проблема возникает только во время запуска cron, а не когда он запускается непосредственно в оболочке. Рад, что кто-то доказал мою неправоту.
Я не думаю, что проблема связана с более широкой средой, а скорее связана с самой конфигурацией 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", "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

Выглядит подозрительно. Я предполагаю фактического пользователя - при условии, что у вас действительно нет пользователя с именем my_user_group_name - не aberry3. Если бы я сделал безумное предположение, я бы сказал libsys запускает скрипт, который является членом backup но не член aberry3 группы.

Поскольку вы все равно создаете каталоги в сценарии, попробуйте переименовать существующие и позвольте сценарию создать их с владельцем / группой фактического пользователя, запускающего сценарий.

Добавьте в скрипт еще логирование.

Добавьте «-x» в первую строку скрипта.

#!/bin/bash -x

Это должно дать вам более подробный вывод сценария в электронном письме, которое отправляется на адрес, указанный в опции cron «MAILTO».

Также согласно документации (https://wp-cli.org/commands/db/export/) вы можете добавить «--debug» к команде «wp db export». Попробуйте вот так.

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

Вы можете опубликовать содержимое письма, которое вы получите в случае сбоя сценария, это должно дать вам / нам достаточно данных, чтобы точно определить проблему.

Пытаться,

sudo chown root: еженедельное резервное копирование