NASへのコピーが成功した後にチェックサム検証が失敗する原因は何ですか？

コピーが成功した後にチェックサム検証が失敗することがあります。コピー完了は転送ツールが書き込み操作を終了したことを確認しますが、チェックサムは読み取られた瞬間のソースと宛先のバイトが同一かどうかを問います。不一致は異なるファイルバージョンやアルゴリズムの比較、まだ変化しているファイルのハッシュ化、不安定なRAMやストレージからの読み取り、または転送経路の実際の破損によって生じる可能性があります。

成功したコピーは何を証明し、何を証明しないのか？

正常なファイルコピーのステータスは通常、ツールが宛先オブジェクトを作成し、致命的な書き込みエラーがなかったことを意味します。サイズと変更時間に依存し、エンドツーエンドのコンテンツハッシュを実行しない場合もあります。ホームNASフォーラムの議論では、コピー後に宛先をチェックするためにソースをハッシュすることが推奨されています。なぜなら、通常の完了とコンテンツの同一性は別のテストだからです。

どのツールがコピーを実行したか、検証を使用したか、タイムスタンプを保持したか、各チェックサムがいつ計算されたかを記録してください。そのタイムラインがなければ、不一致が転送時の破損か後の変更かを特定できません。

両方のチェックサムが同じファイルバージョンを表していることを確認してください。

ハードウェアの調査を始める前に、正確な相対パス、サイズ、ファイルの識別を比較してください。写真編集ソフト、メディアインデクサー、データベースコンテナ、ダウンロードクライアント、または同期サービスは、最初のハッシュ後、コピーの前または途中でソースを変更することがあります。その場合、宛先には異なるバージョンが正しく含まれています。

書き込みアプリケーションを停止するか読み取り専用スナップショットを取得してソースを固定します。その安定した時点から新しいソースチェックサムを生成し、ファイルを新しい宛先名にコピーして、すべての書き込みが完了した後に宛先のハッシュを計算します。

両側で同じアルゴリズムとマニフェスト形式を使用してください。

SHA-256、BLAKE3、MD5、CRC32、およびアプリケーション固有のリポジトリハッシュは、同一のバイト列でも異なる値です。マニフェストにはバイナリモードのマーカー、エスケープされたパス、または復元されたファイルではなく圧縮オブジェクトのチェックサムが含まれることもあります。データ整合性の説明では、チェックサムは特定のアルゴリズムの下で特定のビットストリームを表すことを示しています。

両方のファイルに対して同じコマンドまたは互換性のあるツールを実行し、アルゴリズムを明示的に表示してください。NASファイルシステムのチェックサム、クラウドのETag、RAIDのパリティ値、またはバックアップチャンクのハッシュを全ファイルのSHA-256ダイジェストと比較しないでください。

ファイルがコピー中に変更されたかどうかを確認する

ライブ仮想ディスク、データベースファイル、写真ライブラリ、メールストア、コンテナボリュームは連続した読み取り間で変化することがあります。コピーはI/Oエラーなしに完了しても、非原子的な状態の混合を表す可能性があります。アプリケーションを停止し、そのバックアップ方法を使うか、スナップショットからコピーしてから検証を繰り返してください。

Rsyncの通常のクイックチェックとチェックサム比較は異なる問いに答えます。チェックサムモードと時間・サイズ比較の技術的説明は、メタデータに基づく転送判断がコピー後のコンテンツ検証と同等ではない理由を示しています。

不安定な読み取りパスを検出するためにハッシュを繰り返す

コピーせずに同じ変更されていないソースファイルを何度もハッシュ化してください。次に宛先で同じことを繰り返します。安定したファイルは毎回同じ結果を出すはずです。片方の側で繰り返し読み取り時にハッシュが変わる場合、転送自体が最初の疑いではなく、そのシステムのメモリ、コントローラー、キャッシュデバイス、ケーブル、ドライブ、ファイルシステムを調査してください。

DrivePoolのケースでは、読み取りストライピングが一貫しないチェックサム結果を生み出したことが判明しました。重要な診断パターンは特定の製品設定ではなく、同じファイルを繰り返し読み取った際に異なるバイトが返されたことです。

失敗パターンをRAM、ケーブル、コントローラー、またはディスクにマッピングする

多くの無関係なファイルがすべてのターゲットで不一致の場合は、ソースの読み取りパスまたはクライアントのRAMを疑ってください。不一致が特定のNASディスク、キャッシュデバイス、ポート、またはコントローラーに続く場合は、そのコンポーネントを分離してください。大きなSMBコピーだけが失敗する場合は、同じファイルをNAS上でローカルに、また別のクライアント経由でテストしてください。

ファイル転送後のチェックサム失敗に関するUnraidの調査では、ネットワークだけがデータを破損させたと仮定するのではなく、RAMとコントローラーの分離を競合するテストとして特定しています。

メタデータの違いをコンテンツの違いと混同しないでください

変更時間、作成時間、所有権、ACL、拡張属性、スパース割り当て、ファイル名の大文字小文字は異なっていても、ファイル全体のコンテンツハッシュが一致することがあります。逆に、サイズとタイムスタンプが一致しても、コンテンツが一致しているとは限りません。

検証ツールがマニフェストにメタデータを含む場合、コンテンツの不一致とメタデータの不一致を分離してください。必要なメタデータは適切なコピー方法で保持し、タイムスタンプのみの違いを損傷したファイル内容とラベル付けしないでください。

すべてを再コピーする前に制御されたテストマトリックスを使用する

パスを十分に検証できる不変のテストファイルを1つ使用し、1回の実行で変数は1つだけ変更します：クライアント、プロトコル、NAS共有、キャッシュ設定、ディスク、ケーブル、またはポート。失敗した宛先コピーは、不一致が繰り返されるかどうかが判明するまで保持してください。

証拠に基づいて回復アクションを選択する

ソースが安定して信頼できる場合、不一致のファイルを新しい名前で再コピーし、検証してから不良な宛先を置き換えてください。ソースも不安定な場合は、他の読み取り可能なデータを保護し、繰り返しのフルリードを行う前にハードウェアを調査してください。

アレイの健全性とファイルの同一性は異なるチェックです。ZimaSpaceの故障ドライブ交換後のチェックサム検証ガイドでは、RAIDの整合性チェックに続いて信頼できるマニフェストやバックアップとファイルレベルで比較すべき理由を説明しています。

よくある質問

異なる修正日時がチェックサムの不一致を引き起こしますか？

コンテンツのみのチェックサムでは信頼できません。メタデータを考慮した検証レポートで失敗する可能性がありますが、同一のファイルバイトは同じコンテンツハッシュを生成します。

2回目の試行で一致したチェックサムを信頼できますか？

同じ変更されていないファイルが繰り返しハッシュを生成し、最初の不一致の原因が理解されてからのみです。断続的な不一致はそれ自体が警告です。

不一致のファイルが1つあっただけで全体を再コピーすべきですか？

すぐにはそうではありません。失敗がファイル、ソース、宛先、または転送経路のどれに従うかを分離し、影響を受けた範囲を再コピーして検証してください。

最終的な結論

成功したNASコピーと成功したチェックサム検証は異なる特性を持ちます。同じファイルバージョンとアルゴリズムを確認し、ライブデータを固定し、読み取りの安定性をテストするためにハッシュを繰り返し、ハードウェアを一度に一つの変数で分離し、信頼できるソースが安定した一致する宛先を生成した後にのみデータを置き換えます。