O cp / rsync é assíncrono?

Question

Estamos executando um script de backup que primeiro copia um arquivo para um destino e, em seguida, executa tar sobre ele.

DIR2BCK='/foo/bar'
TMPDIR=$(mktemp -d)
rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1
tar czf /tmp/foo.backup.tar ${TMPDIR}

Depois de executar este último comando, às vezes, o seguinte aviso é exibido:

/tmp/tmp.blqspkA136: file changed as we read it

Copiamos o destino para um diretório temporário com precisão para evitar alterações no arquivo no momento da compactação. Esse comportamento também é reproduzível ao usar o comando cp em vez de rsync . Toda a minha vida eu pensei que esses comandos eram síncronos, mas este aviso parece mostrar o contrário.

Se eu colocar um comando sleep entre as linhas rsync / cp e tar , o aviso não será exibido, mas considero isso uma solução não muito limpa.

Alguns fatos:

• Eu tentei adicionar um comando sync entre os comandos rsync e tar com o mesmo resultado.

• Como sugerido por @jcbermu, também tentei alterar o script para que as duas linhas sejam:

  rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 &
  wait
  

  Eu corri o script várias vezes e alguns deles mostraram o mesmo comportamento, alegando que o arquivo mudou ao copiar.

• O sistema de arquivos usado é o EXT4 para ${TMPDIR} e ${DIR2BCK} .

• ${DIR2BCK} está em um sistema de arquivos remoto, na verdade, este é um ponto de montagem do samba de uma máquina remota. ${TMPDIR} está no sistema de arquivos local. No entanto, alterar ${DIR2BCK} para o sistema de arquivos local não faz diferença.
• Todos os sistemas de arquivos são baseados em hardware RAID-5.

Esses comandos são realmente síncronos? Se não, existe uma maneira de torná-los assim, ou um comando alternativo?

    

Answer 1

Uma solução é reescrevê-lo como:

rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 ; tar czf foo.backup.tar ${TMPDIR}

Portanto, tar não será iniciado até que rsync termine.

A outra solução é enviar o cp / rsync para o segundo plano e aguardar até que ele termine com o comando wait .

Por exemplo:

rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 &
wait
tar czf foo.backup.tar ${TMPDIR}

O último & na linha rsync envia a execução para o segundo plano (torna-se um filho da sessão atual) e, em seguida, o wait força essa sessão do shell a aguardar até que todas as crianças tenham terminado para continuar.

    

Answer 2

I put a sleep command between the rsync/cp and the tar lines, the warning doesn't show up, but I consider this a not quite clean solution.

Bom para você ou ter padrões. O que acontece se, em vez de dormir, você usar:

sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

Você considera isso uma boa solução?

Nota: / proc / sys / vm / drop_caches parece ser o que o Ubuntu usa, e não se espera que seja uma abordagem que funcione em todos os Unixes (embora talvez todos os Linuxes). Estou mencionando isso depois de ler link e, depois de ler um relatório inicial questionando a segurança de fazer isso, lendo mais posts do fórum que confirmam sua segurança.