読み取り専用スナップショットがディスク障害によって破損していないことをどのように確認できますか?
唯一の方法は、チェックサムを次々に計算し、さらに調査するために保存することですか、それとも BTRFS がそれを独自に処理しますか?
根拠
ディスク障害の可能性に備えて、スナップショットを定期的にバックアップしています。数日前、btrfs send | btrfs receive特定のスナップショットを作成できませんでした。それを削除すると、残りの操作は正常に実行されました。さらに、btrfs scrub修正できないエラーがいくつかあると表示されます。そのため、プライマリ ディスクのスナップショットは、外部ディスクにバックアップする前に破損している可能性があると考えました。これに気付いていなければ、外部ディスクにすでに破損したバックアップが残ってしまうことになります。
私が防止したいのは、まさにそれです。スナップショットをバックアップできる場合は、それが破損していないことを確認したいのです。
答え1
「ディスク障害による破損」の意味に応じて、2 つの回答が考えられます。
単純な保存データの破損を意味するのであれば
BTRFS はこれをユーザーに対して透過的に処理します。スナップショット内のデータを含むすべてのチェックサムを内部で計算し、各ブロックを読み取るときにチェックサムを検証します。ただし、これにはいくつかの例外があります。
- ボリュームが
nodatasumまたはnodatacowオプションでマウントされている場合、データ ブロックのチェックサムは行われません。ほとんどの場合、これらのオプションを使用してマウントする必要はないため、これは問題にはなりません。 - 属性が設定されているファイル
NOCOW(コマンドCの出力内lsattr) もチェックされません。この属性が設定されている本当に重要なファイルはおそらくないでしょう (systemd ジャーナル ファイルには設定されていますが、手動で設定しない限りそれだけです)。
多数のデバイスが失われたためにボリューム上のデータが破壊されることを意味する場合
データの別のコピーをどこかに保管する以外に、これを防ぐ方法はありません。ボリュームのストレージ プロファイルが許容できる数よりも多くのデバイスを紛失した場合、データは失われ、バックアップから復元する以外にデータを取り戻す方法はありません。
あなたの具体的なケースに関して
送信/受信に関してあなたが言及している問題は、おそらく scrub によって報告された修正不可能なエラーの副作用です。BTRFS が透過的にエラーを修正できない場合 (通常、ブロックが single や raid0 などの回復できないプロファイルを使用して保存されているため)、I/O エラーが返され、送信操作が失敗します。したがって、送信/受信を使用している場合は、すでに破損したバックアップにはなりません (実際、他のほとんどのツールでも同様です。優れたバックアップ ソフトウェアは、ファイルを読み取れない場合はエラーをスローします)。
この場合、修正不可能なエラーは、スナップショット専用のデータ、またはスナップショットされていないデータにのみ存在するようです。ソース ボリュームを別の場所にマウントし、マウントした場所から次のコマンドを実行すると、どのファイルに問題があるかを簡単に (ただし、非常に迅速に) 特定できます。
find . -exec cat '{}' \; > /dev/null
これにより、ボリューム上のすべてのファイルを読み取ろうとし、コンソールに読み取りエラーが表示され、エラー メッセージにファイル名が表示されます。これは非常に遅くなる可能性があるため、ボリュームが大きい場合は並列化することをお勧めします。
これらのファイルを見つけて対処すれば、それ以上の問題は発生しないはずです。これらの問題が修正後も近い将来に再び発生する場合は、ハードウェアのチェックを検討してください。何か静かにデータを破損しています。