Borgリポジトリでは追記専用モードと通常アクセスのどちらを使用すべきですか？
バックアップクライアントの信頼性がリポジトリより低く、別の信頼できるメンテナンス経路が存在する場合は、追記専用を使用してください。それ以外の場合は、通常のアクセスのほうがシンプルで透明性にも優れています。
あるホームサーバーが別のマシンへバックアップを送信する場合、本当の判断基準は、追記専用のほうが安全そうかどうかではありません。侵害されたクライアントによる古いリポジトリデータの回収を防ぐ必要があるか、保持期間のメンテナンスを誰が実行できるか、アーカイブが非表示になったり削除対象としてマークされたりした場合に復旧をどう行うかが重要です。まず認証情報とメンテナンスの所有者を整理し、その後、リポジトリをどちらのモードにするか決める前に、バックアップと復元の両方をテストしてください。
信頼しないマシンと認証情報を明確にする
ソースマシン、リポジトリホスト、SSHキー、サービスアカウント、管理者のIDを一覧にします。通常のバックアップを実行するID、保持期間のメンテナンスを実行するID、リポジトリホストへログインできるIDを区別してください。追記専用が役立つのは、信頼性の低いクライアントがリポジトリの境界で実際に制限されている場合だけです。
リモートの追記専用バックアップサーバーは、クライアントキーが制限付きのBorgコマンドに強制され、通常のシェルやメンテナンス用認証情報を取得できない場合に最も強固になります。
同じクライアントが管理者キーを保管し、圧縮をスケジュールし、リポジトリ設定を編集できるなら、表向きの境界はほとんど手続き上のものにすぎません。リポジトリホスト自体が侵害される可能性がある場合、そのホスト上の追記専用は独立したコピーではありません。誰と誰を分離するのかが脅威マップで明確になるまで、モードを選択しないでください。
Borgのワークフローで追記専用が変更する内容を確認する
使い捨て可能な小規模リポジトリを作成し、自動化で使用する正確なコマンドを実行します。2つのアーカイブを追加して一覧表示し、予定している保持期間コマンドを適用し、クライアントIDで圧縮を試みた後、信頼できるメンテナンスIDに切り替えます。どのデータが復元可能なまま残り、どの操作がクライアントの現在の表示に反映されるだけなのかを記録してください。
追記専用リポジトリでは、削除やプルーンの指示後、ストレージが信頼できるメンテナンスによって解放されるまで、アーカイブがクライアントから表示されなくなる場合があります。この違いは、インシデントが発生する前に理解しておく必要があります。
制限されたクライアントがバックアップを作成でき、保護された履歴を完全に回収できず、信頼できる管理者がトランザクションの状態を確認して必要なアーカイブを復元できる場合にのみ、テストは合格です。オペレーターが非表示のアーカイブを復旧する方法を説明できないなら、バックアップの作成に成功するかどうかにかかわらず、追記専用は本番環境で使用できる状態ではありません。
メンテナンスの担当者に合ったモードを選ぶ
リモートまたは外部に公開されたクライアントからバックアップをプッシュする必要があり、保護された別のIDでメンテナンスを実行でき、圧縮までの遅延をストレージが許容でき、復旧手順を実際に訓練済みである場合は、追記専用を選択してください。そのメンテナンス用認証情報は通常のバックアップクライアントに保存せず、強化された管理者経路からのみ使用します。
リポジトリとクライアントが1つの信頼できる管理境界を共有し、通常の保持期間処理と容量回収を直接実行する必要があり、侵害されたクライアントキーの制限より運用上のシンプルさを重視する場合は、通常のアクセスを選択してください。追記専用の自動圧縮に関する警告は重要です。レビューなしで自動化された信頼済みの圧縮処理を実行すると、侵害されたクライアントが作成した破壊的な指示を完了させる可能性があります。
一方のクライアントグループは信頼でき、もう一方が外部にさらされている場合や、メンテナンスのスケジュールが競合する場合は、リポジトリを分けてください。重複排除の利便性のために、すべてのクライアントを最も安全性の低い共有モデルに合わせて弱めないでください。適切な選択は条件によって異なります。追記専用は特定の認証情報の境界を保護し、通常のアクセスはメンテナンスを直接実行できます。
バックアップ、復元、メンテナンスを1つのサイクルとして検証する
リポジトリを頼りにする前に、運用サイクル全体を実行してください。クライアントから2つのバックアップを作成し、意図した保持ポリシーを適用し、信頼できるIDで結果の状態を確認し、サンプルディレクトリを別の場所へ復元して、予定していたメンテナンス手順を実行します。遅延した容量回収が確認できるよう、前後のストレージ使用量を測定してください。
リポジトリのアクセスモードによって、IDやマウントパスの確認が不要になるわけではありません。Borgが移動後のリポジトリを見つけられない場合は、そのリポジトリパスの診断を追記専用の動作とは分けて考えてください。
スケジュールされたバックアップが動作し、以前のアーカイブを復元でき、メンテナンス用IDで意図的に確認と容量回収を行え、クライアントの再起動後も同じ結果が維持される場合に、モードは合格です。アーカイブの表示が分かりにくい場合、ストレージが安全なメンテナンス時間帯なしに増え続ける場合、または管理者認証情報が実際には分離されていない場合は、テスト用リポジトリに戻してください。
おすすめ商品
サポートとヒント
もっと読む
ロックの競合を避けて Restic のバックアップ、Forget、Prune ジョブをスケジュールする方法
頻繁なバックアップ、対象を限定した保持、物理的なプルーニング、チェック、再試行、リストア検証を分離した、完全なマルチホスト対応Resticスケジュール。
Resticのプルーニングジョブによってスケジュール済みバックアップがブロックされるのを防ぐ方法
共有Resticリポジトリ向けの予防計画。バックアップの実行時間帯とプルーンを分離し、ロック、再試行、アラートを維持します。
アクティブなバックアップを中断せずに古いResticロックを解除する方法
アクティブなバックアップを保護し、古い状態のみを削除して、通常のスケジュールで復旧を確認する、影響を最小限に抑えたResticのロック解除ワークフロー。
