Por que o script de backup falha com o cron?

3

Estou fazendo backups automatizados de um banco de dados. O script de backup funciona corretamente, tanto quando eu o executo manualmente quanto quando o Cron executa backups diários e por hora programados. O backup falha, no entanto, nos backups semanais e mensais.

Eu (obviamente) não tenho certeza, mas suponho que meu problema seja com a configuração do cron. Talvez um conflito porque o script está sendo executado várias vezes à meia-noite? Não tenho certeza se isso é possível, mas em caso afirmativo, gostaria de receber instruções sobre o ajuste fino do meu crontab.

meu 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

edit: atualizei meu crontab para ter minutos escalonados, mas ainda não funciona:

# *  *  *  *  * 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

Eu os acesso através deste comando:

sudo crontab -u my_user_group_name -e

versão linux:

$ cat /proc/version 
Linux version 3.10.0-514.6.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Wed Jan 18 13:06:36 UTC 2017

O script de backup funciona bem por si próprio, quando executado como um script de shell manual, com qualquer um dos sinalizadores (-h, -d, -w, -m). Ele funciona sem falhas. É um script de backup do Wordpress, usando wp-cli , que basicamente serializa um banco de dados MariaDB. Para completar, incluí o script no final desta pergunta.

Eu examinei de perto o geral conselhos de solução de problemas do cron desta resposta , mas não vejo nada aplicável ao meu problema:

  • Não acho que o problema esteja no próprio script de backup, pois o problema ocorre apenas durante as execuções do cron, e não quando é executado diretamente no shell. Feliz por alguém provar que estou errado.
  • Eu não acho que o problema esteja com o ambiente mais amplo, mas é algo relacionado à própria configuração do cron (acima), já que o problema ocorre apenas durante algumas execuções do cron, mas outras são executadas com sucesso. Por exemplo, o Crontab não tem nome incorreto, tem permissões corretas, etc.
  • A resposta do cron não diz nada sobre a frequência de execuções do cron, conflitos entre execuções ou outras dinâmicas que acredito serem prováveis por trás do problema.

Aqui estão as permissões para os diretórios de backup em questão (em /data/backup/ . Como você pode ver, os diretórios por hora e por semana têm as mesmas permissões.

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

Eu notei que as permissões diárias não têm gravação em grupo; Vou consertar isso e voltar daqui a uma semana. É provavelmente um arenque vermelho, no entanto; meu problema não é com os backups diários, que funcionam bem: apenas os backups semanais e mensais não acontecem.

Aqui está o script de backup:

#!/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

aqui está uma amostra do meu arquivo de log, simplesmente mostrando o problema:

...
√   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
...
    
por allanberry 13.02.2017 / 18:39

3 respostas

3

Este comando:

sudo crontab -u my_user_group_name -e

Combinado com a variedade de propriedades de usuários e grupos de seus diretórios de 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

Parece suspeito. Eu estou supondo que o usuário real - supondo que você não tenha realmente um usuário chamado my_user_group_name - não é aberry3 . Se eu quisesse adivinhar, diria que libsys está executando o script que é membro de backup , mas não é membro de aberry3 groups.

Como você está criando os diretórios no script, tente renomear os existentes e deixar o script criá-los com o proprietário / grupo do usuário que está executando o script.

    
por 23.02.2017 / 04:09
1

Tente,

sudo chown root: backup semanalmente

    
por 21.02.2017 / 15:07
1

Adicione mais logging ao script.

Adicione "-x" à primeira linha do script.

#!/bin/bash -x

Isso deve fornecer uma saída mais detalhada do script no email que é enviado para o endereço especificado na opção cron "MAILTO".

Além disso, de acordo com a documentação ( link ), você pode adicionar "--debug" ao " wp db export "comando. Tente assim.

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

Você pode postar o conteúdo do e-mail que receberá quando o script falhar, o que deve fornecer dados suficientes para identificar o problema.

    
por 22.02.2017 / 20:07