Диагностика проблем 1С через контрольные суммы
Всем привет.
У меня на этой неделе случилась беда. На одной машине пользователя стала глючить 1с. Уже и кэши очищали, и машину перезагружали - глючит и все. Пало подозрение на повреждение самой 1с.
читать первым в телеграм читать первым в макс
Можно было бы просто переставить, и забыть. Но мне хотелось именно убедиться, что проблема на диске.
Нужно просто рекурсивно сравнить два каталога по содержимому файлов. Каталог со старой установкой переименовал, поставил заново и начал сравнивать.
Проще всего это сделать с помощью rsync:
rsync -ncrv /old1c /1c
-n (–dry-run) — только тестирование
-c (–checksum) — по содержимому
-r (–recursive) — рекурсивно
-v (–verbose) — подробности
Вот только ставить на клиентскую машину rsync ради одного сравнения, так себе идея. Да и если забыть ключик -n, можно убить данные. Решил сделать все костылями:
find /old1c /1c -type f -printf "%f " -exec md5sum {} \; |
awk '{print $2,$1}'|sort |uniq -c|awk '$1%2'
-type f — только файлы
-printf "%f " — печатаем basename
-exec md5sum {} \; — для каждого файла вычисляем md5
|awk '{print $2,$1}' — сначала md5, потом файл (не принципиально, но красивее)
|sort |uniq -c — на первой позиции - число уникальных записей. Без sort uniq не работает.
|awk '$1%2' — печатаем только строки, с нечетным числом записей.
В общем, как я и предполагал, нашлись файлы с разной контрольной суммой. Значит повреждение было на диске. Ну, и после переустановки 1с, проблема ушла.
На самом деле проблема не такая редкая. Дело в дисках. Есть такая характеристика как Неисправимых ошибок чтения/прочитанных бит.
Например, на wd blue 1E-14, на wd gold 1E-15, на SSD Micron 7450 MAX 1e-17. То есть серверный ssd в 1000 раз надежней, чем бюджетный hdd. Просто не всегда эти ошибки одинаково заметны.
Кстати, rsync работает значительно быстрее. Если данных много — используйте его.
Всем работы без багов.