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

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

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

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

Также не забывайте учитывать BER ваших дисков. В конце концов, это всего лишь пластины вращающейся ржавчины. Диск на уровне потребителя имеет частоту ошибок 1 неправильно прочитанный бит на каждые 10^14 прочитанных битов, что составляет 1 бит на каждые 11 терабайт, которые вы прочитали. Если у вас есть набор данных объемом 11 терабайт, и вы вычисляете хеш каждого файла в нем, вы будете неправильно вычислять одну из этих контрольных сумм и навсегда повредить один блок одного из файлов в наборе данных. Однако ZFS знает хэш каждого блока, который он записал на каждый диск в вашем пуле, и поэтому знает, какой блок был потерян. It can then use the redundancy (parity, mirrors or extra copies) in your pool to rewrite the data in that block with the correct values. These safety features also apply when you use zfs send or receive to copy data from your primary system to the backups.

Ben brings up a good point in the comments however. ZFS doesn't expose any of the hash values that it computes to the user, so data that enters or leaves a ZFS system should be accompanied by hashes. I like the way the Internet Archive does this with an xml file that accompanies every item in the archive. See https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml as an example.

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

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

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

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

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

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

This answer is a combination of that of @ lechlukasz and @ db48x, also incorporating some points made in comments as well as some of my own thoughts.

The simple path forward is a combined file-system and separate-metadata approach.

By using a file system that does on-the-fly data hashing and validation, such as ZFS or Btrfs (do note that although great advances have been made, Btrfs is not considered ready for production use at this time), you can be reasonably sure that if the data can be read off the disk without the operating system erroring out, then the data read was written to disk in the way intended by the file system. By running periodic "scrub" operations, all data is read and verified against the file system's idea of what it should be.

However, that only protects against on-disk corruption (unreadable blocks, outright hardware write errors, invalid writes that corrupt parts of the data directly on the block device, etc.). It does not protect against a software bug, incorrect user operation, or malicious software which works through the intended operating system facilities for working with files, assuming that those facilities are free of such bugs.

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

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

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

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

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

https://serverfault.com/questions/62539/tripwire-and-alternatives

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

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

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

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

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