別のホストがプルーニングを開始すると、Resticのバックアップが停止するのはなぜですか？
バックアップが通常停止するのは、prune が共有リポジトリを排他的に制御する必要があるためです。その瞬間、2台目のホストは同じリポジトリの状態を使って処理を続行できません。
複数ホストのホーム環境では、まず発生タイミングを確認します。バックアップが正常に進行し、別のマシンが prune を開始した後、バックアップが待機するかロックを報告する場合です。何かを操作する前に、ロックの所有者と実行中のメンテナンスログを確認してください。prune が完了するまで待つか、所有ホストから安全に停止します。待機中のバックアップクライアントからロックを削除してはいけません。
Prune が正確なトリガーであることを確認する
待機中のバックアップログと、prune を実行しているホストのメンテナンスログをタイムスタンプ付きで保存します。リポジトリのロックを一覧表示し、ホスト、プロセス、排他状態が prune ジョブと一致するか確認します。prune がリポジトリを取得した後にバックアップの進行が止まり、そのロックが解放された後に再開するなら、この原因が裏付けられます。
1つのリポジトリを複数ホストで使用している運用者からは、バックアップスケジュール同士が独立していてもメンテナンス処理が競合するため、prune 中のロック競合が報告されています。
バックアップがもともと遅かった場合、prune ホストがロックを取得していない場合、または両方のログがストレージエラーで停止している場合は、この診断を強制的に適用しないでください。バックエンドの可用性、レイテンシ、バックアッププロセス自体を確認します。prune によるロックが原因だと判断できるのは、トリガー、ロック所有者、解放タイミングが一致している場合だけです。
排他ロックを安全境界として扱う
prune はリポジトリのストレージを変更するため、処理中は一貫した状態を必要とします。待機中のバックアップは、通常のプロセス障害という意味で停止しているとは限りません。メンテナンスロックを尊重して待機している可能性があります。最初に確認すべきなのは、バックアップにロックを無視させる方法ではなく、prune が進行しているかどうかです。
共有リポジトリの設計では、ソースデータが異なるホストに属している場合でも、リポジトリ全体のメンテナンスがすべてのクライアントに影響するため、メンテナンスの所有者を1つにする必要があります。
prune のログが進み、リポジトリ I/O が継続しているなら、ロックを維持したままジョブを完了させます。ジョブが本当に停止している場合は、所有ホストから正常に停止し、クリーンな終了を待ちます。prune がまだ書き込み中に別のクライアントからロックを削除すると、制御された待機が安全でない同時実行に変わります。
ロックを回避せずに待機中のバックアップを復旧する
最も影響の少ない対処は、prune の完了を待つことです。バックアップに制限付きの再試行ポリシーがある場合は、排他ロックが消えた後に再試行させます。prune を停止する必要がある場合は、所有ホスト上のサービスマネージャーまたはプロセス監視ツールを使用し、シャットダウンを待ってからロック一覧が変化したことを確認し、その後バックアップを再起動します。
保持設定をホスト単位に適用することはできますが、物理的な領域回収は依然としてリポジトリ上の処理です。ホスト単位の保持ポリシーは、誤ったスナップショットが選択されるのを防ぎますが、無関係なバックアップクライアントに対して同時に prune を安全に実行できるようにするものではありません。
通常のロックを使用して、待機中のバックアップを再試行します。完了すれば、確認した原因に合った修復です。別の prune がすぐに開始される場合は、重複したメンテナンススケジュールを無効にします。排他ロックがないのにバックアップが停止し続ける場合は、再試行回数を増やすのをやめ、バックエンド、ネットワーク、ソーススキャン、またはプロセスの診断に戻ります。
元の重複実行を再テストし、境界を定義する
すべてのログを取得できる管理された時間帯に実施します。通常のバックアップを開始し、計画されたメンテナンスコントローラーを起動して、安全でない重複実行が発生しないことを確認します。続いて、prune を先に実行する想定の順序でも繰り返し、設定されたポリシーに従ってバックアップが待機または終了し、ロックの解放後に正常終了することを確認します。
中断された prune によってリポジトリが別の運用状態になった場合は、その後のすべての失敗を通常の競合として扱うのではなく、prune 中断時の診断に従ってください。
元の重複実行が予測どおりに処理され、バックアップが後で完了し、prune が正常終了し、サンプルスナップショットを復元できれば、復旧は成功です。ロックが更新または解放されない場合、複数のホストがメンテナンスを繰り返し開始する場合、またはリポジトリチェックで破損が報告される場合は、エスカレーションしてください。これらの結果は、実行中の prune だけが原因であるケースを超えています。
おすすめ商品
サポートとヒント
もっと読む
ロックの競合を避けて Restic のバックアップ、Forget、Prune ジョブをスケジュールする方法
頻繁なバックアップ、対象を限定した保持、物理的なプルーニング、チェック、再試行、リストア検証を分離した、完全なマルチホスト対応Resticスケジュール。
Resticのプルーニングジョブによってスケジュール済みバックアップがブロックされるのを防ぐ方法
共有Resticリポジトリ向けの予防計画。バックアップの実行時間帯とプルーンを分離し、ロック、再試行、アラートを維持します。
アクティブなバックアップを中断せずに古いResticロックを解除する方法
アクティブなバックアップを保護し、古い状態のみを削除して、通常のスケジュールで復旧を確認する、影響を最小限に抑えたResticのロック解除ワークフロー。
