Различные цифры свободного места на диске в выводе df после полной передачи rsync -Sap

2 гигабайта пропущенных данных - это значимо. Если бы размер увеличился на 2 Гб, то этому было бы несколько простых объяснений: жесткие ссылки превратились в повторяющиеся файлы, файлы с дырами превратились в полностью заполненные файлы и так далее. Это вполне разумные объяснения.

Однако, поскольку новый размер меньше, вам следует сравнить, что изменилось. Вы же не хотите оказаться в ситуации, когда через 5 месяцев вы поймете, что что-то не так и у вас нет действующей резервной копии.

Резервные копии не важны. Реставрации важны. Мы не знаем, сработает ли восстановление, пока не проверим резервную копию.

Для небольшого количества файлов вы можете сделать diff -r /mnt/RAIDVault /mnt/RAIDVault-BACKUP. Однако, если это остановится на полпути, его нельзя будет перезапустить с того места, где он остановился.

Для большого количества файлов рекомендую вычислять хеши всех файлов и искать отличия. Таким образом, если процесс остановится или прервется, вы сможете продолжить без особого труда.

Вот программа, которая будет генерировать md5-хэши всех файлов в каталоге:

#!/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;
}

Вы можете использовать это так:

# 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

Мне было бы интересно узнать, какую разницу вы найдете!

На странице часто задаваемых вопросов по rsync можно найти хороший и подробный ответ по адресу https://sanitarium.net/rsyncfaq/#differentsizes

Существует несколько причин, по которым источник и цель могут иметь разные размеры:

• исключает
• размер каталога из-за различного распределения дискового пространства (по дизайну и в результате целевой или исходный только немного меньше)
• жесткие ссылки (разница 1-10%)
• разреженные файлы (разница> 10%)
• различия в типах файловых систем, размерах блоков, накладных расходах файлов и т. д.
• df использует двоичные единицы (степень 2), в то время как rsync использует десятичные единицы (степень 1000)
• наконец, сравнение исходных и целевых размеров не всегда надежно, и, следовательно, проверка контрольной суммы в файлах является гораздо лучшей мерой того, идентичны ли исходный и целевой размеры или нет.

В последний раз, когда я видел эту ситуацию, целевая копия находилась в файловой системе с нечувствительными к регистру именами файлов. У мастера были файлы с именем foo и FOO. Место назначения считает, что эти имена файлов совпадают, поэтому процесс резервного копирования скопировал foo к foo, затем он скопировал FOO к foo. Таким образом, мы потеряли оригинал foo. Так мы потеряли много файлов.