Não descarte mensagens potencialmente úteis
Sempre que uma tarefa do cron falha misteriosamente, minha primeira ação geralmente é redirecionar STDOUT e STDERR para arquivos em / tmp para que eu possa ver qualquer mensagem de erro e outra saída potencialmente útil.
Assim, a entrada do cron seria
00 5 * * * /path/to/script/backup.sh >/tmp/backup.out 2>&1
Faça scripts auto documentando
Eu também geralmente garanto que algo útil está escrito lá, adicionando saída de diagnóstico para o script:
#!/bin/sh
echo "Backup starting..."
date
rsync -e"ssh -i /path.to/id_rsa" \
-aP MyUsername@HostIP:/path/to/host/backup/ \
/path/to/local/backup \
--exclude '*.sql'
echo "Backup ended"
Verifique as man pages
A página man do rsync diz
-q, --quiet
This option decreases the amount of information you are given during the
transfer, notably suppressing information messages from the remote server.
This option is useful when invoking rsync from cron.
Portanto, é provável que, quando a saída do rsync for direcionada para / dev / null, o rsync perceba que o STDOUT não está conectado a um terminal ou a um arquivo regular e termina com uma condição de erro.
Você talvez possa verificar isso alterando o comando cron para
00 5 * * * /path/to/script/backup.sh >/dev/null 2>/tmp/backup.err
e, em seguida, revendo o conteúdo de /tmp/backup.err
No entanto, adicionar a opção -q
seria uma solução apropriada.
Um shell em lote não é como um shell interativo
Geralmente, ao executar a partir do cron, existem algumas diferenças importantes correndo de forma interativa
- Você não pode confiar nas variáveis de ambiente que estão sendo configuradas (pegadinha importante)
- Não há um TTY anexado ao processo (alguns programas dependem disso)
- etc
Então, quando as coisas não funcionam como esperado, você deve reconsiderar como tudo isso pode afetar o que você está fazendo.