大規模なファイルのコレクション（通常は複雑なディレクトリ階層内にネストされている）のチェックサムをキャプチャして検証できるようにしたいと思います。
すべてのファイルにチェックサムが必要ですか？既存のディレクトリ構造を活用して、たとえばファイルツリー内のノードのみを検証し、必ずしもすべてのファイルを検証する方法はありますか？
回答:
チェックサムを使用する最も効率的な方法は、コンピューターにすべてを実行させることです。ZFSなどのファイルシステムを使用して、書き込み時にすべてのデータをチェックサム（実際にはチェックサムよりも強いハッシュを使用）し、データが読み取られるたびに検証します。もちろん、欠点は、ファイルの削除または上書きがいつ間違いであり、通常の操作であるかをZFSが認識しないことですが、ZFSはすべてにコピーオンライトセマンティクスを使用するため、そのスナップショット機能を使用してリスクを軽減できます。
ZFSは、raid5スタイルのパリティ、ドライブミラー、または複製コピーなど、設定した冗長性を使用して、ハッシュチェックに失敗したデータを自動的に復元することもできます（copys = NプロパティをZFSファイルシステムに追加し、N個のコピーを保存します）あなたが書くデータの）。また、ハッシュをマークルツリーに保存します。ファイルのハッシュ値はブロックのハッシュに依存し、ディレクトリエントリのハッシュは含まれるファイルとディレクトリのハッシュ値に依存し、ファイルシステムのハッシュは依存しますルートディレクトリなどのハッシュ上
最終的にどのソリューションが使用されるかに関係なく、プロセスは常にCPUの速度ではなくディスクの速度によって制限されることがわかります。
また、ディスクのBERを考慮することを忘れないでください。結局のところ、それらは回転する錆の単なるプレートです。コンシューマレベルのドライブでは、10 ^ 14ビットの読み取りごとに1ビットの誤った読み取りエラーが発生します。これは、読み取り11テラバイトごとに1ビットになります。11テラバイトのデータセットがあり、その中のすべてのファイルのハッシュを計算すると、それらのチェックサムの1つが誤って計算され、データセットのファイルの1つのブロックが永久に破損します。ただし、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つのチェックサムがあると仮定します。データが破損していることは知っていますが、これがたった1つのファイルであるかどうか、さらに重要なのはどれなのかはわかりません。個別のチェックサムを使用すると、柔軟性が高まります。破損した単一のファイルを検出し、他のバックアップのファイルから置き換えることができます（これにより、他のファイルが破損する可能性があります）。
そうすることで、データが生き残る可能性が高くなります。
たぶん、これはBagItを立ち上げる良い機会です。これは、デジタルオブジェクトのアーカイブ、長期保存、および転送を目的とした、非常にシンプルでありながら強力なファイルパッケージ形式です。ユーザーには、米国議会図書館とカリフォルニア州デジタル図書館が含まれます。
BagItツール（いくつかのプログラミング言語に存在します）は、ファイルを特定のディレクトリ構造に配置し、チェックサム/ハッシュを行います。以上です。
PS：もちろん、BagItツールは含まれているチェックサム/ハッシュに対してバッグを検証することもできます。また、バッグにメタデータを追加することもできます。しかし、それはバッグと同じくらい複雑です。
この回答は@ lechlukaszと@ db48xの回答の組み合わせであり、コメントで述べられたいくつかのポイントと、私自身の考えの一部も取り入れています。
単純なパスフォワードは、ファイルシステムと個別のメタデータを組み合わせたアプローチです。
ZFSやBtrfsなど、オンザフライでデータのハッシュと検証を行うファイルシステムを使用することにより（現時点では、Btrfsは本番環境で使用できる状態ではないと見なされていることに注意してください）オペレーティングシステムのエラーなしでデータをディスクから読み取ることができる場合、読み取ったデータはファイルシステムが意図した方法でディスクに書き込まれたことを確認してください。定期的な「スクラブ」操作を実行することにより、すべてのデータが読み取られ、ファイルシステムの本来のアイデアに対して検証されます。
ただし、これはディスク上の破損（読み取り不能なブロック、完全なハードウェア書き込みエラー、ブロックデバイス上のデータの一部を直接破損する無効な書き込みなど）からのみ保護します。ソフトウェアのバグ、誤ったユーザー操作、またはファイルを操作するために意図されたオペレーティングシステム機能を介して機能する悪意のあるソフトウェアは、これらの機能にそのようなバグがないと仮定して保護しません。
後者から保護するには、別の保護層が必要です。ユーザーアプリケーションの観点からのデータのチェックサムまたはハッシュは、上記のリスクの多くから保護するのに役立ちますが、個別に実行する必要があります（ソフトウェアの組み込みプロセスアクションとして、または完全に別個のプロセスとして）。
今日のハードウェアと大量のデータを保存するのに実用的なもの（ソリッドステートディスク/ SSDではなくプラッターハードディスクを回転させる）では、SHA1などの複雑なハッシュアルゴリズムでさえ、大部分はI / Oにバインドされます-つまり、速度データがハッシュされる場所は、コンピューターのプロセッサがハッシュを計算する能力ではなく、ストレージシステムの読み取り速度の関数になります。2012年に中間層のコンシューマPCであった約150 GBのデータに対してユーザースペースMD5ハッシュプロセスを実行する実験を行い、基本的に約40分間中断することなくディスクを実行した後に終了しました。それらの数値を100倍に拡大すると、同じハードウェア上で約3日間で15 TBコレクションのMD5ハッシュを取得できます。読み取り転送速度を追加することにより（たとえば、簡単に達成できますたとえば、RAID 0は冗長性のないストライピングであり、通常はRAID 1と組み合わせて高い読み取り/書き込みパフォーマンスを達成するために一般的に使用され、RAID 10を形成します）、同じ量のデータに対して完了までの時間を短縮できます。
この2つを組み合わせることで、両方の長所を活用できます。ファイルシステムは、ファイルの読み取り時に受け取ったものが実際に書き込まれたものであることを保証し、コレクション全体に対して別個の修正チェックプロセスを実行して、データを保証しますstoredは、アーカイブに取り込まれたものと一致します。2つの間の不一致（ファイルシステムはファイルが正常であると言い、修正チェックはそうではないことを示します）は、アーカイブの意図された動作モード以外で、オペレーティングシステムの施設内から変更されたファイルを示し、セカンダリからの復元を促しますコピー（バックアップ）。したがって、固定性チェックはより長い時間間隔で実行できます。これは非常に大きなアーカイブにとって不可欠になりますが、読み取りが成功した場合、オンラインアクセスはハードウェア上で破損しないことが保証されます。原則として、アーカイブソフトウェアはファイルシステムに依存して読み取りエラーとして不整合を報告し、ユーザーがファイルを操作しているときにバックグラウンドで個別の修正チェックを実行し、ファイルが取り込まれたものと一致しないことを示す適切なメッセージを表示する必要がありますアーカイブに。このようなスキームは、ブロックハッシュファイルシステムを使用すると、知覚されるパフォーマンスへの影響を最小限に抑えながら、コンテンツが正しいことを保証できます。
私は答えを検討しましたが、データレイヤーエラーを処理するためにZFSに依存するというアイデアは好きですが、ファイルが誤ってまたは悪意を持って変更されるという問題がまだあります。その場合、ZFSはユーザーを保護しません。また、他の誰かが述べたように、外部検証のためにユーザーに表示可能な「ハッシュ」を他の場所に保存することもできません。
システムの実行可能ファイルを監視し、攻撃後に変更されていないことを検証するために広く使用されたTripWireと呼ばれるLinuxアプリケーションがあります。そのプロジェクトは現在は見捨てられているAIDE (Advanced Intrusion Detection Environment)ようですが、ServerFaultで推奨されると呼ばれる新しいプロジェクトがあります。
/server/62539/tripwire-and-alternatives
インストールすると、x分ごとに実行され、ユーザーが構成できます。また、ファイルの変更について指定したすべてのフォルダーをチェックします。すべてのファイルハッシュを計算するために1回実行する必要があり、その後、現在のファイルに対してすべてのハッシュをチェックし、それらが同じままであることを確認します。使用するハッシュのタイプまたはハッシュの組み合わせ（SHA-256よりも弱いものはお勧めしません）、使用するファイル属性（コンテンツ、サイズ、変更されたタイムスタンプなど）、チェックする頻度、ハッシュデータベースの保存方法/場所など
このやり過ぎを考慮する人もいるかもしれませんが、OPの要件によっては、特定の時点以降、保存しているデータが同じままになるという安心感が得られる場合があります。
オーストラリア国立公文書館は、GPLv3の下で自由に利用できる[Checksum Checker]（http://checksumchecker.sourceforge.net/）を開発しました。
データベースからチェックサムとアルゴリズムを読み取り、ファイルのチェックサムを再計算し、2つの値を比較してエラーがある場合はレポートします。MD5、SHA1、SHA2、SHA256、およびSHA512アルゴリズムをサポートしています。
デジタルリポジトリ[DPR]（http://dpr.sourceforge.net/）内の他のソフトウェアは、初期チェックサムを生成します（他のすべての処理アクティビティを実行します）。