Этот ответ является комбинацией ответов @ lechlukasz и @ db48x , а также включает в себя некоторые замечания, высказанные в комментариях, а также некоторые из моих собственных мыслей.
Простой путь вперед - это комбинированный подход файловой системы и отдельных метаданных.
Используя файловую систему, которая выполняет хеширование и проверку данных на лету, например, ZFS или Btrfs (учтите, что, несмотря на значительные успехи, Btrfs не считается готовым к использованию в настоящее время), вы можете быть разумно Убедитесь, что если данные могут быть считаны с диска без ошибок операционной системы, тогда считанные данные были записаны на диск так, как это предусмотрено файловой системой. При выполнении периодических операций «очистки» все данные считываются и проверяются в соответствии с представлением файловой системы о том, каким оно должно быть.
Однако это защищает только от повреждения на диске (нечитаемые блоки, прямые ошибки аппаратной записи, неправильные записи, которые повреждают части данных непосредственно на блочном устройстве и т. Д.). Он не защищает от программной ошибки, некорректной пользовательской операции или вредоносного программного обеспечения, которое работает через предназначенные средства операционной системы для работы с файлами, при условии, что эти средства не содержат таких ошибок.
Чтобы защитить от последнего, вам нужен еще один уровень защиты. Контрольная сумма или хеширование данных с точки зрения пользовательского приложения поможет защитить от многих из вышеупомянутых рисков, но их необходимо выполнять отдельно (либо как встроенное действие процесса в программном обеспечении, либо как полностью отдельный процесс).
С современным оборудованием и тем, что практично для хранения больших объемов данных (вращающиеся жесткие диски в отличие от твердотельных дисков / твердотельных накопителей), даже сложные алгоритмы хеширования, такие как SHA1, будут в значительной степени связаны с вводом / выводом, то есть скорость при котором данные хэшируются будут зависеть от скорости чтения системы хранения, а не от способности процессора компьютера вычислять хэш. Я провел эксперимент с запуском процесса хеширования MD5 в пользовательском пространстве на примерно 150 ГБ данных на том, что в 2012 году было потребительским ПК среднего уровня, и он завершился после того, как диск работал в основном без перерыва в течение примерно 40 минут. Если вы увеличите эти цифры в 100 раз, вы получите хеш MD5 из коллекции 15 ТБ примерно за три дня на том же оборудовании. Добавляя скорость передачи чтения (которая может быть легко достигнута, например,RAID 0, например, является чередованием без избыточности, обычно используется для достижения более высокой производительности чтения / записи, возможно, в сочетании с RAID 1, формирующим RAID 10 ), время до завершения может быть уменьшено для того же объема данных.
Комбинируя эти два, вы получаете лучшее из обоих миров: файловая система дает вам уверенность в том, что то, что вы получили при чтении файла, является тем, что было на самом деле написано, и отдельный процесс проверки исправности может выполняться по всей коллекции, гарантируя, что данные сохраненный до сих пор соответствует тому, что было включено в архив. Любое несоответствие между ними (файловая система говорит, что файл в порядке, проверка исправности говорит, что это не так) будет указывать на файл, который был изменен за пределами предполагаемого режима работы архива, но изнутри в средствах операционной системы, запрашивая восстановление из вторичного устройства. копия (резервная копия). Таким образом, проверка исправности может выполняться с более длительным интервалом времени, что становится необходимым для очень больших архивов, но любой доступ в режиме онлайн по-прежнему гарантированно не будет поврежден на оборудовании, если чтение выполнено успешно. В общем, программное обеспечение для архивирования может полагаться на файловую систему, чтобы сообщать о несоответствиях как об ошибках чтения, и выполнять отдельную проверку исправления в фоновом режиме, когда пользователь работает с файлом и отображает соответствующее сообщение, которое должно указывать, что файл не соответствует тому, что было загружено в архив. При использовании файловой системы с хэшированием блоков такая схема будет иметь минимальное влияние на воспринимаемую производительность, но при этом будет обеспечивать уверенность в правильности содержимого.