Это расширениеПочему rsync пытается скопировать файл, который уже обновлен?
Я пытаюсь использовать --copy-devicesпатч, чтобы rsyncскопировать весь диск и сохранить его как образ на другой машине.
Копирование, похоже, прошло успешно, однако при rsyncповторном запуске с теми же значениями оказывается, что некоторые данные каждый раз копируются заново.
Я запустил rsyncс повышенной многословностью и получил следующее:
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
Я знаю, что rsync определяет изменения по времени, но диск не менялся между rsync (и как он вообще может определять время изменения диска?) Однако время на удаленном образе обновляется каждый раз. Так что это может быть проблемой.
Другая возможность заключается в том, что на диске есть поврежденный сектор, который каждый раз возвращает разное значение и сводит на нет любую используемую контрольную сумму.
У меня два вопроса:
Был ли мой образ успешно передан, и если да, то почему при повторном запуске возникает ощущение, что он повторно передает большую часть диска? (На этот вопрос также можно частично ответить, ответив на мой дополнительный вопросЧто такое «matches», «hash_hits» и «false_alarms» в выводе rsync, и означает ли «data=0» успех?)
Может быть, мне не хватает переключателя, чтобы это работало правильно? (Возможно
--checksum?) Возможно ли составить список сбоев на уровне блоков, используемых алгоритмом rsync?
решение1
По умолчанию rsync сравнивает файлы по размеру и временной метке, но у устройства нет размера, поэтому оно должно вычислять разницу с помощью дельта-алгоритма, который описан в этомтехнический отчет. Грубо говоря, удаленный файл делится на блоки выбранного размера, и их контрольные суммы отправляются обратно. Локальный файл аналогичным образом проверяется по блокам и сравнивается со списком. Затем удаленному файлу сообщается, как заново собрать блоки, чтобы переделать файл, и отправляются данные для несовпадающих блоков.
Вы можете увидеть это, запросив вывод отладки на уровне 3 только для алгоритма deltasum с опцией --debug=deltasum3. Вы можете указать размер блока с помощью , -Bчтобы упростить числа. Например, для файла, который уже был скопирован один раз, второй запуск
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
выводит следующий вывод, показывающий контрольную сумму для каждого блока:
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
Затем вы можете довольно легко увидеть соответствие контрольных сумм другому устройству, поскольку никаких различий нет:
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
В конце data=поле равно 0, что означает, что новые данные не были отправлены.
total: matches=164 hash_hits=164 false_alarms=0 data=0
Если теперь мы испортим копию, перезаписав середину файла:
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
затем отладка rsync показывает нам новую контрольную сумму для блока 80, но нет совпадений для него. Переходим от совпадения 79 к совпадению 81:
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
В конце мы data=100000видим, что необходимо отправить совершенно новый блок данных.
total: matches=163 hash_hits=385 false_alarms=0 data=100000
Количество совпадений было уменьшено на 1 для поврежденной контрольной суммы блока, которая не совпала. Возможно, хэш-попадания растут из-за того, что мы потеряли последовательное соответствие.
Если мы посмотримдальшев том же техническом отчете показаны некоторые результаты испытаний иложные тревоги описываются как «количество раз, когда 32-битная скользящая контрольная сумма совпала, а сильная контрольная сумма — нет». Каждый блок имеет простую контрольную сумму и контрольную сумму md5 (md4 в старых версиях). Простую контрольную сумму легко найти с помощью хэш-таблицы, поскольку она представляет собой 32-битное целое число. Как только она совпадает с записью, сравнивается также более длинная 16-байтовая контрольная сумма md5, и если она не совпадает, это ложная тревога, и поиск продолжается.
В моем примере используется очень маленькое (и старое) устройство USB-ключа на 16 Мбайт, а минимальный размер хэш-таблицы составляет 2**16, т. е. 65536 записей, так что она довольно пуста при хранении 164 записей фрагмента, которые у меня есть. Так много ложных срабатываний — это нормально и скорее показатель эффективности, чем что-либо еще.
решение2
Вы хотите рассмотреть использование, rsync --partial --inplaceа также другие ваши варианты, потому что в противном случае он сделает полную копию образа диска на стороне назначения во время работы. Я использовал -B 4096также, потому что это естественный размер сектора устройства, а размер блока rsync по умолчанию слишком мал для этого типа операции.
Чтобы перепроверить, что образ был скопирован правильно, я бы предложил провести независимую проверку sha1sumкак на стороне источника, так и на стороне назначения. Это не обязательно, но если вы хотите быть уверены, это просто, и вы можете доверять этому. Я предполагаю, что ваш исходный диск не является live-mount или чем-то подобным, в противном случае все ставки отменяются, и нет надежного способа отправить его.