Resticリポジトリのメンテナンスワークフロー：チェック、プルーニング、コンパクト化、復元テスト

エヴァ・ウォン

IceWhale author

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

Restic Repository Maintenance Workflow: Check, Prune, Compact, and Test Restore - Zima Store Online

安全な方法は、ゲートスケジュール、健全性チェック、保持対象のプレビュー、再パックのためのプルーニング、再チェック、分離したリストアを、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。

1台以上のホームサーバーホストで使用しているResticリポジトリでは、実務上のリスクは、バックアップを妨げたり、容量の再利用を復旧可能性と取り違えたりせずに、Resticリポジトリを維持する必要があることです。現在の識別情報と復旧ポイントを記録し、最も影響の少ない判別から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーだけが危険にさらされる場合は停止します。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーション境界に達した時点でのみ終了します。

リポジトリ全体のメンテナンスウィンドウを開く

リポジトリにアクセスできるすべてのホストで、バックアップ、forget、check、copy、pruneのスケジュールを一時停止します。稼働中のロック所有者が残っていないことを確認し、ResticのバージョンとリポジトリIDを保存します。認証情報は、シェル履歴やログにさらさずにテストしてください。リポジトリのメンテナンスは、コンテナごとの作業ではなく、共有状態を1回変更する作業です。

以前のクラッシュによってロックが残っている場合は、ロックを解除する前に、ZimaSpaceのクラッシュ後にResticリポジトリがロックされた場合の手順に従ってください。ロックは所有権の証拠です。記載されたプロセス、ホスト、タイムスタンプ、バックエンドの動作によって操作が終了していると確認できた場合にのみ、ロックを削除してください。

バックエンドの空き容量、inodeまたはオブジェクトの上限、書き込み権限、ローカルキャッシュまたは一時領域を確認します。ストレージパスが不安定な場合、変更が必要な削除を不変保持が妨げている場合、または別の書き込み元を一時停止できない場合は停止してください。

構造をチェックし、リポジトリデータをサンプリングする

restic snapshotsと通常のrestic checkを実行し、出力と終了ステータスを保存します。次に、リポジトリのサイズと帯域幅に応じて、--read-dataまたはサポートされているデータ読み取りサブセットをスケジュールします。構造のみの成功では、すべてのパックが読み取り可能であることは証明できません。

Resticコミュニティの議論では、通常のcheck、prune、rebuild-indexの役割を区別し、インデックスの再構築は通常の予防保守ではないと説明しています。checkが遅いからといって、rebuild-indexを実行したりパックファイルを削除したりしないでください。復旧コマンドは、診断済みの不整合に対してのみ使用します。

checkでパックの欠落、ハッシュの不一致、バックエンドの読み取り失敗、またはインデックスの不整合が報告された場合は、pruneの前に停止します。リポジトリを保護し、安定したパスを通じて失敗した読み取りだけを再実行し、コピー上で文書化された復旧手順へエスカレーションします。

保持対象をプレビューしてからpruneと再パックを行う

意図したrestic forgetポリシーを--dry-run付きで実行し、ホスト、パス、タグごとに保持・削除されるスナップショットを確認します。必要な復旧ポイントが一覧に残る場合にのみ、forgetを確定してください。可能であれば、実験的なポリシー変更の対象外に、最近検証済みのスナップショットを1つ残します。

Resticでは、「compact」は独立したコマンドではありません。pruneが参照されていないデータを削除し、必要に応じてリポジトリファイルを再パックします。現在のトラブルシューティングガイドでは、別の破壊的な試行を行う前に解決すべき空き容量やロックの問題を含む、Restic pruneの失敗について説明しています。

バックアップの同時実行なしでpruneを1回実行し、完全なログを保存します。失敗した場合は、盲目的に再実行したり、一時ファイルに見えるオブジェクトを削除したりしないでください。ロック、空きワークスペース、バックエンドの権限、最後に完了したフェーズを再確認し、診断のためにリポジトリの状態を保持します。

Featured

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

ZimaCube2

再チェックして分離したリストアを実行する

pruneが成功したら、restic checkを再度実行し、計画したデータ読み取り範囲を完了します。スナップショット数、リポジトリサイズ、エラーをメンテナンス前のベースラインと比較します。保持されたスナップショットがデータを引き続き参照している場合、容量が見積もりどおりに減らなくても失敗ではありません。

最近のスナップショットと、より古い代表的なサブセットを空のディレクトリにリストアします。ファイルの内容、権限、タイムスタンプ、シンボリックリンク、アプリケーションレベルのアーティファクトを1つ確認してください。マウントや一覧表示だけでは、リストアテストにはなりません。

prune後のcheckに合格し、リストアしたデータが使用可能で、新しい小規模バックアップを作成してリストアできる場合にのみ、スケジュールを再開します。新たな破損、バックエンドエラーの繰り返し、または不完全なpruneが発生した場合は、複数のホストによる再度の書き込みを許可する前にエスカレーションしてください。