Eu tenho um problema muito estranho. Eu tenho dois servidores, ou seja, daytona , que serve como um servidor de armazenamento com uma matriz de raid. Eu WOL quando eu quero voltar para ele. O segundo servidor é testarossa , que executa meus serviços. É o último que eu quero fazer backup diariamente usando duplicidade. Ambas as máquinas rodam o Ubuntu Server 14.04, totalmente atualizado.
Eu escrevi um script para o WOL na máquina e depois executo o backup de duplicidade a cada dia em um horário fixo.
A parte de importação do backupscript é mostrada abaixo. O backup é executado como usuário root on testarossa e backups via SSH via backupper on daytona . Em seguida, ele é desligado via ssh usando o usuário christophe on daytona .
Eu configurei as chaves ssh em testarossa para que eu possa usar ssh em daytona usando backupper e christophe . Eu posso executar os comandos do script muito bem, e até mesmo executar o script no shell também ( ./script.sh ).
Eu adicionei o script nos cronjobs usando:
0 10 * * * /bin/bash /root/scripts/dailybackup >> /var/log/backup.daily.log 2>&1
Cada vez que o cronjob é executado, recebo o seguinte erro:
BackendException: ssh connection to [email protected]:22 failed: [Errno 111] Connection refused
Eu sugeri em #ubuntu-server , tentei echo "" | nc 192.168.1.120 22 e isso retorna o seguinte erro:
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
Protocol mismatch.
Isso me levou a acreditar que eu tinha que atualizar daytona que eu fiz. Houve uma atualização para o pacote gnu-openssl e, em seguida, o cronjob foi executado corretamente. Mas agora isso não acontece mais.
Não tenho ideias sobre como depurar isso. Eu tenho pouca experiência para consertar isso. Quaisquer ponteiros?
Script
serverip=192.168.1.120
servermac=14:DA:E9:4C:6E:17
attempts=50
sourcedir="/"
targetdir="sftp://[email protected]//mnt/raidarr0/backups/testarossa/duplicity/daily"
encryptkey="AC7A8F8C"
keep="1M"
sudouser="christophe"
fullbackup=""
## Load in the passphrase file env variable
. /root/.passphrase
export PASSPHRASE
## Do the snapshot backup
if [ "$fullbackup" == "full" ]; then
$(which duplicity) full --encrypt-key "$encryptkey" --exclude /srv --exclude /usr --exclude /cdrom --exclude /lib64 --exclude /bin --exclude /sbin --exclude /boot --exclude /dev --exclude /proc --exclude /sys --exclude /tmp --exclude /run --exclude /mnt --exclude /media --exclude /lost+found "$sourcedir" "$targetdir"
else
$(which duplicity) --encrypt-key "$encryptkey" --exclude /srv --exclude /usr --exclude /cdrom --exclude /lib64 --exclude /bin --exclude /sbin --exclude /boot --exclude /dev --exclude /proc --exclude /sys --exclude /tmp --exclude /run --exclude /mnt --exclude /media --exclude /lost+found "$sourcedir" "$targetdir"
fi
echo "Backup to target completed."
## Remove older backups. We only want to backup 30 days.
# (We have a full every month)
$(which duplicity) remove-older-than "$keep" --force "$targetdir"
echo "Removal of stale backups completed"
## Shut down the machine using a sudo account. Expects the user to have a key installed for this.
ssh "$sudouser"@"$serverip" "sudo shutdown -h now"
echo "Shutdown command issued to remote machine"
Acompanhamento:
1) O script tem uma função que aguarda o host ser pingável. Então, ele só começa a fazer backup quando o host inicializa completamente. (Este script funcionou bem por mais de um ano em uma máquina diferente com o Debian.)
2) O script é executado corretamente no shell da raiz.
3) E não, eu não tenho um comando de proxy em ambos os arquivos de configuração.
4) Eu tentei executar o comando usando sudo /bin/bash /root/scripts/dailybackup e agora, por algum motivo, ele me pede para verificar a autenticidade do host (com yes/no ). Então agora parece que o comando duplicity não está usando meu arquivo known_hosts ?