md5deep

Есть такое готовое, чтобы не скриптосипедить?

тут скриптосипедствования на час работы

Я думаю, даже минут на 15 со всеми тестами. Но лень же, если такое уже есть готовое.

rsync может сравнивать чексуммы если есть две копии данных

tripwire?

AIDE. Знаю, что не совсем то, что нужно, но задачу выполняет.

Оно же всё?

Возможно ещё http://o-security.sourceforge.net/ подойдёт, хотя он немного для других целей.

btrfs, zfs, raid6

https://attic-backup.org/

Не нашёл, как вывести список изменившихся файлов, зато если файлы не меняются, следующие бекапы почти ничего весить не будут.

Может что то коцает файлы? Или они лежат себе и вдруг у некоторых не совпадают суммы?

Любой IDS. ossec, aide, samhain. Скорее всего tripwire тоже, но его пока не смотрел

Или они лежат себе и вдруг у некоторых не совпадают суммы?

Именно так. Я в Juick'е расписывал проблему подробно. Оказалось, многие с таким сталкиваются и под Linux, и под Windows. В моём случае это бывает на разном железе, с разными ФС, с разными ядрами...

Сам ищу такое решение. Крон + гит не пойдет?

monit умеет чекать файлы и директории на изменения.

Напоминает... Два изначально идентичных файла отличаются одним битом (обнаружилась сбоящая память)

+md5deep
Можешь подробнее рассказать про свое железо (amd/intel), вендоры материнок, хардов, памяти, используемые fs/рейды и т.п. ?

обнаружилась сбоящая память

Железо менялось неоднократно (этому явлению не меньше 10 лет). Кроме того, там сейчас масса очень тяжёлых и критичных до памяти процессов (один MySQL жрёт 8Гб RSS и отдаёт по 500+ запросов в секунду) — и никаких проблем. Так что дело не в железе и об этом я в первую очередь думал.

Можешь подробнее рассказать про свое железо (amd/intel)

Начиналось (когда стал первые сбои замечать, но не факт, что их не было ранее) это всё с Celeron 1700 на, кажется, Asus P4P800, PATA-хардов россыпью, в основном Samsung SpinPoint 80G и т.п. Сейчас через серию апгрейдов стоит Asus P8H77 (а в процессе апгрейда была пара MSI, не Асусом единым :)), i5-2500K, винты WD 4T+3T+1T.

ФС, на которых были потери — xfs и ext4. На других (активно использовал одно время reiserfs, до этого — ntfs) — не сталкивался. Но, судя по комментариям в Juick'е и у меня на форуме, народ с подобным сталкивался на любых ФС.

С 2007-го все системы, где есть потери под LVM. Но сбои наблюдал и раньше. Гарантированно помню — с ~2005-го (обнаружил первый раз повреждение свежей, уникальной и невосполнимой фотки).

Общего в этом всём — только использование Gentoo. Но за 10 лет менялось всё — и версии ядра, и опции сборки (от навороченных когда-то до нынешних дефолтовых), и даже сама система менялась однажды целиком.

...

В общем, закономерности не наблюдаю, а с учётом того, сколь многие, оказывается, сталкивались с этим, похоже, это что-то достаточно фундаментальное.

Я просканировал ночью домашний фотоархив с помощью jpeginfo -c (странно, что раньше руки не доходили) и на 74 тыс. фотографий архива обнаружил 657 сбоев. Из них 563 случая обнуления файлов (это может объясняться тем, что архив несколько лет жил на XFS и не самым благоприятным электропитанием, без ИБП) и 94 случая повреждения данных во внешне целом файле. Как раз, тот случай, про который говорю. Архиву около 12 лет. Если считать, что его объём рос примерно линейно и среднее время хранения в нём файла составляет 74000/2*12 = 444 тыс. «файлолет», то один сбой приходится, в среднем, на 4700 «файлолет» хранения.

Если средний размер файла считать за 2Мб, то, в среднем, 1Мб данных повреждается за 9400 лет хранения. В видеоколлекции на 1Тб размером таким образом каждый год должно накапливаться около 100 сбоев. Вот тут встречно проверить точность оценки не могу. На хранящихся файлах сбои так просто не заметить, ну, мелькнёт в процессе воспроизведения сбойный блок, так они иногда и на свежевыкаченных 100% файлах бывают. А при пересчёте хешей раздач сбои (когда 100% закачки превращаются в «99.98%») встречаются не редко, но нет данных для статистики за какой период и т.п.

Крон + гит не пойдет?

git сдохнет на 600Гб архиве :)

Сбой в 1Мб на (округлённо) 10 тыс. лет хранения, скорее намекает, всё же, на какую-то статистическую ошибку. Очень похоже на физический сбой в самом носителе, на блине HDD. Но тогда непонятно, какого фига он не возвращает современный аналог пресловутого досовского (R)etry/(A)bort/(I)gnore... Контрольная же сумма блока не должна совпадать при чтении.

...

На форуме товарищ пишет:

Обнаружил что некоторые (выборка мала) видео из архива «квадратят». Кое что я перед закладкой перекодировал, видеоадаптер менял, да и систему недавно пришлось переустанавливать. Однако есть и файлы которые почти точно не перекодировал. Грехи видеоадаптера и переуствноыки системы (косо поставленные кодеки и драйверы) проверил отнеся один из файлов на работу - так же «квадратит» (но, это не отсеяло варианта «перекодировал и не посмотрел, что получилось»). Что-то я насторожился. Будем потихоньку исследовать вопрос.

Кажется, докопался до причин.

Я недавно (25 июля) переносил данные со старого на новый HDD (выводил из LVM 2Тб с дохнущей механикой в пользу нового 4Тб). Но считал, что бэкап, в котором цел ряд файлов, повреждённых сейчас в основной копии, делал уже после этого переноса. Поднял форумные архивы (хорошо, когда сам для себя такие отчёты пишешь :D), оказалось, я бэкап через btsync делал аж за месяц до переноса, процесс начался 27 июня и занимал несколько дней.

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

o_0 Мать моя женщина, с закачками тоже наблюдал, удивлялся, списывал на кторрент...
Если я правильно понимаю:
1. это все без рейдов ?
2. p,q,z чипсетов не было ?
Перечисленное железо, не фонтан, но не настолько же.
А вендоры памяти какие ?
Пожалуй, тоже начну статистику собирать.

это все без рейдов ?

Да. Но в последние 7 лет — с LVM

p,q,z чипсетов не было ?

P4P800, P8Z77.

А вендоры памяти какие ?

В последние годы в основном Kingston.

Но, вообще, обращаю внимание на Сканер изменений в содержимом файлов, атрибуты которых не менялись. (комментарий) — похоже, проблемы именно при копировании вылезают. Так что теперь придётся брать за практику постоянные проверки после копирований. И хорошо, когда это просто cp, а что делать с pvmove? Только с бэкапом сверять :)

...

Забавно — я сегодня начал разгребать древний винт соседа, которому комп новый собирают. Винт - WD на 750Гб. На каком железе работал — х.з. Стал паковать фотки в .tar.gz (мало, мегабайт 600) получил с десяток предупреждений (дословно не помню) «файл усечён, дополнен нулями». Это, часом, не подобная же фигня под виндой и NTFS?

Тоже наблюдал такое (битые фотографии). Но это после нештатного выключения, да и вообще у меня три уровня абстракции до и после фс. После этого вроде не повторялось. Приеду домой, еще раз проверю jpeginfo.

Про LVM понятно, непонятно обеспечивается ли у тебя отказоустойчивость по дискам и если да, то как (поверх mdadm'a ли, например, LVM, или контроллеры какие).
У меня пока с мультимедией на одиночных дисках только проблемы наблюдались, при копировании больших qcow2 (сотни гиг) пока md5 сходились, но все на рейдах и я не доверяю LVM.

Стал паковать фотки в .tar.gz ... Это, часом, не подобная же фигня под виндой и NTFS?

Или проблемы реализации тара. Под виндами он странный какой-то порой. Попробуй в какой-нить .7z пожать.
С другой стороны, а куда они денутся, если проблема в дисках (например, легко может быть некая комбинация намагниченных доменов на блине, которая читается хуже, нежели другие, или сочетание таких комбинаций на соседних цилиндрах - вот и будут вылезать архивы типа м/жпегов), ну и стандартные износ, размагничивание, неточное позиционирование, скачки напряжения где попало, частицы... Блин, посчитать все - странно что оно вообще работает.
А ведь еще и интерфейс хотят упростить, контрольные суммы из протокола убрать собрались, пипец будет.

Народ, а шустрее md5deep никто ничего не знает ?

Или проблемы реализации тара. Под виндами он странный какой-то порой.

Я под Ubuntu паковал :)

например, легко может быть некая комбинация намагниченных доменов на блине, которая читается хуже, нежели другие

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

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

Не факт, голова диска тупо вернула кривую (заряд ячейки вернул какой-то уровень), оцифровали, что-то получили, а откуда мы знаем что там должно было быть ? Ошибку разве что CRC выловит, надо вспоминать где по дороге чтения (и записи) контроль CRC есть, а где его нет, да и он не панацея - еще же и коллизии есть, когда оно сойдется при изменении данных. Может быть сбой и самого механизма проверки CRC, ошибочно возвращающий совпадение суммы, когда его нет, например, если в контроллере бит результата перевернется или алгоритм залип и вообще подтверждает всё неглядя (кстати, ведь хрен определишь, работает оно вообще или нет - моя статистика по памяти с/без ЕСС, мягко говоря неоднозначна). Порча данных уже после их проверки и тп.
Хм, интересно, если пересчитать сумму какого-нибудь 4TБ с кучей данных дохера раз, сколько раз получатся разные цифры. Че-то сомневаюсь чтобы это кто-то проверял.

а откуда мы знаем что там должно было быть ? Ошибку разве что CRC выловит

Именно. У каждого блока есть контрольная сумма.

да и он не панацея - еще же и коллизии есть

Есть. Но вероятность произведения ошибки чтения на вероятность коллизии, ИМХО, таки, принципиально меньше ошибки сбоя уже успешно прочитанных данных где-нибудь в тракте контроллер-шина-контроллер-память-контроллер-шина-контроллер.

Хм, интересно, если пересчитать сумму какого-нибудь 4TБ с кучей данных дохера раз, сколько раз получатся разные цифры.

Да, интересно посмотреть.

Именно. У каждого блока есть контрольная сумма.

И не меньше мест, где это не поможет.

Есть. Но вероятность произведения ошибки чтения на вероятность коллизии, ИМХО, таки, принципиально меньше ошибки сбоя уже успешно прочитанных данных где-нибудь в тракте контроллер-шина-контроллер-память-контроллер-шина-контроллер.

А прикинь частица через них все и пролетит ? :) Путь у данных неблизкий, тут имхо не перемножать, а складывать надо - общее воздействие на систему (рад.фон/наводки, вибрация/дребезг контакотв/частица же тоже не одна летает), в одном месте тракта вибрации не влияют, а в другом уже да, с фоном - наборот, частицы вообще не по расписанию, а тут еще руки вверх включили, и еще что-то записывают на соседний диск и в сталкера играют. :) Я бы не взялся точно оценить что с магнитного домена до пикселя на экране дойдет. Я бы сказал что велика вероятность, что мы увидим значение этого домена, поскольку приложили значительное число усилий по недопущению иных значений. :)

Я боюсь по результатам этого эксперимента мы увидим число различных значений больше чем хотелось бы увидеть. Собственно это и есть та проблема, которую ты поднял.

mtree

На FreeBSD есть программа, регистрирующая изменения файловой иерархии и содержимого файлов — mtree. Она способна делать сравнения полученных «спецификаций» одной и той же файловой иерархии и показывать различия в элементах (размере, контрольных суммах, атрибутах и т.д.).

1. Делаем контрольный снимок:

% mtree -x -ic -K cksum -K md5digest -K sha256digest -p /usr/local/bin/ > /root/mtree1.out

% mtree -x -ic -K cksum -K md5digest -K sha256digest -p /usr/local/bin/ > /root/mtree2.out

% mtree -f /root/mtree1.out -f /root/mtree2.out > /root/mtree.difference

Пример лога сравнения после того, как были пересобраны пакеты cmake, питоновские дополнения и несколько других:

% cat /root/mtree.difference
	ccmake file cksum=1878989250 gid=0 mode=755 nlink=1 size=4261284 uid=0 md5digest=0d172f5068026f8f7fac8ca4236e30ad sha256digest=3e5af198e06cb7b94b94f812727f14eb59a7389900e7a21ad685520d1dfff87a flags=uarch
	cmake file cksum=1996047418 gid=0 mode=755 nlink=1 size=4222941 uid=0 md5digest=935440d42083fed8eb6f990a25c425d4 sha256digest=307c8112cd28880674e3bda08bf855b614eb6c487e7bf3d5f2b3dc70425a8eeb flags=uarch
	cpack file cksum=1231143217 gid=0 mode=755 nlink=1 size=4477050 uid=0 md5digest=f9f2c8c1b67b3f8495308fbeb009ad7d sha256digest=02b51df4b51923702d4f3f846d865bf34ad4a99a13dafa5828e12468738f5ecd flags=uarch
	ctest file cksum=126619143 gid=0 mode=755 nlink=1 size=5346129 uid=0 md5digest=e92da38aea8abcd8ce32d530bd9af7fe sha256digest=635cfeee48592664993cba8973a5e470d6e9e4e79ae5881f3c525fb334a39623 flags=uarch
	pybabel file cksum=2658765465 gid=0 mode=755 nlink=1 size=298 uid=0 md5digest=25cbda53271748f38db261eb238130c3 sha256digest=8390af40b020cfc9bdd49f2e0d77da1b717603d0d87a340d884728cdf57afa65 flags=uarch
	pygmentize file cksum=358235165 gid=0 mode=755 nlink=1 size=313 uid=0 md5digest=594691da33a658883f01e380d6488ae1 sha256digest=ce8ee6517a3bb77d56b66a8194794b9a15e2f00e3ef8e4137a083a7fab9dc829 flags=uarch
		slim file cksum=76175764 md5digest=f610875a6c682695c014cb762833492e sha256digest=7d07138fa72dfd4540b58ebfa56fd86b751ea1962622b2afe673d152506a0e3d
		slim file cksum=4122065990 md5digest=30ec93bd04a9536fefb5cb80c8cfdafe sha256digest=2d7278150ff00563389ce6d7e974761915b38bc27959481a07a5ca6959dd7f81
	sphinx-apidoc file cksum=228715259 gid=0 mode=755 nlink=1 size=319 uid=0 md5digest=d0b5357b448685ba1414f4eb541318ea sha256digest=e5ac4faac1a32545dfb4252a452805490eb68c02bc6e4f0aa42ffe6741174afb flags=uarch
	sphinx-autogen file cksum=3728146398 gid=0 mode=755 nlink=1 size=321 uid=0 md5digest=053bbb62d2f456a86237b586cc0e4f51 sha256digest=0eae2223400e2054229cd0abc633e93464c008ff8e72a77938b84139573026de flags=uarch
	sphinx-build file cksum=3157256149 gid=0 mode=755 nlink=1 size=317 uid=0 md5digest=59c53eeefd4b5de1257e6901bd93b113 sha256digest=c9fb813afd4e8217e052fcc1ac6d74e302e476468e3bfe593291c85f00b9c406 flags=uarch
	sphinx-quickstart file cksum=1885720249 gid=0 mode=755 nlink=1 size=327 uid=0 md5digest=a0aefd31830478cd3f7073791247cd5d sha256digest=ecdb8bb66c85e1d7440a9ddd7c07caa17e0e5a2ea3b0b2709f4ca6486fc99190 flags=uarch
		. dir
		. dir

Прошло полтора года. За это время полностью переехал с Gentoo на Ubuntu. Железо итак менял со времени первых ошибок. Т.е. не осталось уже ничего общего. И, на тебе, только скрипт обнаружил ещё одну ошибку в фотке, совсем свежей, от июня.

Так что, либо это ошибка в современном железе вообще, либо в ядрах Linux за, как минимум, несколько последних лет.

Дядь. Вы опытный человек. ЕМНИП у вас и муська крутиться и туча контейнеров, и вроде же все живое? Смотрите на железки/софт(т.е. чем заливаете), вот реально ядра тут не причем. «Миллионы мух» не могут ошибаться. Представьте себе «несколько измененных байтиков» в живой БД, это же краньтец.

Смотрите на железки/софт

Всё менялось за последние годы. Мать/процессор, память, винты... Gentoo на Ubuntu.

«Миллионы мух» не могут ошибаться

Жалоб на потери, на самом деле, в моих темах (этой и в Juick) было. Особенно часто это заметно на пересчёте хешей торрентов. У некоторых нет-нет, да окажется после пересчёта, что торрент готов на что-то типа 99.8%.

Вон, чуть выше:

Мать моя женщина, с закачками тоже наблюдал, удивлялся, списывал на кторрент...

Ну и до кучи:

фотки ополовиненные иногда попадаются, я всегда думал что они где то в другом месте портятся, на флешках своих фотоаппаратных или типа того

нет-нет, да попадётся раз в несколько месяцев «закачано на 99.8%»

однако ж натыкался на такое не раз, но грешил на старенький хард

эффект «99.8%» с торрентами вполне себе наблюдается и под Windows

Тож наблюдал подобный торрент и под фат32 под виндами и на райзерФС в лине.

...

Вообще, я прошлый раз оценивал грубо, получается что-то около одной ошибки на 1Мб на 10000 лет хранения. Или, соответственно, одна ошибка на 10Гб за год хранения.

С трудом верится что такие сбои возможны - это в багрепорты не помешает сообщить.

Статистика экстраполируется на обычное хранение данных и как-то настораживает, но за все время эксплуатации ни разу не наблюдал сбойных файлов. Может что-то есть такое ообенное, что является причиной сбоев или что-то делается не так. Словом икс фактор.

это в багрепорты не помешает сообщить

Вот только — в чьи? :)

Совсем тупое предположение, но: Может вы харды «соответствующие» покупаете? Или любите «проводочки на карандаш наматывать»?
Нет ну реально, тонны БД и других бинарных хранилищ работают, а вы тут один в белом с фотками. Что-то не сходиться с такой математике.

Так или иначе это в конечном итоге фс, а это модули ядра. Если конечно не пишешь прямо с фотоаппарата или с глючного девайса или размонтирование некорректное или какой-то сторонний софт гадит.

Кстати, т.е. получается после смены генты на убунту, проблемы не ушли?

Это случаем не ssd?

Это не lvm?

ext4 считается довольно надежной фс, но были проблемы с ней в начале эксплуатации при определенных условиях - но это было давно в период активной миграции на ext4 и после 1-2 лет спустя вроде ...

Может вы харды «соответствующие» покупаете?

Первые проблемы встречал на Samsung Spinpoint. Сейчас в основном WD Red. Были сбои на WD Green.

Нет ну реально, тонны БД и других бинарных хранилищ работают

Так у меня тоже :) Но одиночный сбой раз в год-два в текстовой таблице MySQL на 5-10Гб (мой типичный объём) ещё пойди заметь... А вот в контролируемых целостностью сотнях гигабайт фото и терабайтах видео заметить ошибку уже проще... И, как отмечал выше, такое не один я замечал. Просто народ обычно такие редкие ошибки игнорирует, считая какой-то частной единичной проблемой.

Кстати, т.е. получается после смены генты на убунту, проблемы не ушли?

Да, была у меня мысль, что это может быть связано с Gentoo (хотя народ с подобным сталкивался и в других системах), но вижу ошибки это на Ubuntu :)

Это случаем не ssd?

Нет. SSD пока имеют слишком малые объёмы, чтобы заметить такие редкие ошибки.

Это не lvm?

Вот это был самый главный подозреваемый. Но на этот раз я ошибку обнаружил на машине без LVM (и с зеркалом mdadm).

ext4 считается довольно надежной фс, но были проблемы с ней в начале эксплуатации

Хотя сбои в фотках у меня на ext4, но вот торренты (и, соответственно, сбои в них) у меня все на xfs.

Samsung Spinpoint

Не очем

Сейчас в основном WD Red

Red != RE т.е. не айс

WD Green.

ну тут надеюсь мысль понятна? :)
Итого: склоняюсь к железу. И повторю «миллионы мух не могут ошибаться» У меня бы уже куча БД упала если бы такое было. Хотяяяя вот вспомнил случай меньше чем годовой давности, действительно был сбой по системе, хз какие файлы изменились, просто развернул из бэкапа перезаписав повех существующей из tar архива. Но там все на территории заказчика и в виртуалке vmware которая на блэйде крутиться, так что хз может и в железе была проблема но мне так и не сообщили.

Да с лвм как-то диссонансно. Только недавно захотелось перейти на него (пока не rootfs/bootfs) - и хочется и колется ...

Лучше расскажи , как копируешь фотки и откуда, чем еще обрабатываешь во время или после копирования.

Лучше расскажи , как копируешь фотки и откуда, чем еще обрабатываешь во время или после копирования.

Фотки раньше сливались просто с флешки на HDD на домашнем сервере по SMB или NFS и потом так и лежали годами. Переименования, понятно. Мувы в пределах раздела, т.е. то же самое переименование. Обработка недеструктивная, но при правке EXIF/XMP, конечно, перезапись файла происходит.

Сейчас чаще всего сливаю на десктоп, с него свежие фотки синкаются по Syncthing с «большим» архивом на домашнем сервере, а оттуда (точнее, в т.ч. и прямо с домашней машины, т.к. p2p) на внешний сервер и, частично, срезами, на несколько рабочих машин (ноут, офисный комп...).

Ошибки встречались и раньше, при прямой записи. Сейчас, вот, ошибка нашлась на внешнем сервере (при чём раньше её не было).

В случае с торрентами всё куда проще — обычный Transmission на сервере, как качает, так потом и лежит... В коллекции около 600 файлов объёмом под 2Тб. При редких, раз в несколько месяцев пересканированиях штук 5-6-7 файлов оказывается «чуть-чуть недокаченными». Я из-за этого даже файлы с раздачи перестал снимать, т.к. восстанавливать файлы просто и контролировать целостность :)

рискованных узлов хватает, особенно когда перезапись и синхронизация

рискованных узлов хватает, особенно когда перезапись и синхронизация

Ага. Поэтому я указал и про ошибки в те времена, когда лил сразу с флешки на HDD, и сегодняшнюю практику с торрентами, где рискованных узлов нет :)

одна ошибка на 10Гб за год хранения

В ЦЕРНе приблизительно такая же частота ошибок дисков:

https://en.wikipedia.org/wiki/Data_corruption#Silent_data_corruption

study, performed by CERN over six months and involving about 97 petabytes of data, found that about 128 megabytes of data became permanently corrupted

Что-то около байта в гигабайте за год

Значит, ещё одно свидетельство в пользу того, что явление не исключительное, а обыденное, но просто большинство не обращает на него внимания из-за относительной редкости.