マウントポイントを変更すると、ResticまたはBorgでリポジトリが見つからない、または移動されたと報告されるのはなぜですか？
ResticやBorgでは、設定されたパスが空のディレクトリ、別のファイルシステム、または移動後のリポジトリの場所を指していると、リポジトリを忘れたように見えることがあります。
リポジトリのデータはバックアップディスク上にそのまま残っている可能性があります。しかし、ディスクが接続される前にジョブが空のマウントディレクトリを開いたり、コンテナ内のパスが変更されていたり、古い環境変数を読み込んでいたり、IDが新しい場所にあるBorgリポジトリへのアクセスを拒否したりすることがあります。何かを初期化する前に、マウント元とリポジトリの識別情報を確認してください。間違った空のパスに対してinitコマンドを実行すると、2つ目のリポジトリが作成され、元の問題が分かりにくくなる可能性があります。
設定されたリポジトリパスに何がマウントされているか確認する
スケジュールされたジョブが使用するリポジトリパスを記録し、バックアップディスクのマウント前後でパスを比較します。ファイルシステムのソース、UUID、マウントポイント、利用可能な容量を記録してください。
Linuxのfindmntユーティリティはターゲットパスの背後にあるアクティブなマウントを解決するため、見慣れたディレクトリが実際にはマウントされていないホスト側フォルダーである可能性がある場合の最初の確認に適しています。
パスがバックアップディスクではなくルートファイルシステムに属している場合は、その空のディレクトリに新しいリポジトリやバックアップセットが書き込まれる前に、バックアップサービスを停止してください。
Resticの正確なリポジトリの場所を確認する
-r、--repository-file、またはRESTIC_REPOSITORYに渡されているパスを、現在のマウントポイントと比較します。ラッパースクリプト、NASの設定項目、認証情報ファイル、スケジュールタスクの環境を確認してください。
Resticでは、ローカルリポジトリは、config、data、index、keys、locks、snapshotsを含む特定のディレクトリとして定義されます。そのため、マウントポイントを変更すると、コマンドが開こうとする場所も変わります。
新しいパスでリポジトリが存在しないと表示されたというだけで、restic initを実行しないでください。まず、マウントしたディスク上で元のリポジトリのconfigおよびdataディレクトリを見つけてください。
Borgの移動されたリポジトリ警告には意図的に対処する
BorgリポジトリのURL、リポジトリID、以前の場所、現在の場所、キャッシュパス、セキュリティディレクトリを記録します。同じリポジトリを意図的に移動したことを確認してください。
BorgのFAQでは、リポジトリの移動後に承認を求める理由を説明しています。同じリポジトリIDが新しいパスに現れることは、安全でない置き換えを示している可能性もあるためです。
リポジトリIDとストレージの内容を比較してから、移動を承認してください。複数のリムーバブルリポジトリが変化するパスで接続される可能性がある場合は、警告をグローバルに無効化しないでください。
デバイス順序に依存するパスを永続的なストレージ識別子に置き換える
マウント設定が/dev/sdX、重複したラベル、ファイルシステムUUID、パーティションUUID、またはデバイスIDを参照しているか確認します。ローテーションして使用するすべてのディスクで、識別子が重複していないか比較してください。
ArchWikiでは、カーネルが割り当てるデバイス名やラベルは検出順序によって変わる可能性があるため、UUIDによって名前の衝突を減らせると説明しています。
ただし、安定した識別子でも、意図した固定マウントディレクトリに対応付けられている必要があります。UUIDはディスク順序の変動を防ぎますが、バックアップジョブに以前のパスが残っている場合、そのパスは更新されません。
コンテナとバインドマウントのパス変換を確認する
コンテナ化されたRestic、Borg、またはバックアップUIの場合は、ホストのマウントポイント、バインドマウントのソース、コンテナ内のリポジトリパスを比較します。保存済みのcomposeファイルだけでなく、実行中のコンテナを確認してください。
Dockerのドキュメントでは、バインドマウントはホスト上の正確なパスに依存すると説明されています。そのため、ディスクを/mnt/backup-aから/media/backup-aへ移動すると、コンテナが空のディレクトリを参照したままになる可能性があります。
ホスト上では安定したハードウェアパスを使用し、コンテナには1つの安定したパスを公開してください。固定マッピングを利用できる場合は、ホスト固有のリムーバブルメディアのパスをリポジトリ設定に直接保存しないでください。
バックアップサービスがマウントを待機するようにする
起動時刻とサービスの開始時刻を比較します。バックアップスケジューラー、コンテナ、リポジトリUI、またはメンテナンスタスクがアクセスを試みる前に、マウントが完了していることを確認してください。
Red Hatの永続マウントに関するガイダンスでは、fstabで固定マウントを定義することを推奨しており、これをサービスの依存関係や起動前の検証と組み合わせられます。
リムーバブルバックアップディスクにはnofailの起動オプションが適している場合もありますが、必要なファイルシステムが存在しない場合は、バックアップサービスが起動を拒否するようにしてください。
バックアップを実行する前に既存のリポジトリへ再接続する
スケジュールを停止し、意図したファイルシステムを固定パスにマウントして、リポジトリの構造を確認します。その後、読み取り専用で開くかスナップショットを一覧表示し、書き込みを有効にする前に小規模なリポジトリチェックを実行してください。
ZimaSpaceのUUIDに基づく安定したアプリパスに関する記事では、一般的なマウントチェーンを説明しています。この記事では、パス変更後のリポジトリの識別情報とバックアップツールの安全性に焦点を当てています。
再起動とディスクのローテーションテストを繰り返した後も、意図したパスで同じリポジトリIDとスナップショット履歴を開け、空のマウントディレクトリに新しいリポジトリが作成されなければ、問題は解決しています。
よくある質問
Resticのリポジトリを別のマウントポイントへ移動できますか？
完全なリポジトリをそのまま移動し、すべてのジョブが新しい場所を参照するようにすれば可能です。Resticは、コマンドに指定されたパスまたはバックエンドでリポジトリを識別します。
リポジトリのデータが変わっていないのに、なぜBorgは警告するのですか？
Borgはセキュリティ対策として、リポジトリの識別情報と以前の場所を記録します。同じIDが別のパスに現れた場合は、意図的に承認する必要があります。
新しいパスでリポジトリを初期化すべきですか？
いいえ、古いリポジトリが存在しないことを確認するまでは初期化しないでください。空のマウントポイントを初期化すると、元のリポジトリに再接続されるのではなく、別のリポジトリが作成されます。
おすすめ商品
サポートとヒント
もっと読む
Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか？
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。
Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。
リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか？
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。
