リポジトリの整合性チェックに合格しても、1つのファイルの復元に失敗するのはなぜですか？
リポジトリチェックが成功していても、チェックが実際の復元経路そのものではなく、メタデータやサンプルデータを検証している場合は、1つのファイルの復元に失敗することがあります。
バックアップ検証は、1種類の万能な処理ではありません。リポジトリの構造、インデックス、マニフェスト、参照チャンクを確認するだけで、保存されたすべてのバイトを読み取らないチェックもあります。ほかにも、データをサンプリングしたり、取得されていないファイルを対象外にしたり、復元先ファイルシステムのファイル名、権限、ACL、ラベル、空き容量、アプリケーションによるロックについては何も確認しないチェックがあります。復元に失敗したファイルについては、スナップショットの選択から保存オブジェクトを経て、復元先での作成に至る経路として考えてください。
成功したチェックで何が検証されたのかを正確に確認する
チェックコマンド、オプション、バックアップツールのバージョン、リポジトリバックエンド、スナップショットID、最終ログを保存します。リポジトリの構造、アーカイブメタデータ、参照チャンク、保存データ、実際の展開のどれが確認されたのかを特定します。
Borgの標準アーカイブチェックは、デフォルトではメタデータを読み取りますが、ファイルデータは読み取らないと説明されています。データ検証を明示的に要求した場合を除きます。
したがって、緑色の成功結果が示すのは、参照関係に内部的な整合性があるということだけで、一部のペイロードチャンクが未読のまま残っている可能性があります。代表的なファイルを実際に展開するまで、リポジトリ全体が完全に復元可能だと判断しないでください。
対象ファイルの保存データが実際に読み取られたか確認する
対象のスナップショット内でファイルを検索し、再構成に必要なパック、チャンク、オブジェクトを特定します。復元に失敗したファイルと、リポジトリチェックでデータが読み取られた範囲を比較します。
Resticでは、read-dataおよびread-data-subsetチェックについて説明しており、通常の構造チェックと、ペイロード全体の読み取りが異なる検証レベルであることが分かります。
一部だけが読み取られていた場合、復元に失敗したファイルが未検証のパックに依存している可能性があります。修復を試みる前に、対象を絞ったデータチェック、またはサポートされている完全なデータチェックを実行してください。
そのファイルが対象のスナップショットに含まれているか確認する
選択したスナップショット内で、正確な相対パスを一覧表示します。フィルター、除外設定、読み取り不能なソースに関する警告、シンボリックリンクのルール、マウント境界、復元画面で別のバージョンを選択していないかを確認します。
Kopiaは、ignoreポリシーによって一致するパスが除外されると説明しています。そのため、目的のファイルが取得されていなくても、リポジトリの整合性チェックは成功する可能性があります。
プレースホルダーのパスや親ディレクトリのエントリだけでは、ファイルのペイロードが存在する証拠にはなりません。スナップショットのインベントリ、サイズ、ハッシュ、タイムスタンプを、想定されるソースの記録と比較してください。
復元先のファイル名とパスの制約を確認する
同じファイルを、短く空のローカルパスに、単純な名前で復元します。使用できない文字、予約名、大文字と小文字の衝突、末尾の空白、パスの長さ、Unicode正規化の違いを比較してください。
Microsoftのファイル名に関するガイダンスでは、Windowsのファイル名とパスの制限について説明されています。これにより、リポジトリ自体が正常でも、特定の復元先パスだけが拒否されることがあります。
ファイルを一時的な短いパスに復元できる場合、保存されたコンテンツは利用可能です。リポジトリを修復するのではなく、復元先の構成または名前変更マッピングを修正してください。
ACL、拡張属性、所有者情報の復元を確認する
使い捨ての復元先でのみ、メタデータの保持を無効にして復元を繰り返し、通常のメタデータ対応復元と比較します。最初に失敗した属性を記録してください。
GNU tarでは、ACLと拡張属性の復元が個別に説明されています。これは、ファイルデータは読み取れる一方で、メタデータの適用に失敗することがある理由を示しています。
アプリケーションがACL、所有者情報、スパース領域、xattrに依存している場合、メタデータなしの復元を本番環境での解決策として扱わないでください。失敗している層を特定するためだけに使用します。
セキュリティラベルと復元先のポリシーを確認する
復元先のSELinuxラベル、ウイルス対策ソフトやエンドポイント保護、ランサムウェア対策、immutableフラグ、共有権限、アプリケーションによるロックを確認します。
Red Hatでは、ファイルの作成または移動後にラベルが欠落している、または不適切な場合に、デフォルトのセキュリティコンテキストを復元する方法を説明しています。
展開はできても開けないファイルは、リポジトリの障害ではなく、復元先のポリシーによる失敗である可能性があります。復元されたファイルを必要とするユーザーとアプリケーションと同じ経路でテストしてください。
修復を行う前に分離された環境で復元する
復元に失敗したファイル、その親のメタデータ、近接する複数のファイルを、空のデータセットまたは一時ディレクトリに復元します。修復コマンドを実行する前に、ハッシュ、ログ、リポジトリの状態を保存してください。
ZimaSpaceのチェックサムとメタデータの検証に関するガイドでは、保存コンテンツの整合性と、アプリケーションで利用可能な復旧との違いについて説明しています。
選択したファイルが意図したスナップショットから復元され、期待されるコンテンツと一致し、必要なメタデータが付与され、本番環境のアプリケーション経路から開けることを確認できれば、問題は解決です。
よくある質問
リポジトリチェックに成功すれば、すべてのファイルを復元できることが証明されますか？
いいえ。保存されたデータをすべて読み取ったかどうか、また復元先で各パスとメタデータを再作成できるかどうかによって異なります。
1つの復元に失敗したら、すぐに修復を実行すべきですか？
いいえ。まず別の復元先でテストし、そのファイルがスナップショットに存在することを確認して、サポートされているデータチェックを実行してください。修復によって、破損したメタデータやオブジェクトが削除される可能性があります。
テスト復元に成功するほうが、検証レポートより確実ですか？
テストした復元経路については、はい。特定のサンプルについて、選択、復号、ペイロードの読み取り、復元先の作成、メタデータ処理が機能したことを証明できます。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
