Esta é uma extensão paraPor que o rsync tenta copiar um arquivo que já está atualizado?
Estou tentando usar o --copy-devicespatch para rsynccopiar uma unidade de disco inteira e armazená-la como uma imagem em outra máquina.
A cópia parece ter sido executada corretamente, no entanto, quando executo rsyncnovamente com os mesmos valores, parece que alguns dos dados são copiados novamente todas as vezes.
Corri rsynccom a verbosidade aumentada e consegui isto:
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
Estou ciente de que o rsync determina as alterações por tempo, mas o disco não mudou entre os rsyncs (e como ele determinaria o horário modificado de um disco?) O horário na imagem remota, entretanto, é atualizado a cada vez. Então esse pode ser o problema.
A outra possibilidade é que o disco tenha um setor defeituoso que retorna um valor diferente a cada vez e nega qualquer soma de verificação que esteja sendo usada.
Minha pergunta é dupla:
Minha imagem foi transferida com êxito e, em caso afirmativo, por que ela parece retransmitir grande parte do disco se eu executá-la novamente? (Isso também pode ser parcialmente respondido como parte da minha pergunta coroláriaO que são "correspondências", "hash_hits" e "false_alarms" na saída rsync e "data = 0" significa sucesso?)
Estou faltando uma opção para fazer isso funcionar corretamente? (Talvez
--checksum?) É possível listar falhas em nível de bloco usadas pelo algoritmo rsync?
Responder1
Por padrão, o rsync compara arquivos por tamanho e carimbo de data / hora, mas um dispositivo não possui tamanho, portanto deve calcular as diferenças usando o algoritmo delta descrito nesterelatório técnico. Vagamente, o arquivo remoto é dividido em blocos de tamanho escolhido e as somas de verificação destes são enviadas de volta. O arquivo local é igualmente verificado em blocos e comparado com a lista. O controle remoto é então informado sobre como remontar os blocos necessários para refazer o arquivo, e os dados dos blocos que não correspondem são enviados.
Você pode ver isso solicitando a saída de depuração no nível 3 apenas para o algoritmo deltasum com a opção --debug=deltasum3. Você pode especificar um tamanho de bloco para -Bsimplificar os números. Por exemplo, para um arquivo que já foi copiado uma vez, uma segunda execução de
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
produz uma saída como esta mostrando a soma de verificação para cada bloco:
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
Você pode então ver que ele corresponde às somas de verificação do outro dispositivo de maneira bastante trivial, já que não há diferenças:
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
No final o data=campo é 0, indicando que nenhum dado novo foi enviado.
total: matches=164 hash_hits=164 false_alarms=0 data=0
Se agora corrompermos a cópia substituindo o meio do arquivo:
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
então a depuração do rsync nos mostra uma nova soma de verificação para o bloco 80, mas nenhuma correspondência para ela. Vamos do jogo 79 ao jogo 81:
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
No final mostramos data=100000que todo um novo bloco de dados teve que ser enviado.
total: matches=163 hash_hits=385 false_alarms=0 data=100000
O número de correspondências foi reduzido em 1, para a soma de verificação do bloco corrompido que não correspondeu. Talvez os acertos de hash aumentem porque perdemos a correspondência sequencial.
Se olharmosavançarno mesmo relatório técnico, alguns resultados de testes são mostrados e oalarmes falsos são descritos como "o número de vezes que a soma de verificação contínua de 32 bits correspondeu, mas a soma de verificação forte não". Cada bloco possui uma soma de verificação simples e uma soma de verificação md5 feita (md4 em versões mais antigas). A soma de verificação simples é fácil de pesquisar usando uma tabela hash, pois é um número inteiro de 32 bits. Assim que corresponder a uma entrada, a soma de verificação md5 de 16 bytes mais longa também será comparada e, se não corresponder, será um alarme falso e a pesquisa continuará.
Meu exemplo usa um dispositivo de chave USB muito pequeno (e antigo) de 16 Mbytes, e o tamanho mínimo da tabela hash é 2 ** 16, ou seja, 65.536 entradas, portanto, fica bastante vazio ao armazenar as 164 entradas de pedaços que tenho. Muitos alarmes falsos são normais e são mais uma indicação de eficiência do que qualquer outra coisa.
Responder2
Você deve considerar o uso rsync --partial --inplacejunto com suas outras opções, caso contrário, ele fará uma cópia completa da imagem do disco no lado de destino enquanto estiver funcionando. Eu também tenho usado -B 4096porque é o tamanho natural do setor do dispositivo e o tamanho do bloco padrão do rsync é muito pequeno para esse tipo de operação.
Para verificar se a imagem foi copiada corretamente, sugiro um independente sha1sumfeito tanto na origem quanto no destino. Não deveria ser necessário, mas se você quiser ter certeza, é simples e você pode confiar. Presumo que o seu disco de origem não seja uma montagem ativa ou algo desagradável assim, caso contrário, todas as apostas serão canceladas e não haverá um método confiável para enviá-lo.