Сравните контрольную сумму файлов между двумя серверами и несоответствие отчета - PullRequest
0 голосов
/ 28 апреля 2018

Я должен сравнить контрольную сумму всех файлов в папках /primary и /secondary в machineA с файлами в этой папке /bat/snap/, которая находится на удаленном сервере machineB. На удаленном сервере будет много файлов вместе с файлами, которые у нас есть в machineA.

  • Если в контрольной сумме есть какое-либо несоответствие, я хочу сообщить обо всех файлах, имеющих проблемы в machineA, с полным путем и завершить работу с ненулевым кодом состояния.
  • Если все совпадает, выйдите из нуля.

Я написал одну команду (не уверен, есть ли лучший способ написать ее), что я работаю на machineA, но она очень медленная. Есть ли способ сделать это быстрее?

(cd /primary && find . -type f -exec md5sum {} +; cd /secondary && find . -type f -exec md5sum {} +) | ssh machineB '(cd /bat/snap/ && md5sum -c)'

Также распечатывает имя файла, как это ./abc_monthly_1536_proc_7.data: OK. Есть ли способ, которым он может распечатать полный путь к этому файлу в machineA?

ssh для удаленного хоста для каждого файла определенно не очень эффективен. parallel может ускорить его, выполняя его одновременно для большего количества файлов, но более эффективный способ, вероятно, немного подправит команду, чтобы она передавала ssh на machineB и получала всю сумму md5 за один раз. Возможно ли это сделать?

Ответы [ 4 ]

0 голосов
/ 08 августа 2018

Вы можете попытаться распараллелить процесс, упомянутый в другом ответе. измените + на \; выполните bash с помощью &.

find $(pwd) -type f -exec bash -c "md5sum '{}' &" \; 
0 голосов
/ 03 мая 2018

Используя md5sum, вы можете попросить его проверить файлы по входному md5sum файлу.

man md5sum: полезны следующие две опции:

  • -c, --check: прочитать суммы MD5 из ФАЙЛОВ и проверить их
  • --quiet: не печатать ОК для каждого успешно подтвержденного файла

Так что все, что нам нужно сделать, это создать такой файл и передать его. Самым простым является следующее (из machineA):

$ cd /primary; md5sum * | ssh machineB '(cd /bat/snap; md5sum -c - --quiet 2>/dev/null)`
$ cd /secondary; md5sum * | ssh machineB '(cd /bat/snap; md5sum -c - --quiet 2>/dev/null)`

Это будет сообщать о вещах как:

file1: FAILED
file2: FAILED open or read

Это даст вам все сбойные файлы для каждого каталога. Позже вы можете выполнить любую последующую обработку с любым ароматом awk.

0 голосов
/ 20 мая 2018

Если вашей основной целью является не подсчет контрольных сумм, а перечисление различий, возможно, более быстрый (и более простой) способ - запустить rsync с опцией --dry-run. Если какие-либо файлы перечислены, они отличаются, например:

MBP:~ jhartman$ rsync -avr --dry-run rsync-test 192.168.1.100:/tmp/; echo $?
building file list ... done
rsync-test/file1.txt

sent 172 bytes  received 26 bytes  396.00 bytes/sec
total size is 90  speedup is 0.45

Конечно, из-за --dry-run файлы не изменились на цели.

Надеюсь, это поможет, Jarek

0 голосов
/ 30 апреля 2018

Если файлы в директории /primary и /secondary вместо в этих каталогах, потеряйте поиск. Вы также можете распараллелить вычисление md5. Так что это сделало бы это:

#!/bin/bash
cd /primary
md5sum * > /tmp/file-p &
cd /secondary
md5sum * > /tmp/file-s &
wait
cat  /tmp/file-p /tmp/file-s | ssh machineB '(cd /bat/snap/ && md5sum -c)'

При относительно небольшом наборе файлов:

$ time find . -exec md5sum {} \;
7e74a9f865a91c5b56b5cab9709f1f36  ./file
631f01c98ff2016971fb1ea22be3c2cf  ./hosts
d41d8cd98f00b204e9800998ecf8427e  ./fortune8547
49d05af711e2d473f12375d720fb0a92  ./vboxdrv-Module.symvers
bf4b1d740f7151dea0f42f5e9e2b0c34  ./tmpavG1pB
a9b0d3af1b80a46b92dfe1ce56b2e85c  ./in.clean.4524

real    0m0.046s
user    0m0.035s
sys 0m0.006s
$ time md5sum *
7e74a9f865a91c5b56b5cab9709f1f36  file
d41d8cd98f00b204e9800998ecf8427e  fortune8547
631f01c98ff2016971fb1ea22be3c2cf  hosts
a9b0d3af1b80a46b92dfe1ce56b2e85c  in.clean.4524
bf4b1d740f7151dea0f42f5e9e2b0c34  tmpavG1pB
49d05af711e2d473f12375d720fb0a92  vboxdrv-Module.symvers

real    0m0.005s
user    0m0.003s
sys 0m0.002s

(просто чтобы доказать, что поиск не всегда самый быстрый).

...