増分履歴を壊さずにUSBバックアップリポジトリを新しいマウントパスへ移動する方法
USBバックアップリポジトリを新しいマウントパスへ移動する場合、リポジトリ自体を完全な状態で維持し、バックアップジョブを意図的に再接続すれば安全です。
危険なのは、新しいパスを新しい保存先として扱い、バックアップアプリケーションに古いリポジトリの隣へ空のリポジトリを初期化させてしまうことです。ラベル、マウントルール、ディレクトリ構成を変更する前に、物理ファイルシステムの識別情報、リポジトリのルート、ツールで確認できる場合はリポジトリID、暗号化情報、ジョブ設定、最後に使用可能だった復元ポイントを記録してください。その後、既存のリポジトリを一つの単位として移動または再マウントし、次の書き込みを行う前に、アプリケーションが過去の履歴を認識していることを確認します。
パスを変更する前に既存のリポジトリを記録する
現在のマウント元、ファイルシステムのUUIDまたはラベル、リポジトリディレクトリ、ジョブ名、暗号化キーまたはパスワードの保存場所、バックアップツールで確認できる場合はリポジトリ固有の識別子を保存します。基準情報として、最近のスナップショットまたはアーカイブをいくつか一覧表示しておきます。
Kopiaでは、リポジトリの作成と既存のリポジトリへの接続が分けられています。これは、マウントパスを移動する際に最初に確認すべき重要な違いです。
マウントパスだけに頼らず、以前の履歴を特定できる状態になるまで移動を開始しないでください。記録したのがパスだけの場合、後から別のUSBディスクを同じ場所にマウントすると、正しいものに見えてしまう可能性があります。
リポジトリ全体を一つの完全な単位として移動する
リポジトリファイルを移動する前に、バックアップジョブ、およびプルーニング、圧縮、検証、復元の各処理を停止します。インデックス、設定、パック、ロック、そこに保存されたキー、ツール固有のメタデータを含め、リポジトリのルート全体をコピーまたは再マウントしてください。
Borgでは、リポジトリをバックアップデータとリポジトリメタデータで構成される構造化されたトランザクションストアとして説明しています。そのため、アーカイブのように見えるファイルだけをコピーする方法は、安全な移行手段ではありません。
新しいパスで読み取り専用の一覧表示またはチェックに成功するまで、元のリポジトリは変更せずに保持してください。ツールが同じリポジトリ識別子として扱う場合、通常の書き込みで元のインスタンスとコピーの両方を開くことは避けます。
新しい履歴を初期化せずに保存先のパスを変更する
既存のジョブまたはリポジトリ接続を、新しいファイルシステムパスに更新します。画面に「作成」と「接続」、「インポート」、「再リンク」、「既存を使用」などの選択肢がある場合は、既存リポジトリを使用する項目を選び、保存する前に保存先を確認してください。
Duplicatiのメンテナーは、既存のストアを移動した後、ジョブのデータベースが移動先のストアを参照していれば、保存先を編集して続行できると説明しています。
アプリケーションが空の保存先を初期化するよう直ちに求めてきた場合は、キャンセルしてください。これは、古いリポジトリをまだ認識できていない証拠です。初期化すると別の履歴が作成され、後で整理する際に区別が難しくなる可能性があります。
リポジトリの移動を検知するツールもある
バックアップクライアントが記憶しているのは、リポジトリの内容だけとは限りません。ローカルキャッシュがリポジトリの識別情報と以前の場所を関連付けている場合、同じリポジトリが新しい場所に現れると、明示的な承認を求められることがあります。
Duplicacyのマウントパス移行事例では、移動したリポジトリを再関連付けする方法が中心となっており、リポジトリパスの変更を新規初期化ではなく再リンクとして扱うべき理由が分かります。
リポジトリの識別情報、想定されるスナップショット、暗号化状態、USBファイルシステムが一致していることを確認してから、移動を承認してください。間違ったディスクに対して警告が表示された場合は、ソフトウェアが慎重すぎるという意味ではなく、作業を中止すべきサインです。
USBファイルシステムに安定したマウント識別情報を設定する
リポジトリが認識されたら、適切な永続的識別子を使って、物理USBファイルシステムを管理者が所有する固定パスに割り当てます。スケジュールされたバックアップを、/dev/sdXの検出順序やデスクトップセッションのマウントディレクトリに依存させないでください。
Linuxのツールでは、安定したラベルまたはUUIDでファイルシステムを特定できます。これにより、通常のデバイス列挙順序が変わっても、同じリポジトリパスを維持できます。
意図的にファイルシステムのラベルを変更する場合は、バックアップを再有効化する前にマウントルールを更新してテストしてください。人間が読みやすいラベルが変わっても、バックアップアプリケーションが同じリポジトリルートを認識し続ける必要があります。
移動後に初めて書き込む前に履歴を検証する
USBディスクを新しいパスにマウントし、既存のリポジトリに接続して、過去のスナップショットを一覧表示します。最新の復元ポイントを確認し、小さなファイルを一つ一時ディレクトリに復元してください。その後で初めて、新しいバックアップを実行します。
resticのユーザー事例では、ローカルリポジトリを名前変更して再指定できると説明されており、リポジトリの履歴は一つのマウントパスの表記ではなく、リポジトリの内容に属することが分かります。
古いスナップショットを引き続き参照でき、テスト復元が成功し、新しいバックアップが同じ履歴に追加されれば、移動は完了です。計画外のパス変更が発生した場合は、リポジトリを意図的に移動するのではなく、関連するZimaSpaceの記事再起動後にUSBマウントパスが変わる場合を参照してください。
よくある質問
USBボリュームのラベルを変更すると、バックアップ履歴は自動的に壊れますか？
必ずしもそうではありません。マウントルールまたはバックアップジョブが保存先の識別情報の一部としてそのラベルを使用しており、想定されたパスにリポジトリが見つからなくなった場合に問題になります。
最新のバックアップフォルダーだけを新しいパスにコピーすべきですか？
リポジトリベースのバックアップツールでは、すべきではありません。インデックス、カタログ、パックファイル、キー、古い復元ポイントは相互に依存している可能性があるため、リポジトリ全体の構成をまとめて保持してください。
古いリポジトリのコピーと新しいリポジトリのコピーを同時にオンラインにしてもよいですか？
古いコピーはロールバック用として保持して構いません。ただし、バックアップツールが明示的にそのワークフローをサポートしていない限り、一つのリポジトリ識別情報を共有するクローンに対して、独立して書き込むことは避けてください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
