Resticのプルーニングジョブによってスケジュール済みバックアップがブロックされるのを防ぐ方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Prevent Restic Prune Jobs From Blocking Scheduled Backups - Zima Store Online

リポジトリごとにメンテナンス担当を1つに割り当て、バックアップクライアントが新しい処理を開始できない時間帯を設けることで、pruneの競合を防止します。

共有ホームサーバーのリポジトリでは、問題は通常、ロックエラーより前に始まっています。複数のホストがメンテナンススケジュールを管理し、1つのバックアップが予想以上に長引いたにもかかわらず、リポジトリ全体のゲートなしでpruneが開始されるのです。この順序を逆にします。pruneを一元管理し、十分な時間を確保し、Resticの外部でジョブを直列化し、スキップや期限超過を通知します。すでに競合が発生している場合は、新しいジョブを停止し、ロック機構を弱めるのではなく、最小限の復旧手順を使用してください。

各リポジトリに1つのメンテナンス担当を設定する

すべてのクライアントとリポジトリ側のサービスで、Resticのメンテナンスコマンドを検索します。forget、prune、check、unlock、通知の担当者を記録します。重複するpruneスケジュールを無効にし、すべてのクライアントを把握できる、リポジトリの認証情報と必要な可視性を持つコントローラーを1つだけ残します。

複数のバックアップを1つのリポジトリに対して調整することはできますが、prune前にすべてのロックを削除することは安全境界を無効にし、スケジュールで防ぐはずだった危険な重複処理を引き起こす可能性があります。

担当者の確認に合格するのは、リポジトリ全体のメンテナンスを開始できるホストが1台だけで、すべてのバックアップクライアントが障害の報告先を把握している場合です。アプライアンスやバックアップラッパーが非表示のメンテナンスを起動できる場合は、自動オプションを無効にするか、続行する前に同じコントローラーへ組み込んでください。

通常の最長実行時間より長いprune時間帯を確保する

最近のログを使って、通常のバックアップの最長時間、最近のpruneの最長時間、クライアントの起動遅延、再試行待ちの処理を確認します。予想される最後のバックアップ完了時刻より後にpruneを配置し、prune自体の通常時における最長実行時間も確保します。1台のホスト上で静かに見えるという理由だけで、深夜0時を選ばないでください。

保持計画では、ホストまたはタグでスナップショットの対象範囲も指定する必要があります。そうすれば、複数ホストの保持によって、1つのメンテナンス担当が管理するリポジトリで誤ったスナップショットが選択されることを防げます。

バックアップが提案した境界を頻繁に越える場合は、バックアップ時間帯を短縮するのではなく、pruneの実行時刻を変更します。pruneの所要時間が空き時間を超えて増加する場合は、物理的な容量解放の実行頻度を下げるか、バックエンドのスループットを調査するか、より長い時間帯を使用します。すべてのジョブが平均時間内に終わることを前提にしたスケジュールでは、予防策は機能しません。

相互排他と、可視性のある再試行ポリシーを適用する

すべてのローカルジョブが従う外部の直列化方法を1つ使用します。systemdのユニット順序、共有ロックラッパー、またはメンテナンスホストが管理するキューなどです。ラッパーは後から開始されたジョブを拒否または遅延させ、Restic独自のロックを維持し、監視で通知できる明確なステータスを書き込む必要があります。

systemdベースのResticスケジュールでは、定期バックアップサービスとpruneサービスを分離できるため、順序、終了ステータス、ログを可視化したままにできます。

再試行間隔と最大遅延時間には上限を設定します。メンテナンスによってブロックされたバックアップは、翌日まで消えるのではなく、時間帯の後に再試行する必要があります。遅延したバックアップによってブロックされたpruneは、通知を出して次に承認された時間帯へ移行させます。自動的な強制unlockを再試行の処理にしてはいけません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

予防ポリシーをテストし、最小限のロールバック手順を維持する

使い捨てのリポジトリまたはサンプルデータセットで、両方の順序をテストします。まずバックアップを開始してpruneを要求し、次にpruneを開始してバックアップを要求します。どちらの場合も、一方のジョブが待機するか、明確に終了し、コントローラーが設定されたポリシーに従って再試行し、実行中のプロセスの下でロックが削除されないことを確認します。

導入後、次回の通常のバックアップ、forget、pruneのログを確認します。メンテナンス後にリポジトリが読み取り専用として動作する場合は、予防ゲートを緩めるのではなく、別途用意されたprune中断時の復旧手順を使用してください。

2サイクルが重複なしで完了し、遅延したジョブが明確に再試行され、時間帯の取り逃しに対して通知が発生し、サンプルの復元が有効であれば、ポリシーは合格です。失敗した場合は、まずpruneの自動実行を無効にし、通常のロック機構を使った通常のバックアップは継続します。測定したワークロードに適合するメンテナンス時間帯がない場合や、バックエンドがpruneを安定して完了できない場合は、エスカレーションしてください。