O tamanho do rsync é diferente da origem para o destino

4

Estou usando o rsync com as opções

-r for recursive
-l copy symlinks as symlinks
-t preserve modification time
-D preserve devices and specials
-v verbose
--prune-empty-dirs

A fonte FS é ext4 e o destino é XFS. Eu copiei algumas centenas de pastas que variam entre algumas centenas de gigabytes para poucos TB e elas estão todas dentro de menos de 1GB de diferença de tamanho. No entanto, esta pasta específica é 264GB na fonte e uma vez eu rsync ele é 286GB. Essa é uma diferença enorme e eu não sei o que está errado com isso.

Se a fonte ext4 FS tiver algum dano, é possível que não esteja relatando o uso correto do disco? Estou usando 'du-skh'.

Eu apaguei a coisa toda e reiniciei 3 vezes e ela produz os mesmos resultados.

    
por lbanz 05.11.2015 / 10:51

4 respostas

3

A página de perguntas frequentes do rsync lista esses motivos: link

No entanto, a única maneira de saber é comparar os arquivos.

Para um pequeno número de arquivos, você pode fazer diff -r /mnt/data /mnt/data-BACKUP . No entanto, se isso parar no meio do caminho, ele não poderá ser reiniciado de onde parou. Os programas de diff mais antigos não lidam bem com arquivos binários.

Para um grande número de arquivos, recomendo calcular os hashes de todos os arquivos e procurar diferenças. Desta forma, se o processo parar ou quebrar, você pode continuar sem muita dificuldade.

Veja este script como um exemplo:

link

md5tree /mnt/data        >/var/tmp/list.orig
md5tree /mnt/data-BACKUP >/var/tmp/list.backup
# NOTE: For these next 2 lines TAB means press the TAB key.
sort  -t'TAB' -k6 </var/tmp/list.backup >/var/tmp/list.backup.sorted
sort  -t'TAB' -k6 </var/tmp/list.orig >/var/tmp/list.orig.sorted
diff /var/tmp/list.orig.sorted /var/tmp/list.backup.sorted
    
por 06.11.2015 / 16:04
2

A causa mais provável é links físicos . Por padrão, o Rsync transforma dois arquivos com link físico em arquivos duplicados no destino ocupando o dobro do espaço em disco. Se você quiser preservar links físicos, adicione a opção -H/--hard-links .

O próximo problema mais provável é arquivos esparsos . Por padrão, o Rsync não grava arquivos como arquivos esparsos, mesmo que estejam na origem (não é possível dizer realmente). Se você tiver arquivos esparsos (mais comumente usados como imagens de máquinas virtuais e downloads p2p incompletos), então você vai querer usar o --sparse option .

    
por 06.11.2015 / 16:10
0

Os tamanhos dos blocos usados nos dois sistemas de arquivos são os mesmos?

Se você tiver dúvidas sobre os arquivos corrompidos, considere usar a opção (slow!) -c para rsync.

    
por 06.11.2015 / 16:30
0

Corri para esse "problema" ao usar 'du -b -d0 source destination'
como eu tinha uma lista enorme de coisas que não combinam quando eu perfurei.

O problema parece ser que du insiste em reportar o tamanho de diretórios e arquivos, e eu queria apenas o tamanho dos arquivos.

Portanto, como criar alguns diretórios usará mais bytes em alguns sistemas de arquivos e menos nos outros, você terá uma diferença.

A solução é apenas comparar os tamanhos dos arquivos reais e não os diretórios.

A linha de comando a seguir usa find para enviar apenas os arquivos no diretório de músicas e, em seguida, usa du para totalizar a contagem de bytes

find music -type f -print0 |du --files0-from=- -cb

se alguém postar um script sed para fazer a mesma coisa, faça

    
por 11.11.2018 / 19:23

Tags