Как эффективно генерировать и проверять контрольные суммы файлов?


12

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

Каждому файлу нужна контрольная сумма? Существуют ли способы использовать существующую структуру каталогов, скажем, для проверки только узла в дереве файлов и не обязательно каждого файла в нем?


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

Ответы:


13

Самый эффективный способ использования контрольных сумм - заставить компьютер делать все это. Используйте файловую систему, такую ​​как ZFS, которая проверяет контрольные суммы (фактически она использует хеши, которые сильнее контрольной суммы) всех данных, когда они записываются, и проверяет их при каждом чтении данных. Конечно, недостатком является то, что ZFS не знает, когда удаление или перезапись файла является ошибкой и когда это нормальная операция, но поскольку ZFS использует семантику копирования при записи для всего, вы можете использовать его функцию моментального снимка, чтобы снизить риск ,

ZFS также может автоматически восстанавливать данные, которые не проходят проверку хеша, используя любую настроенную вами избыточность, будь то контроль четности в стиле raid5, зеркала дисков или дублированные копии (добавьте свойство copy = N в любую файловую систему ZFS, и в ней будут храниться N копий любых данных, которые вы пишете). Он также хранит хеши в дереве Merkle, где хеш-значение файла зависит от хеш-значений блоков, хеш-значение записи каталога зависит от хеш-значений файлов и каталогов, которые он содержит, хеш-функция файловой системы зависит по хешу корневого каталога и т. д.

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

Также не забывайте учитывать BER ваших дисков. В конце концов, это всего лишь пластины вращающейся ржавчины. Диск на уровне потребителя имеет частоту ошибок 1 неправильно прочитанный бит на каждые 10 ^ 14 прочитанных битов, что составляет 1 бит на каждые 11 терабайт, которые вы прочитали. Если у вас есть набор данных объемом 11 терабайт, и вы вычисляете хэш каждого файла в нем, вы будете неправильно вычислять одну из этих контрольных сумм и навсегда повредить один блок одного из файлов в наборе данных. Однако ZFS знает хэш каждого блока, который он записал на каждый диск в вашем пуле, и поэтому знает, какой блок был потерян. Затем он может использовать избыточность (четность, зеркала или дополнительные копии) в вашем пуле, чтобы перезаписать данные в этом блоке с правильными значениями.

Однако в комментариях Бен поднимает вопрос. ZFS не предоставляет никаких хеш-значений, которые он вычисляет для пользователя, поэтому данные, которые входят или выходят из системы ZFS, должны сопровождаться хешами. Мне нравится, как интернет-архив делает это с помощью XML-файла, который сопровождает каждый элемент в архиве. См. Https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml в качестве примера.


1
Ты подтолкнул меня на это. Я также собирался предложить систему, основанную на хэше. Хешируйте каждый файл, хешируйте хеши файлов (+ хэши sub dir) для хэша каталога и т. Д. Компромисс между CPU / IO и вероятностью ошибки. Контрольная сумма / CRC дешевая, но вероятность ошибки увеличивается с масштабом. Как и обычные хэши, но они начинаются с гораздо меньшей вероятности ошибки.
The Diamond Z

3
Даже если вы запускаете файловую систему, такую ​​как ZFS (Btrfs также имеет аналогичную функциональность, но все еще находится в тяжелой разработке и в настоящее время не считается готовой к производственному использованию), вам потребуется периодически выполнять операцию очистки, чтобы убедиться, что данные читать и сверять с контрольными суммами или хэшами. Просто вычисление контрольных сумм, а затем ничего с ними не делать, пока вам не понадобится доступ к данным, потенциально хуже, чем ничего не стоящее.
CVn

1
Да, это хороший момент. Мой последний скраб исправил 2 килобайта поврежденных данных. Это четыре блока, разбросанных по пяти дискам! Чем дольше вы переходите между чтениями определенного фрагмента данных, тем выше вероятность того, что вы накопите достаточно ошибок в одном файле, и он не сможет его восстановить.

1
Выполнение пользовательского пространства md5sum с более чем 150 ГБ данных на моем домашнем ПК заняло около 40 минут в режиме тайм-аута, просто с привязкой к вводу / выводу. При увеличении в 100 раз на потребительском оборудовании мы проверим 15 ТБ в течение трех дней . Я бы, конечно, посчитал это выполнимым даже в большом архиве с правильно выбранным интервалом.
CVn

3
ZFS вычисляет контрольные суммы для блоков, а не файлов или битовых потоков, нет? Хотя ZFS решает проблему вычислений, может показаться, что она менее контролируема человеком и не производит переносимые данные, независимо от файловой системы - что необходимо для архивов.

6

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

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

Таким образом, ваши данные, скорее всего, выживут.


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

4

Может быть, сейчас хорошее время для воспитания BagIt . Это очень простой, но мощный формат упаковки файлов, предназначенный для архивирования, долгосрочного сохранения и передачи цифровых объектов. Пользователи включают Библиотеку Конгресса и Калифорнийскую цифровую библиотеку.

Инструмент BagIt (они существуют на нескольких языках программирования) помещает ваши файлы в определенную структуру каталогов и выполняет контрольную сумму / хэширование за вас. Это все.

PS: Конечно, инструменты BagIt также могут проверять пакеты на соответствие контрольным суммам / хэшам, и вы можете добавить некоторые метаданные в пакеты. Но это так сложно, как мешки.


1

Этот ответ является комбинацией ответов @ lechlukasz и @ db48x , а также включает в себя некоторые замечания, высказанные в комментариях, а также некоторые из моих собственных мыслей.

Простой путь вперед - это комбинированный подход файловой системы и отдельных метаданных.

Используя файловую систему, которая выполняет хеширование и проверку данных на лету, например, ZFS или Btrfs (учтите, что, несмотря на значительные успехи, Btrfs не считается готовым к использованию в настоящее время), вы можете быть разумно Убедитесь, что если данные могут быть считаны с диска без ошибок операционной системы, тогда считанные данные были записаны на диск так, как это предусмотрено файловой системой. При выполнении периодических операций «очистки» все данные считываются и проверяются в соответствии с представлением файловой системы о том, каким оно должно быть.

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

Чтобы защитить от последнего, вам нужен еще один уровень защиты. Контрольная сумма или хеширование данных с точки зрения пользовательского приложения поможет защитить от многих из вышеупомянутых рисков, но их необходимо выполнять отдельно (либо как встроенное действие процесса в программном обеспечении, либо как полностью отдельный процесс).

С современным оборудованием и тем, что практично для хранения больших объемов данных (вращающиеся жесткие диски в отличие от твердотельных дисков / твердотельных накопителей), даже сложные алгоритмы хеширования, такие как SHA1, будут в значительной степени связаны с вводом / выводом, то есть скорость при котором данные хэшируются будут зависеть от скорости чтения системы хранения, а не от способности процессора компьютера вычислять хэш. Я провел эксперимент с запуском процесса хеширования MD5 в пользовательском пространстве на примерно 150 ГБ данных на том, что в 2012 году было потребительским ПК среднего уровня, и он завершился после того, как диск работал в основном без перерыва в течение примерно 40 минут. Если вы увеличите эти цифры в 100 раз, вы получите хеш MD5 из коллекции 15 ТБ примерно за три дня на том же оборудовании. Добавляя скорость передачи чтения (которая может быть легко достигнута, например,RAID 0, например, является чередованием без избыточности, обычно используется для достижения более высокой производительности чтения / записи, возможно, в сочетании с RAID 1, формирующим RAID 10 ), время до завершения может быть уменьшено для того же объема данных.

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


1

Я прошел через ответы, и хотя мне нравится идея полагаться на ZFS для обработки ошибок на уровне данных, все еще существует проблема изменения файлов, либо по ошибке, либо злонамеренно. ZFS не будет защищать вас в этом случае, и, как кто-то другой упомянул, он не даст вам «хеш», который можно просмотреть для хранения где-то еще для внешней проверки.

Существует приложение Linux под названием TripWire, которое широко использовалось для мониторинга исполняемых файлов системы, чтобы проверить, не изменились ли они после атаки. Этот проект, по-видимому, сейчас заброшен, но есть новый AIDE (Advanced Intrusion Detection Environment), который рекомендуется для ServerFault:

/server/62539/tripwire-and-alternatives

При установке он запускается каждые x минут, настраивается пользователем, и проверяет все папки, которые вы указали, на наличие изменений в файлах. Он должен запускаться один раз, чтобы вычислить все хэши файлов, а затем после этого он проверяет все хэши в текущем файле и проверяет, что они все те же. Вы можете указать, какой тип хэша или комбинацию хэшей использовать (я бы не рекомендовал ничего более слабого, чем SHA-256), какие атрибуты файлов использовать (содержимое, размер, измененную метку времени и т. Д.), Частоту, с которой он проверяет, как / где хранить хеш-базу и т. д.

Кто-то может счесть это излишним, но в зависимости от требований ОП, он может получить больше уверенности, что данные, которые он хранит, останутся такими же после определенного момента времени.


0

Национальный архив Австралии разработал [Checksum Checker] ( http://checksumchecker.sourceforge.net/ ), который свободно доступен под лицензией GPLv3.

Он считывает контрольную сумму и алгоритм из базы данных, затем пересчитывает контрольную сумму для файла, сравнивает два значения и сообщает, если обнаружена ошибка. Он поддерживает алгоритмы MD5, SHA1, SHA2, SHA256 и SHA512.

Другое программное обеспечение в их цифровом репозитории [DPR] ( http://dpr.sourceforge.net/ ) генерирует начальную контрольную сумму (а также выполняет все другие операции обработки)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.