バックアップの失敗がリポジトリに起因するのか、ソースファイルに起因するのかを見分ける方法
小規模で安定したソースから独立してテストリポジトリを読み取り、その後、疑わしいソースパスを新しい使い捨てリポジトリに対してテストします。
この判断が重要になるのは、バックアップが読み取り、チェックサム、権限、パック、またはインデックスのエラーで停止した場合です。競合する2つの状態は、リポジトリまたは保存先の破損と、ソースファイルの読み取り、権限、または変更に関するエラーです。保存済みの構成と使い捨てデータから始め、一度に1つの分岐だけを観察し、データ損失、権限、または可用性のリスクを拡大する場合は停止してください。
リポジトリまたは保存先の破損と、ソースファイルの読み取り、権限、または変更に関するエラーを切り分ける
何かを変更する前に、環境を記録します。ソフトウェアとファームウェアのバージョン、デバイスの識別情報、マウントパスまたはネットワークパス、空き容量、権限、観測された症状を記録してください。ベースラインには、バックアップが読み取り、チェックサム、権限、パック、またはインデックスのエラーで停止した状況を再現できる十分な詳細を残す必要があります。
最初の候補は、リポジトリまたは保存先の破損です。2つ目は、ソースファイルの読み取り、権限、または変更に関するエラーです。現在のResticのトラブルシューティング手順は、テストで使用する仕組みまたはコマンドの境界を定義するものであり、このホームサーバー固有の観察に取って代わるものではありません。
判別テストを実行する前に、合格条件と停止条件を記述します。合格とは、一方の分岐が予測した証拠を変化させながら、無関係なサービスには変化がないことです。不合格の場合は、推測に基づく修正を連鎖的に実行するのではなく、保存済みの状態に戻せなければなりません。
管理された判別テストを1つ実行する
次の判別テストを使用します。リポジトリチェックとカナリアリストアを実行し、その後、読み取り可能な固定テストセットをバックアップして、ソースエラーを個別に調べます。変更した変数に結果を帰属できるよう、負荷、クライアント、パス、ファイルセット、実行タイミングを一定に保ってください。
独立したResticワークフローを使用して、分岐を実際に切り分けられる項目を選び、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、レイテンシ、転送バイト数、権限、復旧状態を記録します。識別情報、耐久性、またはアプリケーション状態がテスト対象の主張である場合、コマンドが正常終了しただけでは不十分です。
再起動、再接続、再マウント、またはキャッシュのコールド化が元の条件の一部である場合は、その操作の後にテストを1回繰り返します。最初の実行が破壊的である場合、または環境を復元できない場合は、停止して、代わりに使い捨てコピー上で再現してください。
restic check
restic restore latest --include /canary --target /tmp/restore-test証拠がどの分岐を支持しているかを判断する
合格: リポジトリチェックまたはリストアが複数のソースで失敗する、またはリポジトリが健全なまま特定のソースパスだけが失敗する。結論が普遍的な主張にならないよう、合格した正確なバージョン、識別情報、負荷を記録して、条件付きの結論として維持してください。
不合格: ネットワークとメモリの障害が両方のテストに影響するため、どちらか一方が破損していると判断する前に、ローカルで再現してください。不合格だからといって、反対の分岐が自動的に証明されるわけではありません。ネットワーク、メモリ、権限、またはソースの整合性が両方に影響する可能性があるため、エスカレーションする前に共有依存関係を切り分けてください。
例外または曖昧な結果: 破壊的なメンテナンスを凍結し、ログをコピーして、最後に正常だったリポジトリの状態を保護します。復旧可能なコピーが存在するまで、ログを保持し、修復、プルーニング、破棄、再パーティション、または再帰的な所有権変更コマンドを実行しないでください。
一致する対処を適用し、元の障害を再現する
観測された分岐に対応する対処を適用し、その後、簡略化した代替条件ではなく元の条件を繰り返します。リポジトリチェックまたはリストアが複数のソースで失敗する、またはリポジトリが健全なまま特定のソースパスだけが失敗する状態が、2サイクルにわたって、または関連する再起動、スリープ、中断、負荷遷移の後も続く場合にのみ、この判断は有効です。
Resticのパックサイズ設定を使用して、直近の依存ワークフローを確認します。ただし、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、リカバリポイントでは、以前のアクセス性と処理時間を維持する必要があります。
停止境界は明確です。ネットワークとメモリの障害が両方のテストに影響するため、どちらか一方が破損していると判断する前にローカルで再現する必要がある場合は、最後に検証済みの構成に戻し、証拠を保持し、分岐が再現可能な場合にのみ、より深いプラットフォームまたはハードウェアテストへエスカレーションしてください。
対象の結果が得られたら、検証頻度と比較して、修正によって隣接するサービスにリスクが移っていないことを確認します。新しいバックアップ、識別情報、タイムアウト、または可用性の障害を伴う対象テストの成功は、依然として失敗した変更です。
FAQ
バックアップ障害の切り分けでは、通常、リポジトリチェックの成功でソースの網羅性を証明できるか、リポジトリをすぐに修復すべきか、見落としやすいソースエラーは何か、といった点を追加で確認します。以下の回答では、これらの例外的なケースを主要な判断から分けて扱います。
合格境界は変わりません。リポジトリチェックまたはリストアが複数のソースで失敗する、またはリポジトリが健全なまま特定のソースパスだけが失敗することです。後続の条件によってファイルシステム、識別情報、ネットワークパス、またはアプリケーションバージョンが変わった場合は、その変更の影響を受ける判別テストだけを繰り返してください。
ネットワークとメモリの障害が両方のテストに影響するため、どちらか一方が破損していると判断する前にローカルで再現する必要がある場合は、実験を広げるのをやめてください。その時点で、破壊的なメンテナンスを凍結し、ログをコピーして、最後に正常だったリポジトリの状態を保護します。プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に、証拠を保持してください。
リポジトリチェックの成功でソースの網羅性を証明できますか？
いいえ。証明できるのはリポジトリの特性であり、意図したすべてのソースファイルが読み取り可能だったことや、含まれていることではありません。
リポジトリはすぐに修復すべきですか？
いいえ。可能であれば安全なコピーを作成し、障害の種類を確認してからにしてください。
見落としやすいソースエラーには何がありますか？
権限拒否、消失するファイル、読み取り不能なセクター、スパースファイル、アプリケーションの整合性に関する問題は、要約に隠れている可能性があります。
同じ負荷によって、証拠がリポジトリまたは保存先の破損、またはソースファイルの読み取り、権限、または変更に関するエラーに沿って変化し、一致する対処によって別の問題を発生させずに元の症状が解消されたとき、診断は完了です。どちらの分岐も再現可能な状態を維持できない場合は、ログと保存済みの状態をそのまま保ってください。不確実性は、修正を積み重ねるのではなく、エスカレーションする理由です。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
