なぜホームNASのスナップショットはすでに破損しているデータを保存できるのですか？

ホームNASのスナップショットは、ファイルシステムの状態を保持することが役割であり、その状態のすべてのファイルが正常かどうかを判断するものではないため、破損したデータを保持することがあります。データベース、ドキュメント、写真、またはメディアファイルがスナップショット作成時にすでに損傷している場合、そのスナップショットを復元すると同じ損傷バージョンが再現される可能性があります。

破損のタイミングが重要です。スナップショットは後の上書きから以前のバージョンを保護することはできますが、一度もキャプチャされなかったクリーンなバージョンを作り出すことはできません。コピーオンライトのブロック共有はもう一つのケースを生み出します：物理的なブロックの損傷は、そのブロックを参照する複数のファイルシステムビューに影響を与える可能性があります。

スナップショットは既知の良好なコピーではなく、ファイルシステムの状態を保存する

ファイルシステムのスナップショットは特定の時点のストレージ状態を記録します。例えばOpenZFSでは、スナップショットはファイルシステムまたはボリュームの読み取り専用バージョンであり、最初はすべてのファイルを複製するのではなくアクティブなデータセットとデータを共有します。OpenZFSスナップショットのドキュメントは、スナップショットがアクティブなデータセットが変更されるまで共有されるデータをどのように保持するかを説明しています。

この操作は、保存された内容が意味的に正しいかどうかを判断しません。アプリケーションが無効なレコードを書き込んだ場合、同期ツールが誤ったバージョンをコピーした場合、またはランサムウェアが元のバイトを暗号化された内容に置き換えた場合でも、ファイルシステムは構造的に読み取り可能なファイルを保持できます。したがって、スナップショットの成功は状態が保持されたことを意味し、その状態が良好であることを保証するものではありません。

スナップショット時に存在する破損はリカバリポイントの一部となる

深夜に作成されたスケジュールされたスナップショットを考えてみましょう。アプリケーションが午後10時にデータベースを破損させた場合、深夜のスナップショットは破損後のファイルシステム状態を記録します。そのスナップショットにロールバックするとデータベースは深夜の状態に戻りますが、深夜はすでに正常なコピーを提供するには遅すぎます。

同じシーケンスは、同期エラー、不完全なインポート、誤った保存、または不正な暗号化の後にも発生します。スナップショットは破損を特別な性質として「固定」するわけではなく、単にキャプチャ時点のバージョンを保持します。古いスナップショットにはまだ使用可能なバージョンが含まれているかもしれませんが、損傷後に作成されたすべてのスナップショットは同じ論理的エラーを含む可能性があります。

破損のタイミングがスナップショットの有効性を決定する

スナップショットは、不要な論理的変更がリカバリポイントの後に発生した場合に最も役立ちます。月曜日のスナップショットに正常なファイルが含まれていて、火曜日にライブファイルが上書きされた場合、月曜日のビューは以前のデータをまだ表示できます。ファイルが月曜日にすでに壊れていた場合、その同じリカバリポイントでは問題を解決できません。

基盤となるストレージの損傷は異なる経路を作ります。スナップショットは作成時には正常だったかもしれませんが、まだ参照している物理ブロックが破損し、ファイルシステムが検証済みコピーを再構築できない場合、後に読み取り不能になることがあります。だからこそ、破損のタイミングはブロック共有とストレージの冗長性とともに考慮されなければなりません。

コピーオンライトのブロック共有はスナップショット間で1つの破損したブロックを露呈させる可能性があります

コピーオンライトスナップショットは未変更のデータを共有するためスペース効率が良いです。Btrfsストレージモデルのドキュメントは、スナップショットとその元のサブボリュームが共通の未変更データを共有していることを説明しています。したがって、スナップショットは歴史的なファイルシステムのビューであり、自動的に別の物理的なコピーではありません。

ライブファイルが通常通り変更されると、コピーオンライトは変更のために新しいストレージを割り当て、スナップショットは以前のブロックを参照し続けます。この分離がロールバックを可能にします。しかし、変更されていないブロックがまだ共有されていて、その保存されたブロックが後に読み取り不能になったり誤ったデータを返した場合、それに依存するすべてのビューが同じ障害に遭遇する可能性があります。

チェックサムと冗長ストレージは不一致を検出し別のコピーを提供することで結果を変えることができますが、スナップショット自体はその保護を作り出しません。コピーオンライトはバージョンの分離を提供しますが、独立したハードウェア障害ドメインを作成するわけではありません。

チェックサムとスクラブは整合性をテストしますが、スナップショットはしません

スナップショット、チェックサム、およびスクラブは保護スタックの異なる部分に属します。スナップショットは履歴を保存し、チェックサムは保存されたバイトが予期せず変更されたかどうかを判断するのに役立ち、スクラブはエラーを検出するために保存データを積極的に読み取ります。これらの機能を同じものとして扱うと、リカバリポイントが証明できる内容について誤った自信を持つことになります。

チェックサムは予期しないブロックの変更を検出できます

Btrfsチェックサムドキュメントは、チェックサムは書き込み前に計算され、ストレージからブロックが読み取られた後に検証されると述べています。不一致は、取得したブロックがファイルシステムが保存することを期待したブロックと異なることを示す可能性があります。

一致するチェックサムは、ドキュメント、データベース、またはメディアファイルが論理的に正しいことを証明しません。アプリケーションが通常の書き込み経路を通じて不正なデータを書き込んだ場合、ファイルシステムはその不正なバイトに対して有効なチェックサムを計算できます。アプリケーションレベルの内容が使用不能でも、ファイルシステムの観点からはブロックは無傷です。

冗長性がスクラブによる損傷修復の可否を決定します

スクラブはチェックサムエラー、読み取りエラー、および特定のメタデータの問題を検出できますが、検出は修復と同じではありません。Btrfsスクラブドキュメントは、複製ストレージでの自動修復は別のレプリカからの検証済みの良好なデータを使用すると説明しています。有効な代替コピーがなければ、ファイルシステムは損傷したブロックを特定できても再構築できない場合があります。

USENIXのZFSデータ整合性に関する研究も同様に、チェックサムベースの検出と冗長性を用いた復旧を区別しています。実際の教訓は「スクラブが破損を修復する」というより狭いもので、スクラブはストレージシステムが信頼できる代替データを見つけたり再構築できる失敗のみを修復できます。

スナップショットの保持は健全な状態がまだ存在する場合にのみ役立ちます

破損は必ずしもすぐに気づかれるわけではありません。めったに開かれない写真、アーカイブ、またはプロジェクトファイルは、誰かが使おうとするまで数週間損傷したままでいることがあります。もしスナップショットのローテーションで損傷前のすべてのバージョンがすでに削除されている場合、最近のスナップショットの深いコレクションにも健全な復旧ポイントが含まれていないことがあります。

したがって、保持期間はスナップショットがどれだけ頻繁に作成されるかだけでなく、検出可能な期間を反映すべきです。毎時のスナップショットは詳細な最近の履歴を提供し、より長期間の毎日、毎週、または毎月のポイントは、気づかれないエラーから逃れることができる期間を延長します。普遍的なスケジュールはなく、有用な間隔は変更頻度、利用可能な容量、および重要なファイルが通常どれくらいの速さでチェックされるかに依存します。

ライブNASデータを置き換える前にスナップショットを検証してください。

日付でスナップショットを選ぶのは最初のステップに過ぎません。データセット全体をロールバックしたりライブファイルを置き換えたりする前に、ホームNASプラットフォームが許す場合は、候補バージョンを別の場所に復元してください。これにより、未検証の回復試行がまだ有用な新しいデータを上書きするのを防げます。

1. 破損が最初に現れた時期を推定してください。
2. その時点より前のスナップショットを選択してください。
3. 候補を別のフォルダまたはクローンに復元してください。
4. ライブデータを置き換える前に、回復した内容を開いて検証または比較してください。

検証はデータタイプに合わせるべきです。既知のチェックサムは変更されていないアーカイブを検証できますが、データベースは独自の整合性チェックが必要で、写真やビデオはデコードが必要です。回復ポイント、独立コピー、デバイス外保護の広範な関係については、こちらのホームNASバックアップ戦略をご覧ください。

よくある質問

破損前に取得されたスナップショットが読み取り不能になることはありますか？

はい。スナップショットは後のファイル変更から以前の論理状態を保護しますが、同じストレージプールや物理ブロックを共有している場合があります。これらのブロックのいずれかが損傷し、検証済みの冗長コピーがない場合、論理的な破損より前に作成されたスナップショットでも読み取り不能になることがあります。

成功したスナップショットは、その中のすべてのファイルが健全であることを意味しますか？

いいえ。成功したスナップショットは、ファイルシステムが回復ポイントを作成したことを示しますが、すべてのファイルが開かれ、デコードされ、信頼できるバージョンと照合され、作成したアプリケーションによって検証されたことを意味しません。

データスクラブはアプリケーションによって書き込まれた破損を修復できますか？

通常は、アプリケーションが誤った内容を書き込んだ場合は修復されません。その場合、ファイルシステムは有効なチェックサム付きで不良バイトを保存することがあり、スクラブで検出できるブロックレベルの不一致がありません。回復には、より古い健全なバージョン、アプリケーション対応の修復プロセス、または独立したコピーが必要です。

破損したライブファイルを置き換えることで古いスナップショットは修復されますか？

いいえ。ライブファイルの置き換えは、アクティブなデータセットの健全なデータを書き込むか参照しますが、古いスナップショットは引き続きその歴史的状態を表します。破損したバージョンを保持しているスナップショットは、通常、有効期限が切れるか削除されるまで破損したままです。