Я хотел бы иметь возможность собирать и проверять контрольные суммы для крупномасштабных коллекций файлов, обычно вложенных в сложную иерархию каталогов.
Каждому файлу нужна контрольная сумма? Существуют ли способы использовать существующую структуру каталогов, скажем, для проверки только узла в дереве файлов и не обязательно каждого файла в нем?
Самый эффективный способ использования контрольных сумм - заставить компьютер делать все это. Используйте файловую систему, такую как ZFS, которая проверяет контрольные суммы (фактически она использует хеши, которые сильнее контрольной суммы) всех данных, когда они записываются, и проверяет их при каждом чтении данных. Конечно, недостатком является то, что ZFS не знает, когда удаление или перезапись файла является ошибкой и когда это нормальная операция, но поскольку ZFS использует семантику копирования при записи для всего, вы можете использовать его функцию моментального снимка, чтобы снизить риск ,
ZFS также может автоматически восстанавливать данные, которые не проходят проверку хеша, используя любую настроенную вами избыточность, будь то контроль четности в стиле raid5, зеркала дисков или дубликаты копий (добавьте свойство copy = N в любую файловую систему ZFS, и она будет хранить N копий любых данных, которые вы пишете). Он также хранит хеши в дереве Merkle, где хеш-значение файла зависит от хеш-значений блоков, хеш-значение записи каталога зависит от хеш-значений файлов и каталогов, которые оно содержит, хеш-функция файловой системы зависит по хешу корневого каталога и т. д.
Независимо от того, какое решение вы используете, вы всегда обнаружите, что процесс ограничен скоростью ваших дисков, а не скоростью вашего процессора.
Также не забывайте учитывать BER ваших дисков. В конце концов, это всего лишь пластины вращающейся ржавчины. Диск на уровне потребителя имеет частоту ошибок 1 неправильно прочитанный бит на каждые 10 ^ 14 прочитанных битов, что составляет 1 бит на каждые 11 терабайт, которые вы прочитали. Если у вас есть набор данных объемом 11 терабайт, и вы вычисляете хэш каждого файла в нем, вы будете неправильно вычислять одну из этих контрольных сумм и навсегда повредить один блок одного из файлов в наборе данных. Однако ZFS знает хэш каждого блока, который он записал на каждый диск в вашем пуле, и, следовательно, знает, какой блок был потерян. Затем он может использовать избыточность (четность, зеркала или дополнительные копии) в вашем пуле, чтобы перезаписать данные в этом блоке с правильными значениями. Эти функции безопасности также применяются, когда вы используете zfs send или receive для копирования данных из вашей основной системы в резервные копии.
Однако в комментариях Бен поднимает хороший вопрос. 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 в качестве примера.
Я бы сгенерировал контрольную сумму для каждого файла. Контрольные суммы очень малы, и генерация контрольной суммы для всего каталога потребует от вас также обработки каждого файла (по крайней мере, если вы не говорите о контрольной сумме каталога, сделанной только из записей каталога - я бы также сделал их, чтобы гарантировать отсутствие данных). удаляется).
Предположим, у вас есть одна контрольная сумма для всего архива. Вы знаете, что данные повреждены, но вы не знаете, является ли это только одним файлом, и, что более важно, какой из них. Наличие отдельных контрольных сумм дает вам больше гибкости. Вы можете обнаружить один файл, который поврежден, и заменить его из файла из другой резервной копии (которая, в свою очередь, может повредить другой файл).
Таким образом, ваши данные, скорее всего, выживут.
Может быть, сейчас хорошее время для воспитания BagIt. Это очень простой, но мощный формат упаковки файлов, предназначенный для архивирования, долгосрочного хранения и передачи цифровых объектов. Пользователи включают Библиотеку Конгресса и Калифорнийскую цифровую библиотеку.
Инструмент BagIt (они существуют на нескольких языках программирования) помещает ваши файлы в определенную структуру каталогов и выполняет проверку / хеширование за вас. Это все.
PS: Конечно, инструменты BagIt также могут проверять пакеты на соответствие контрольным суммам / хэшам, и вы можете добавить некоторые метаданные в пакеты. Но это так сложно, как мешки.
Этот ответ является комбинацией ответов @ lechlukasz и @ db48x, а также включает в себя некоторые замечания, высказанные в комментариях, а также некоторые из моих собственных мыслей.
Простой путь вперед - это комбинированный подход файловой системы и отдельных метаданных.
Используя файловую систему, которая выполняет хеширование и проверку данных на лету, например ZFS или Btrfs (учтите, что, хотя большие успехи были достигнуты, Btrfs не считается готовым к использованию в настоящее время), вы можете быть разумно Убедитесь, что если данные могут быть считаны с диска без ошибок операционной системы, тогда считанные данные были записаны на диск так, как это предусмотрено файловой системой. При выполнении периодических операций "очистки" все данные считываются и проверяются на соответствие представлению файловой системы о том, каким оно должно быть.
Однако это защищает только от повреждения на диске (нечитаемые блоки, прямые ошибки аппаратной записи, недействительные записи, которые повреждают части данных непосредственно на блочном устройстве и т.д.). Он не защищает от программной ошибки, неправильной пользовательской операции или вредоносного программного обеспечения, которое работает через предназначенные средства операционной системы для работы с файлами, предполагая, что эти средства не содержат таких ошибок.
Чтобы защитить от последнего, вам нужен еще один уровень защиты. Контрольная сумма или хэширование данных с точки зрения пользовательского приложения помогут защитить от многих из вышеупомянутых рисков, но их необходимо выполнять отдельно (либо как встроенное действие процесса в программном обеспечении, либо как полностью отдельный процесс).
С современным оборудованием и тем, что практично для хранения больших объемов данных (вращающиеся жесткие диски в отличие от твердотельных дисков / твердотельных накопителей), даже сложные алгоритмы хеширования, такие как 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/) генерирует начальную контрольную сумму (а также выполняет все другие операции обработки)
