Diferentes figuras de espaço livre em disco na saída df após rsync completo - Transferência de segurança

Question

Eu fiz "rsync -Sap - ids numéricos --delete-during / mnt / RAIDVault / / mnt / RAIDVault-BACKUP /" pretendendo trazer duas unidades de armazenamento em sincronia (com conteúdo idêntico), mas acabou com diferentes quantidade de espaço livre em disco nos dois:

/dev/md1 2.0T 2.0T 81G 96% /mnt/RAIDVault /dev/md0 2.0T 2.0T 79G 97% /mnt/RAIDVault-BACKUP /dev/md1 1951405544 1873160540 78245004 96% /mnt/RAIDVault /dev/md0 1951405544 1874906476 76499068 97% /mnt/RAIDVault-BACKUP

Estou coçando a cabeça porque não sei por que isso acontece nem por onde começar a solução de problemas. Não houve erros, rsync completou uma transferência muito bem, tudo parece bem e "uptodate".

Ainda assim, o / dev / md0 é 2 gigabytes a menos após o que deveria ser uma transferência "espelho A para B".

A saída do df foi produzida com "df --sync". Eu acho que é uma figura confiável. df nunca mente, não é?

Uma distinção importante entre / dev / md0 e / dev / md1 é que, embora ambos sejam do tipo raid1, o software raid / dev / md0 tem atualmente apenas 1 membro da matriz. Eu estou querendo saber se isso é o que está causando diferentes números no relatório do df?

Então, minha pergunta é dupla:

1. Por que existem figuras diferentes no relatório do df?
2. Como você pode garantir que ambos, md0 e md1, tenham cópias completas e idênticas do mesmo conteúdo?

Answer 1

Há uma boa e detalhada resposta na página de perguntas frequentes do rsync, encontrada em link

Existem vários motivos pelos quais a origem e o destino podem ter tamanhos diferentes:

• exclui
• tamanho do diretório devido à alocação de espaço em disco variável (por design e resultados em destino ou origem sendo apenas um pouco menor)
• links físicos (1 a 10% de diferença)
• arquivos esparsos (> 10% de diferença)
• diferenças nos tipos de sistema de arquivos, tamanhos de bloco, sobrecarga de arquivos, etc.
• df usa unidades binárias (potência de 2) enquanto o rsync usa unidades decimais (potência de 1000)
• Por último, a comparação dos tamanhos de origem e de destino nem sempre é confiável e, portanto, a verificação de soma de verificação nos arquivos é uma medida muito melhor de se a origem e o destino são idênticos ou não

Answer 2

2 gig de dados perdidos são significativos. Se o tamanho aumentasse em 2G, haveria algumas explicações fáceis: links rígidos transformados em arquivos duplicados, arquivos com buracos transformados em arquivos totalmente desenvolvidos e assim por diante. Essas são explicações perfeitamente razoáveis.

No entanto, como o novo tamanho é menor, você deve fazer uma comparação para ver o que mudou. Você não quer estar em uma situação onde daqui a 5 meses você percebe que algo está errado e você não tem um backup válido.

Os backups não são importantes. Restaurações são importantes. Não sabemos se uma restauração funcionará, a menos que validemos o backup.

Para um pequeno número de arquivos, você pode fazer diff -r /mnt/RAIDVault /mnt/RAIDVault-BACKUP . No entanto, se isso parar no meio do caminho, ele não poderá ser reiniciado de onde parou.

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.

Aqui está um programa que irá gerar hashes md5 de todos os arquivos em um diretório:

#!/usr/local/bin/perl

# md5tree: Output file data information for comparison

use Digest::MD5;
use File::Find ();

# Default to "." unless things are speced on the cmd line.
if ($#ARGV == -1) {
        @DIRS = ( '.' );
} else {
        @DIRS = @ARGV;
}

&File::Find::finddepth(\&wanted, @DIRS);

exit;

sub wanted {
    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) &&
    -f _ &&
    ((-s _) > 0) &&
    &doit($_, $File::Find::dir, -s _, $mode, $uid, $gid);
}

sub doit {
        my($fn, $dir, $size, $mode, $uid, $gid) = @_;

        return 0 if $fn =~ m/[\r\n]+/;

        open(FILE, "<$fn") or die "Can't open '$dir/$fn': $!";
        binmode(FILE);
        print Digest::MD5->new->addfile(*FILE)->hexdigest, "\t$size\t$uid\t$gid\t$mode\t$dir/$fn\n";

        return 0;
}

Você pode usá-lo assim:

# md5tree /mnt/RAIDVault-BACKUP >/var/tmp/list.backup
# md5tree /mnt/RAIDVault        >/var/tmp/list.orig
   # 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

Eu estaria interessado em saber que diferença você encontra!

    

Answer 3

A última vez que vi esta situação, a cópia de destino estava em um sistema de arquivos com nomes de arquivos insensíveis a maiúsculas e minúsculas. O mestre tinha arquivos chamados foo e FOO . O destino considera esses nomes de arquivos iguais, portanto, o processo de backup copiou foo para foo , depois copiou FOO para foo . Assim, perdemos o original foo . Perdemos muitos arquivos dessa maneira.