新しいストレージへリポジトリを移行するためのBorg Backup移行ガイド
安全なアプローチは、書き込みを静止し、バージョンに適した方法でコピーまたは転送し、保存先を検証してから、ロールバック可能な状態で切り替えるという一連の確認可能なゲートとして扱うことです。単一のコマンドではありません。
ローカル、NAS、またはSSHでアクセスできるストレージ上のBorgBackupリポジトリでは、分岐や密かに不完全なコピーを作成せずにBorgリポジトリを移動する必要があることが、実際のリスクになります。現在の識別情報と復旧ポイントを記録し、影響の最も小さい判別から始め、別の変数を変更する前に合否の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが1つしかなく、それが危険にさらされる場合は中止します。以下のワークフローは、元のワークロードが正常に完了するか、証拠がエスカレーション境界に達するまで終了しません。
コピー前にリポジトリの契約を記録する
Borgのバージョン、リポジトリURL、リポジトリID、暗号化モード、鍵の場所、パスフレーズの復旧手順、アーカイブ一覧、サイズ、空き容量、追記専用設定、書き込み可能なすべてのクライアントまたは自動化ジョブを保存します。リポジトリはローカルキャッシュだけでは復旧できず、暗号化されたリポジトリは保存先の外部にある鍵マテリアルに依存する場合があります。
ZimaSpaceの記事にある失われたBorgキャッシュの復旧ガイドでは、再構築可能なキャッシュ状態と、失われた鍵またはリポジトリの破損を区別しています。移行前にこの確認を行い、古いストレージを失った後になって初めて鍵の問題が判明する事態を避けます。
これが同じリポジトリのバイト単位の移設なのか、新しく初期化したリポジトリへの転送なのかを決めます。利用できる方法はBorgのバージョンと形式によって決まります。Borg 1とBorg 2のコマンド例を混在させたり、リポジトリIDを変更すべきだと思い込んだりしないでください。
書き込みを静止し、一貫したソースポイントを作成する
タイマー、cronジョブ、コンテナ、リモートクライアントを無効にし、Borgプロセスやリポジトリロックがアクティブでないことを確認します。コピー前にborg listと、適切なborg checkを実行します。ソースがチェックに失敗した場合は、その状態を保持して原因を診断し、不確実な状態を保存先に複製しないでください。
Super Userの議論では、重複排除されたBorgリポジトリが変更されている間にrsyncで稼働中のリポジトリをコピーするリスクが強調されています。安全なルールは、書き込みを静止したリポジトリをコピーするか、すべてのBorg書き込みを停止した後に取得したファイルシステムスナップショットを使用することです。これにより、インデックス、セグメント、ノンス状態、データが同じ時点のものになります。
保存先の検証が完了するまで、バックアップスケジュールを停止したままにします。停止時間が長すぎる場合は、リポジトリがアイドル状態の間に初回コピーを行い、書き込みを停止してから最終同期を実行します。切り替え中にソースと保存先がそれぞれ独立したバックアップを受け入れる状態には、決してしないでください。
Borgのバージョンがサポートする方法でコピーする
同じリポジトリの移設では、適切なローカルまたはリモートのコピー ツールを使って、すべてのファイル、権限、スパースファイルの動作、所有権を保持し、エラーログを確認します。見かけ上サイズの大きいデータディレクトリや選択したアーカイブだけでなく、リポジトリのルートを単位としてコピーします。最終同期後はソースを変更しないでください。
新しいリポジトリまたは形式の移行では、インストールされているBorgのバージョンと暗号化計画がサポートしている場合に限り、転送機能を使用します。Server Faultの回答では、Borgリポジトリの転送はBorg 2に関連するリポジトリ間の転送方法であり、Borg 1のファイルシステムコピーとは互換性がないと説明されています。
コピー後は、まず保存先をクライアントに読み取り専用でマウントまたは公開します。リポジトリID、鍵へのアクセス、権限、形式に予期しない点がある場合は停止して保存先を修正し、コピー済みのデータに対して「初期化」を実行したり、認識させるために修復を実行したりしないでください。
アーカイブを検証し、クライアントを切り替えて、ロールバックを維持する
保存先でBorgのlist、info、および適切なリポジトリとアーカイブのチェックを実行します。最近のアーカイブと古いアーカイブからカナリアファイルを別のディレクトリに抽出し、内容、メタデータ、権限を比較します。自動化で使用するものと同じBorgバイナリとリモートパスでテストします。
1台のクライアントを新しいURLに更新し、Borgが必要と判断したキャッシュ状態だけを消去または再構築して、小さなテストアーカイブを作成します。そのアーカイブから復元し、すべてのクライアントが新しい場所を使用するまで、プルーニングまたはコンパクトのスケジュールが無効のままであることを確認します。
アーカイブの一覧が一致し、チェックに合格し、2つの復元が使用可能で、再起動またはスケジューラーの再起動後に新しいバックアップが成功すれば、切り替えは合格です。少なくとも1回の通常サイクルが完了するまでソースを読み取り専用で保持し、ロールバック期間が過ぎてから削除します。ソースと保存先のチェック結果が異なる場合は、エスカレーションしてください。
おすすめ商品
サポートとヒント
もっと読む
Resticリポジトリのメンテナンスワークフロー：チェック、プルーニング、コンパクト化、復元テスト
Resticには個別のcompactコマンドはありません。pruneが再パッキングを実行します。ロックと空き容量を確保し、完了後に再確認して、最後に分離環境で復元テストを行ってください。
壊れた、または放置されたバックアップ履歴からのTime Machine NAS復元ガイド
古いバンドルはそのままにしてください。修復するか新しいチェーンを作るかを決める前に、NASアクセス、宛先ID、イメージの損傷、放棄された履歴を切り分けてください。
ホームNASのスナップショット保持レビュー チェックリスト
有用な保持レビューでは、履歴を削除する前に、各スナップショット階層を復元ニーズ、担当者、容量予算、レプリケーション境界に関連付けます。
