Corrigir um arquivo binário muito grande em uma conexão lenta

0

para fins de backup, eu transferi um arquivo binário muito grande sobre uma conexão lenta comparativamente a montante (a transferência levou 2 semanas), rsincronizando-o em um cifs-share montado (assim eu pude e posso acessá-lo em bloco). Após as 2 semanas, o rsync mostrou um erro (infelizmente não pôde salvá-lo), mas o tamanho do arquivo foi igualado.

tail -c 1000000000 myfile.img|md5sum # and
head -c 1000000000 myfile.img|md5sum

jogo, então o início e o fim do arquivo são idênticos.

Como meu downstream é muito mais rápido, eu baixei a imagem completa novamente e fiz md5 somas sobre a coisa toda, e elas NÃO combinam. Então, aparentemente, em algum lugar desses 1,5 TB é pelo menos um bit que difere.

Existe uma maneira de gerar um "patch" dos dois arquivos que baixei e depois aplicá-lo no arquivo remoto, para que apenas os blocos errados tenham que ser transferidos novamente?

Por favor, note novamente: Eu não tenho o poder de executar o código remotamente ou fazer uso dos recursos do rsync que exigem a execução remota do rsync. Eu acho que eu ainda poderia usar o rsync e funciona na ordem de magnitude da minha taxa de download, mas eu me pergunto se há uma maneira melhor de fazer uso do fato de que eu tenho a versão localmente. Provavelmente não seria tão difícil escrever algo, mas eu preferiria usar algo testado e salvar o trabalho.

file-transfer rsync patch

— mcandril
fonte

Acabei de ver uma resposta aqui que sugeriu bsdiff. Eu não posso mais ver isso. Eu realmente olhei para isso e diz que está rodando com O ((n + m) log n). Como meus arquivos têm o mesmo tamanho e, aparentemente, grandes partes são iguais, acho que isso deve ser possível em O (n) - & gt; Executar uma vez sobre o primeiro arquivo, olhar para o bit correspondente no outro e anote se você quiser alterá-lo e para o quê.

— mcandril

Agora sobre o bsdiff: O Pentium Pro de 200MHz mencionado em sua página precisaria de 9375h para meus 1.5TB. Meu sistema não é tão lento, mas também não é um moderno Core i7. Então eu provavelmente ainda ficaria pelo menos na região do tempo em um novo download, que eu também seria capaz de alcançar com o rsync, usando este blog.christophersmart.com/2014/01/15/… . O outro sugeriu um que não consigo lembrar.

— mcandril

1

(assumindo Linux) se você acredita que há apenas um bloco ou mais de dados corrompidos, mas o tamanho do bloco não mudou, então você poderia usar cmp -l. Compara byte por byte e com -l fornece o deslocamento de quaisquer diferenças. Se você tem uma vaga idéia de onde começar dentro dos arquivos, você pode começar -i. Quando você tem as compensações em erro, você pode usar dd skip=... para recortar isso do arquivo original, e dd seek=... conv=notrunc para colá-lo no arquivo quebrado. (Teste na cópia primeiro)

— meuh
fonte

Impressionante, exatamente o que estou procurando!

— mcandril

0

Eu usaria o BitTorrent para recuperar o arquivo no lado remoto. O protocolo divide um arquivo em pequenos blocos e automaticamente re-transfere blocos cujos hashes não correspondem ao arquivo semente.

Para fazê-lo funcionar em um ambiente privado:

Desabilite o DHT nos clientes locais e remotos bit-torrent.
Abra portas locais de torrent de bits no firewall ou configure o encaminhamento de porta SSH.
Crie um arquivo de semente no lado da fonte. Não use um rastreador. Certifique-se de que o cliente comece a propagar o arquivo também.
Backup do arquivo no lado remoto.
Copie o arquivo de propagação para o lado remoto e abra-o com o cliente.
Aponte o local de download para o arquivo corrompido e escolha a opção não iniciar o download !! Também desative as opções para se conectar a DHT, troca de peer, etc, se disponível.
Peça ao cliente para verificar novamente o arquivo baixado. Deve informar uma porcentagem de download que está quase concluída.
Adicione o cliente local como um par ao download
Inicie o download

— billc.cn
fonte

Obrigado, mas como eu disse: não consigo executar código remotamente. Isso também significa que não pode haver um cliente bittorrent remoto. A única coisa que eu tenho são protocolos como o SCP (mas não o SSH, não posso nem obter checksum calculado no lado remoto), SFTP, CIFS, WebDAV. Potencialmente bagunçar coisas não é um grande problema, no entanto, uma vez que o armazenamento remoto suporta instantâneos.

— mcandril

Se você tiver acesso a SCP / CIFS / WebDAV, poderá montá-los como sistemas de arquivos locais e usar o BitTorrent como descrito acima. Seria extremamente lento embora ... Uma solução intermediária seria fazer isso de um computador com conexão rápida para o lado remoto. Por exemplo. Provedor AWS / VPS-by-hour próximo ao servidor remoto.

— billc.cn

Sim, mas nesse caso eu não vejo como o rsync não seria muito mais direto. Eu realmente tenho um servidor com acesso rápido a esse armazenamento, mas eu ainda usaria o rsync. Deveria ter pensado nisso para a transferência inicial. De qualquer forma, a proposta do meuh é exatamente o que eu quero e não consigo imaginar como isso poderia funcionar mais rápido. É O (n) localmente e só transfere os bytes errados.

— mcandril