クラッシュ後にResticリポジトリがロックされた場合：原因、確認方法、対処法
別のプロセスがまだ実行中である、クラッシュによって古い状態が残っている、バックエンドの更新が遅れている、またはメンテナンス処理が排他ロックを保持しているため、Resticリポジトリのロックが解除されないことがあります。
複数ホストで構成されたホームサーバーでは、最後に目にしたクラッシュが唯一のロックを作ったという思い込みは危険です。別の場所でpruneジョブがまだ実行中かもしれませんし、コンテナが同じスケジュールで再起動している可能性もあります。また、オブジェクトストレージに最新状態がすぐ反映されないこともあります。まず新しいスケジュールを停止し、ロックの識別情報を確認してください。ホスト、プロセス、時刻、リポジトリのアクティビティがすべて処理の終了を示している場合に限り、ロックを削除します。
操作する前にロックの識別情報を確認する
リポジトリにアクセスできるすべてのマシンで、新しいバックアップ、forget、check、pruneのスケジュールを一時停止します。ロックの一覧を表示し、ホスト、プロセスID、ユーザー、作成時刻、更新時刻、排他または非排他の役割を保存してください。その後、ロックに記録されたホスト上で、推測だけで判断せず、該当するプロセスとサービスログを調べます。
Resticプロセスが中断された後に古いロックが残ることはよくありますが、中断されたパイプラインは原因の一つにすぎません。正常でないシグナルを受け取ったプロセスが、リモートジョブがまだ動作している場合とよく似た状態を残すこともあります。
PIDが存在し、ログが進行している場合は、待機するか、サービスマネージャーを通じてジョブを停止してください。その下でロックを解除してはいけません。プロセスが存在せず、ホストも同じジョブを再起動していない場合、そのロックは古いロックの候補になります。ホストに接続できない場合や、バックエンドの表示に一貫性がない場合は、状態を確認できていないため、破壊的な操作を行う根拠はありません。
4種類のロック状態を切り分ける
実行中の書き込み処理には、対応するプロセス、現在進行中のログアクティビティ、更新され続けるロックがあります。異常終了では、実行中のプロセスが存在せず、ホストまたはコンテナの停止後にロックのタイムスタンプが固定されます。バックエンドの遅延は、クライアント間でロック一覧の内容が一致しない場合や、既知のリポジトリアクティビティに比べてタイムスタンプの反映が遅れている場合に現れます。未完了のメンテナンスでは、排他ロックが存在し、checkまたはpruneのログが変化し続けます。
包括的なResticのトラブルシューティング手順では、リポジトリロック、pruneの失敗、破損の可能性を別々の分岐として扱います。これにより、ストレージ障害に対して古いロックの修正を適用することを防げます。
一度に一つの状態だけを検証してください。まず処理が生きているかを確認し、次にタイムスタンプとログを比較し、その後でバックエンドへの接続性と時刻を確認し、最後にメンテナンス処理を調べます。2つの状態が依然として考えられる場合は、ロックを保持して安全な分岐を調査してください。ロック解除は診断テストではありません。理解しようとしている保護機能そのものを変更してしまうためです。
古いロックだと確実に判断できた場合のみ解除する
ロックを解除する前に、すべてのクライアント、自動化コントローラー、コンテナホスト、リポジトリ側のサービスをもう一度確認してください。現在のロック一覧と直近のログを保存します。すべて削除するコマンドやロックなしのオプションではなく、通常の古いロック削除コマンドを使用してください。標準の手順は、アクティブなロックを残すように設計されています。
実際の古いロックによる失敗は、確立済みのバックアップスケジュールであっても停止させることがあります。ただし、ある事例での経過時間を、普遍的に安全な削除基準とみなしてはいけません。
標準コマンドで古い記録が削除され、ロックがすぐに再作成されない場合は、読み取り専用のリポジトリ一覧表示に進みます。アクティブなロックであるため拒否された場合は、停止して所有者を探してください。すぐに新しいロックが現れた場合は、スケジューラーまたは再起動したコンテナがまだ動作しています。別の修復を試みる前に、その発生源を無効化してください。
元の操作を再テストし、再発を監視する
失敗したときと同じ操作を実行し、進行状況と終了ステータスを記録します。ジョブがアクティブな間にロックが現れて更新され、正常終了後に消えることを確認してください。その後、通常のスケジュールサイクルを1回実行します。これにより、単にリポジトリの一覧表示が成功した場合よりも、元のトリガーを再現していることを確認できます。
ロック解除後にリポジトリが読み取り専用になったり、メンテナンスが失敗したりする場合は、繰り返しロックを解除するのではなく、別のprune中断からの復旧手順に従ってください。
元の負荷で2サイクルが完了し、それぞれのロックがアクティブな間に更新され、終了時に削除され、リポジトリチェックまたはサンプルリストアも正常に動作すれば、復旧は成功です。正常終了後もロックが再発する場合、クライアント間でバックエンドの状態が一致しない場合、またはcheckでリポジトリオブジェクトの欠落や破損が報告される場合は、エスカレーションしてください。その調査中はロックを有効に保ってください。
おすすめ商品
サポートとヒント
もっと読む
ロックの競合を避けて Restic のバックアップ、Forget、Prune ジョブをスケジュールする方法
頻繁なバックアップ、対象を限定した保持、物理的なプルーニング、チェック、再試行、リストア検証を分離した、完全なマルチホスト対応Resticスケジュール。
Resticのプルーニングジョブによってスケジュール済みバックアップがブロックされるのを防ぐ方法
共有Resticリポジトリ向けの予防計画。バックアップの実行時間帯とプルーンを分離し、ロック、再試行、アラートを維持します。
アクティブなバックアップを中断せずに古いResticロックを解除する方法
アクティブなバックアップを保護し、古い状態のみを削除して、通常のスケジュールで復旧を確認する、影響を最小限に抑えたResticのロック解除ワークフロー。
