Perder permissões em links físicos ao usar o rsync --delete

1

Usando um meio de armazenamento baseado na nuvem (produto HiDrive da Strato), eu uso um esquema de backup usando rsync . Durante o horário de trabalho, a maioria dos meus arquivos do servidor local é copiada para backup na nuvem por um cronjob. Meu script de backup faz uso intensivo da capacidade do rsync de não copiar arquivos inalterados, mas de vinculá-los. Isso parece

rsync -av -M--perms  \
            $inp_sig $REMOTE_USER@$RSYNC_HOST:$REMOTE_BASIS/$CURRENT_SNAPSHOT \
            --exclude-from=$EXCLUDE_FILES \
            --link-dest=$link_destination/

onde todas as variáveis mostradas com antecedência são definidas para os valores corretos pelo script. Tudo isso funciona muito bem.

Durante a noite, outro script é iniciado, limpando os instantâneos que não são mais usados. Para a tarefa de exclusão, eu uso outro script que, no fundo, tem o seguinte comando rsync :

empty_dir='mktemp -d'
rsync -d --delete-before --inplace --perms \
            $empty_dir/  $REMOTE_USER@$RSYNC_HOST:$REMOTE_BASIS/$snap/ || \
                    log_rsync ERROR: could not delete $snap
rm $empty_dir

Este também funciona - quase. O problema é que todas as permissões em todos os arquivos vinculados são esmagadas pela exclusão de rsync (todas elas acabam com 644 permissões, em que algumas delas devem ter 444 ).

Eu venho lidando com o problema há vários dias, mexendo nas opções de excluir rsync em diferentes combinações. Eu tentei -rd vs. -r ou -a ; --delete vs. --delete-before , sem sucesso ainda. A partir da página man, eu aprendi que a opção --inplace deveria fazer o truque:

This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file... Hard links are not broken.

Isso me faz pensar que não usando --inplace deve resultar em hard links quebrados. Mas no nosso caso, links rígidos são quebrados de qualquer maneira (para os arquivos com diferentes bits de permissão).

Eles também têm uma interface cifs que é perfeitamente utilizável para um pequeno número de operações de arquivo. Mas um rm -rf em um diretório de snapshot não é de forma alguma viável - ele dura horas em um snapshot típico de backup, e eu tenho que executar de 16 a 20 exclusões por noite. A variante rsync é executada cerca de dois minutos.

Então, eu perdi devido ao meu limitado entendimento ou limitações implícitas de rsync ? Ou eu sou apenas infeliz por causa de uma má implementação de rsync do lado do provedor?

    
por H.W. Wyes 10.05.2017 / 17:15

1 resposta

1

Problema não totalmente resolvido, mas contornado.

O problema que descrevi no meu post é devido à implementação de rsync . Enviei um relatório de erros para o Bugzilla e recebi uma indicação clara de que rsync de fato não controla a permissão bits corretamente quando recursivamente excluir diretórios.

Eles apontaram uma solução alternativa usando a opção --super :

empty_dir='mktemp -d'
rsync -d --delete --super \
        $empty_dir/  $REMOTE_USER@$RSYNC_HOST:$REMOTE_BASIS/$snap/ || \
                log_rsync ERROR: could not delete $snap
rm $empty_dir

Sim, pode haver efeitos colaterais com a opção --super . Para minha aplicação, a solução alternativa é suficiente.

    
por 12.06.2017 / 10:17