Fazemos backup de um conjunto de máquinas virtuais para uma unidade USB externa usando rsync -a . O diretório de origem é 145G, conforme relatado por du -sh , mas o alvo está relatando 181G.
Os dois sistemas de arquivos são ext3 e o tamanho do bloco é o mesmo, alguém pode explicar qual é a discrepância?
Como Dennis mencionou, parece ser um problema de arquivo esparso. Um exemplo disso pode ser:
$ dd if=/dev/zero of=sparse.txt count=0 seek=1000
0+0 records in
$ du sparse.txt
0 sparse.txt
$ ls -l sparse.txt
-rw-r--r-- 1 user user 512000 2010-03-22 11:54 sparse.txt
Como você pode ver, du informa quantos blocos são realmente usados, enquanto ls mostra o tamanho do arquivo.
-S, --sparse
Try to handle sparse files efficiently so they take up less
space on the destination. Conflicts with --inplace because it's
not possible to overwrite data in a sparse fashion.
NOTE: Don't use this option when the destination is a Solaris
“tmpfs” filesystem. It doesn't seem to handle seeks over null
regions correctly and ends up corrupting the files.
Outros já informaram sobre arquivos esparsos, mas há outra coisa: links físicos. Hard links - vários nomes para o arquivo (e espaço no disco) são freqüentemente usados em partições do sistema (por exemplo, para múltiplos comandos shell implementados no mesmo binário) e não são tratados especialmente pelo rsync com a opção '-a' apenas. Então, por exemplo um arquivo com quatro links físicos será armazenado em quatro arquivos separados.
Tente usar rsync -aH .
Com o script rsync, você está excluindo os itens existentes no destino e não estão mais no destino? Se você quer ter uma cópia idêntica em ambos os lados, você precisaria de um sinalizador "--delete" em sua rotina de rsync.
"rsync -a --delete /source/ /destination/"
Você também pode inserir "-n e -P" na string para fornecer um indicador de execução a seco e de progresso, respectivamente, para mostrar o que aconteceria com a opção "--delete".
Tags rsync