rsync funciona bem até eu colocá-lo no crontab (UPDATE: 'date' não funciona no crontab)

Question

Eu tenho este comando rsync que funciona muito bem quando eu o executo a partir da linha de comando (Ubuntu Server 12.04.1 LTS). Eu gostaria que ele fosse executado a cada hora, na hora e gerasse os resultados (juntamente com erros) em um arquivo de log. Aqui está o comando que eu coloquei no crontab:

0 * * * * root rsync -av --delete -e "ssh -i /root/.ssh/id_rsa" 
user@host:/path/to/dir/ user@host:/path/to/another/dir/ /destination/dir
--exclude='.DS_Store' &> /var/log/backup/'date '+%Y_%m_%d_%H:%M''_hourlybackup.log

Apesar de funcionar exatamente como eu esperava do bash, nada acontece quando está no crontab. Ele nem escreve erros no arquivo. A execução de ps aux | grep rsync não mostra nada de interesse. Eu não consigo encontrar o problema. Alguma idéia?

ATUALIZAÇÃO: Graças às respostas que recebi, consegui ajustar o comando para que ele funcionasse corretamente, embora nenhum deles resolvesse o problema por conta própria. Aqui está o que eu encontrei obras esta manhã:

0 * * * * /usr/bin/rsync -av --delete -e "ssh -i /root/.ssh/id_rsa" 
user@host:/path/to/dir/ user@host:/path/to/another/dir/ /destination/dir
--exclude='.DS_Store' > /var/log/backup/_hourlybackup.log 2>&1   

Por alguma razão, o date '+%Y_%m_%d_%H:%M' (incluído nos backticks) está causando o problema. Se eu removê-lo do comando, funciona muito bem ... embora seja importante para mim que eu tenha logs de backup abrangentes, então eu ainda gostaria de encontrar uma solução para isso. Eu continuarei hackeando, mas se alguém souber, seja meu convidado.

    

Answer 1

O problema, como mencionei na atualização, é com o comando date . Acontece que, se você estiver escrevendo o comando diretamente no crontab , e não em um script de shell, será necessário escapar da % na sequência de caracteres date . Veja o que acabou funcionando:

0 * * * * rsync -av --delete user@host:/path/to/dir 
user@host:/path/to/another/dir /path/to/destination
--exclude='.DS_Store' >
/var/log/backup/'date '+\%Y_\%m_\%d_\%H''h_hourlybackup.log 2>&1

Obrigado por todos que me ajudaram a descobrir isso. Este comando provavelmente ficará mais longo e complexo no futuro e, portanto, será mais adequado ao seu próprio shell script, mas por enquanto está bem diretamente em crontab , eu acho.

    

Answer 2

Na maioria das vezes, é porque você não colocou um caminho completo para o seu rsync como

/usr/bin/rsync -av ...

Além disso, você pode tentar criar um pequeno script de shell e colocar esse comando lá e apenas execute esse script único do seu cron

    

Answer 3

Pode ser um problema de caminho, mas não é provável, já que o root deve ter /usr/bin em seu caminho.

No entanto, os comandos crontab são provavelmente não executados no Bash, mas no Dash . A construção &> é um "Bashism" [ 1 ] [2 ].

Substituir

command >& file

com

command > file 2>&1

para que funcione como pretendido no Dash.

    

Answer 4

coloque seu comando rsync em um script .sh (shell) para iniciá-lo com o crontab

• pesquise sobre o script de shell como este exemplo

  test.sh

#!/bin/sh

echo $2 echo $1

• no seu script use esta sintaxe para nomear seu arquivo de backup

now=$(date +"%m_%d_%Y")

.. &> /var/log/backup/{$now}_hourlybackup.log

    

Answer 5

Teria simplesmente comentado a resposta verificada, mas era novo e ainda não posso comentar.

Eu só queria explicar por que você estava vendo esse problema. % significa uma nova linha e qualquer texto após o primeiro é fornecido para o comando como stdin.

Então, seu comando cron:

rsync -av --delete -e "ssh -i /root/.ssh/id_rsa" user@host:/path/to/dir/ \
  user@host:/path/to/another/dir/ /destination/dir --exclude='.DS_Store' \
  &> /var/log/backup/'date '+%Y_%m_%d_%H:%M''_hourlybackup.log

é interpretado como:

rsync -av --delete -e "ssh -i /root/.ssh/id_rsa" user@host:/path/to/dir/ \
  user@host:/path/to/another/dir/ /destination/dir --exclude='.DS_Store' \
  &> /var/log/backup/'date '+<<EOI
Y_
m_
d_
H:
M''_hourlybackup.log
EOI

Quando o shell tenta executá-lo, ele não pode encontrar o segundo 'como está agora presente como parte do stdin do comando. A chave é perceber que todos os caracteres% precisam ser escapados, a menos que você realmente queira novas linhas.