Parar a condição de corrida da tarefa agendada rsync (diretório grande, intervalo de tempo pequeno)

Question

Informações da plataforma:

OpenBSD 6.2 amd64

$ rsync --version rsync version 3.1.2 protocol version 31

Estou tentando sincronizar um diretório grande (4 TB) usando o seguinte arquivo daily.local (para administradores do Linux, isso é essencialmente uma tarefa diária do cron):

#!/bin/sh
# Sync the primary storage device to the backup disk
/usr/local/bin/rsync -avz /mnt/media_primary/ /mnt/media_backup/

A cópia inicial do rsync demora mais de um dia. Depois de um dia ou dois, acabo com várias cópias em execução do rsync na minha lista de processos: novos são iniciados como planejados e esses novos processos parecem estar competindo entre si e não terminando a tarefa (pelo menos rapidamente)!

Existe uma maneira de tornar um novo processo de rsync ciente de outros processos de rsync (ou outra maneira de evitar condições de corrida do rsync)?

Sei que posso executar o rsync manualmente para copiar o diretório pela primeira vez e / ou aumentar o intervalo de tempo planejado. Essa pergunta é mais para o meu interesse, pois não consegui encontrar informações na Internet sobre esse assunto.

    

Answer 1

Uma maneira de contornar esse problema (se o diretório de backup estiver em sua própria partição) é deixar o volume desmontado, montando apenas antes de iniciar o comando rsync. Isso nega a necessidade de usar flock e pode ter o benefício de prolongar a longevidade da unidade / reduzir o consumo de energia.

/etc/fstab : adicione a opção noauto à partição para que ela não seja montada automaticamente na inicialização

Na tarefa agendada daily.local ou cron.daily :

#!/bin/sh
mount /mnt/media_backup && \
/usr/local/bin/rsync -avz /mnt/media_primary/ /mnt/media_backup/ && \
umount /mnt/media_backup

O operador de "e" comercial duplo ( && ) somente iniciará o próximo comando se o comando anterior for bem-sucedido. Portanto, se o disco de backup não puder ser montado (porque já está montado e o rsync já está em execução na partição), o restante do comando não continuará.

    

Answer 2

Uma solução que seria um pouco semelhante à solução de Mark , mas sem exigir alterações no /etc/fstab ou Montando e desmontando sistemas de arquivos:

#!/bin/sh

lockdir=/tmp/file-copy.lock

if ! mkdir "$lockdir"; then
   echo 'File copy already in progress' >&2
   exit 1
fi

trap 'rmdir "$lockdir"' EXIT

PATH=$PATH:/usr/local/bin

rsync -ai ...

Algumas notas sobre isso:

1. A mkdir é uma operação atômica, muito parecida com mount , que falhará se o diretório já existir, mas criará o diretório se não existir. Isso é mais seguro do que primeiro verificar um arquivo de bloqueio e depois criá-lo (duas etapas com a possibilidade de uma condição de corrida intermediária).

2. O trap EXIT garante que o diretório de bloqueio seja excluído quando o script terminar. O diretório de bloqueio também seria excluído nas reinicializações (pelo sistema), pois está em /tmp .

3. Eu defino PATH para o valor apropriado em vez de chamar rsync com seu caminho completo. Isso é puramente uma coisa cosmética, mas pode ser útil se o script for expandido para usar outros comandos da coleção de ports do OpenBSD (como restic ou borgbackup ).

4. A opção -z para rsync é realmente necessária somente em conexões de rede muito lentas

   (quando a compactação / descompactação de dados é feita mais rápido que a largura de banda da rede) e nunca para cópia local. Também tenho a tendência de favorecer o -i ( --itemize-changes ) sobre -v ( --verbose ), pois isso me dirá exatamente por que um arquivo foi transferido.

Para fazer o backup de grandes quantidades de dados com segurança, eu geralmente recomendaria o uso de um software de backup escrito para fins específicos sobre rsync , como restic ou borgbackup . Esses dois também fazem a desduplicação e a criptografia de dados, e borgbackup pode, opcionalmente, fazer compactação. restic é bom no sentido de permitir salvar backups em um servidor externo (por exemplo, sftp ), mesmo que o servidor não tenha restic instalado, enquanto borgbackup exige que o software esteja instalado o sistema de destino. Tanto restic quanto borgbackup manipulam o bloqueio do repositório de backup.