ロックの競合を避けて Restic のバックアップ、Forget、Prune ジョブをスケジュールする方法

エヴァ・ウォン

IceWhale author

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

How to Schedule Restic Backup, Forget, and Prune Jobs Without Lock Conflicts - Zima Store Online

バックアップを頻繁にスケジュールし、1つのリポジトリコントローラーからforgetを実行し、pruneは専用のメンテナンス時間帯に、より低い頻度で実行します。すべてのホストに3つすべてのジョブを担当させないでください。

共有ホームサーバーリポジトリには、ホストごとの復旧ポイントとリポジトリ全体のメンテナンスという2種類のタイミングが必要です。固定的なインターネット上の例ではなく、実測した所要時間と復旧目標に基づいてスケジュールを作成します。保持とpruneを一元管理し、スナップショットを正しくグループ化し、ユニットの順序を明示し、スキップされたすべてのジョブに再試行とアラートを設定します。保持とロックが意図どおりに機能することを、2サイクルとサンプル復元で確認して初めて、スケジュールは完成です。

すべてのジョブ、担当者、通常時の最長所要時間を一覧化する

リポジトリに触れるすべての操作について、1つの表を作成します。対象はbackup、forget、prune、check、unlock、スナップショット一覧の取得、復元テストです。起動元のホスト、コマンドまたはラッパー、認証情報、直近の通常時および最長所要時間、タイムアウト、再試行ルール、アラート送信先を記録します。バックアップアプリケーションやNASインターフェース内に隠れているジョブも含めてください。

共有リポジトリには、クライアントごとに1つずつ用意するのではなく、リポジトリレベルのメンテナンスが必要です。実用的な複数ホストでのRestic運用方法では、リポジトリごとにforget、prune、checkを1回だけ実行し、対象となるホストとパスの保持設定をまとめます。

重複するメンテナンスジョブは、1つのコントローラーに統合します。ソースへのアクセスに有利な場合はホストごとのバックアップ担当を維持しますが、各ホストからコントローラーへ開始状態と完了状態を必ず報告させます。実測した所要時間や担当者がないジョブは、そのジョブを中心にメンテナンス時間帯を設定する前に観測してください。

まずバックアップ頻度を決め、その後にforgetの範囲を設定する

各ホストのバックアップ頻度は、失っても許容できる変更量と、通常のバックアップにかかる時間に基づいて決めます。大規模なソーススキャンがネットワークやストレージで競合する場合は開始時刻をずらしますが、スケジュール表を整然と見せるためだけにジョブを分散しないでください。通常時の最長バックアップ時間を、メンテナンス開始可能時刻の基準にします。

forgetはリポジトリコントローラーから実行し、想定するホスト、パス、タグのグループ化を使って選択内容をプレビューします。カレンダーによる予期しないグループ化により、単純な保持数の解釈から想定するよりも保持処理によって多くの復元ポイントが削除されることがあります。

スケジュール設計では、forgetと物理的なpruneを論理的に分離します。プレビューした保持ポリシーは、バックアップ成功後に実行するか、コントローラーの独立したフェーズで実行できます。一方、pruneにはより長い専用時間帯を割り当てます。1つのコマンドで組み合わせられるからといって、各ホストのバックアップにpruneを付加しないでください。

pruneとcheckをリポジトリ全体の時間帯に配置する

pruneはバックアップより低い頻度で、通常はforgetよりも低い頻度で実行します。物理的なリポジトリのクリーンアップにははるかに長い時間がかかり、他の処理を妨げる可能性があるためです。想定されるすべてのバックアップと保持対象の選択が完了した後に実行します。checkには、リポジトリのサイズとバックエンドの速度に応じて、独自のフェーズまたは時間帯を割り当てます。

systemdのRestic設定では、バックアップとpruneを別々のサービスに分けられるため、スケジューラーは1つの不透明なコマンドを起動するのではなく、それぞれの終了状態を監視できます。

pruneが定期的に時間帯を超過する場合は、バックアップを気付かないまま滞留させないでください。pruneの頻度を下げる、時間帯を広げる、バックエンドのスループットを調査する、または運用要件が合わなくなったリポジトリを分割します。開始条件はアクティブなバックアップがないこと、終了条件はメンテナンスが正常に完了し、リポジトリのロックが解放されていることです。

Featured

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

ZimaCube2

依存関係、再試行、アラートを定義する

時刻の間隔に頼るのではなく、意図した順序を定義します。バックアップユニットが完了を報告し、必要なバックアップの後にのみforgetを実行し、リポジトリが専用時間帯に入った後にのみpruneを実行し、選択したメンテナンスポリシーに従ってcheckを実行します。関連するすべてのユニットが従う共有の外部ゲートを使用します。

systemdのターゲットを使えば、バックアップとメンテナンスの依存関係を、単に異なる時刻に開始するのではなく、順番どおりに完了させることができます。

ロック競合やネットワーク障害に対して上限付きの再試行を設定し、期限を超過した場合はアラートを送信します。遅延したバックアップはpruneを遅らせ、時間を超過したpruneは次回のバックアップを遅らせて担当者に通知します。強制unlockやno-lockオプションは、再試行ポリシーではありません。

2回の完全なサイクルと1回の復元を検証する

タイマーファイルが読み込まれた時点で成功と判断せず、2回の完全なサイクルを監視します。各ソースから想定したスナップショットが生成されること、forgetが意図したグループを保持すること、pruneが時間帯内でのみ実行されること、正常終了後にロックが解除されること、遅延があればアラートに記録されることを確認します。

最新のバックアップだけでなく、保持とpruneの処理を経ても残ったスナップショットからファイルを復元します。これにより、単にジョブのステータスが成功になるだけでなく、スケジュール全体によって利用可能な復旧ポイントが維持されることを証明できます。

2回のサイクルが順序どおりに完了し、どのジョブも通知なしに消失せず、保持されたスナップショットがプレビューと一致し、サンプル復元が正しければ、スケジュールは合格です。保持によって誤ったグループが削除される、pruneを安定して完了できない、またはロック競合が繰り返される場合は、通常のバックアップを維持したままメンテナンス自動化をロールバックします。リポジトリの保護を無効にするのではなく、実測結果に基づいて頻度を調整してください。