Razões para o rsync NÃO transferir todos os arquivos?

Question

Alguém sabe os motivos mais comuns para uma grande diferença no número de arquivos transferidos ao fazer backup do meu diretório principal LARGE usando o rsync em uma configuração do Ubuntu 10.04 LTS? A máquina é estável e todos os volumes são limpos ext4 - sem erros de fsck.ext4.

Number of files: 4857743
Number of files transferred: 4203266

Essa é uma diferença de 654.477 arquivos !!!

Eu quero fazer backup da minha pasta base COMPLETA em um disco externo para que eu possa limpar e reformar completamente o sistema e restaurar a minha casa a partir desse backup rsync'd, mas estou preocupado com a falta de arquivos de dados significativos.

Eu estava logado como root e usei o rsync para fazer backup do meu diretório / home / hholtmann / * em uma unidade de backup sobressalente em / mnt / wd750 / c51 / home /

Aqui está a linha de comando que usei como root

root@c-00000051:~# pwd
/root
root@c-00000051:~# rsync -ah --progress --stats /home/hholtmann /mnt/wd750/c51/home/ -v

Saída resumida capturada do rsync

Number of files: 4857743
Number of files transferred: 4203266
Total file size: 487.41G bytes
Total transferred file size: 487.41G bytes
Literal data: 487.41G bytes
Matched data: 0 bytes
File list size: 102.48M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 487.75G
Total bytes received: 82.42M

Apenas para comparar um importante sub-diretório do projeto em minha casa após o rsync:

Diferença de bytes entre uma sub-dir de origem e destino usando du

root@c-00000051:~# du -cs /home/hholtmann/proj/
18992676    /home/hholtmann/proj/
18992676    total
root@c-00000051:~# du -cs /media/wd750/c51/home/hholtmann/proj/
19006768    /mnt/wd750/c51/home/hholtmann/proj/
19006768    total

CONTUDO: NENHUMA diferença de FILE COUNT entre as mesmas sub-dirs de origem e destino

root@c-00000051:~# find /home/hholtmann/proj/ -type f -follow | wc -l
945937
root@c-00000051:~# find /mnt/wd750/c51/home/hholtmann/proj/ -type f -follow | wc -l
945937

por que tais resultados inesperados? Um arquivo é um arquivo ... especialmente no diretório inicial de um usuário!

O que estou perdendo? Ou isso é um sinal de que estou pronto para o gerenciamento!?!

SOLUÇÃO E RESPOSTA:

A resposta selecionada abaixo explica a diferença na contagem de bytes e minha expectativa incorreta dos dados de resumo do rsync. Fiquei surpreso com essa diferença de bytes, já que os dois volumes são ext4 com tamanhos de bloco padrão. Eu apenas presumi que cada arquivo ocuparia o mesmo espaço em termos de du números.

Eu encontrei alguns arquivos que NÃO foram rsync'd adicionando uma saída mais detalhada ao rsync adicionando -vv ao rsync e executando novamente.

O que eu vi foram erros do rsync informando que ele NÃO pôde gravar nenhum dos meus arquivos dir do DROPBOX no destino devido aos "atributos estendidos" nos arquivos. O rsync estava ignorando todos os meus arquivos de caminho da caixa de depósito.

Termina o meu volume / home foi montado com a opção user_xattr ext4 mount no arquivo / etc / fstab:

/dev/mapper/vg1-lv_home /home   ext4 nobarrier,noatime,user_xattr 0 2
# I HAD to add the ,user_xattr option to match my home volume
/dev/sda1           /mnt/wd750  ext4 nobarrier,noatime,user_xattr 0 2

Depois de executar outro rsync completo pela terceira vez, decidi permitir que uma contagem de arquivos fosse executada toda a noite em minha pasta de início completa e backup rsync'd:

root@c-00000051:~# find /home/hholtmann/ -type f | wc -l
4203266
root@c-00000051:~# find /mnt/wd750/c51/home/hholtmann/ -type f | wc -l
4203266

** UMA PERFEITA CORRESPONDÊNCIA DE ARQUIVOS **

CONCLUSÃO:

** Sempre garanta que seus volumes de backup sejam montados com as mesmas opções de montagem do sistema de arquivos que a fonte E ative o log completo com o rsync para análise posterior do grep para procurar erros em longas listagens de arquivos! **

    

Answer 1

Existem 2 partes para esta questão. Primeiro, por que há uma diferença entre "Número de arquivos" e "Número de arquivos transferidos". Isso é explicado na página de manual do rsync:

Number of files: is the count of all "files" (in the generic sense), which includes directories, symlinks, etc.

Number of files transferred: is the count of normal files that were updated via rsync’s delta-transfer algorithm, which does not include created dirs, symlinks, etc.

A diferença aqui deve ser igual à quantidade total de diretórios, links simbólicos, outros arquivos especiais. Aqueles não foram "transferidos", mas apenas recriados.

Agora, para a segunda parte, por que há uma diferença de tamanho com du. du mostra a quantidade de espaço em disco usada por um arquivo, não o tamanho do arquivo. O mesmo arquivo pode ocupar uma quantidade diferente de espaço em disco, se, por exemplo, os blocos de sistemas de arquivos diferirem.

Se você ainda está preocupado com a integridade dos dados, uma maneira fácil de ter certeza é criar hashes para todos os seus arquivos e comparar:

( cd /home/hholtmann && find . -type f -exec md5sum {} \; ) > /tmp/hholtmann.md5sum
( cd /media/wd750/c51/home/ && md5sum -c /tmp/hholtmann.md5sum )

    

Answer 2

Tente seguir, isso pode ajudá-lo,

rsync -avH --delete /home/hholtmann/ /media/wd750/c51/home

    

Answer 3

Eu poderia muito bem acrescentar algo que aprendi.

Eu estava usando o comando rsync /path/source/* /path/to/destination/* (observe o globbing). Foi estranho porque 90% dos meus arquivos foram transferidos com poucas exceções (mesmo estando na mesma pasta que alguns que foram transferidos). Depois de remover o * da origem e do destino, todos eles foram transferidos. ¯ \ _ (ツ) _ / ¯