再起動後、回転式USBバックアップディスクの1台だけマウントパスにサフィックスが付くのはなぜですか？
ローテーションして使用するUSBバックアップディスクは、優先されるラベルベースのディレクトリがすでに使用中、重複している、または別の自動マウント機構によって割り当てられている場合、末尾にサフィックスが付いたマウントパスになることがあります。
バックアップのローテーションでは、似たディスクを複数使用することがよくあります。また、管理者が利便性のためにファイルシステムを複製したり、同じボリュームラベルを再利用したりする場合もあります。再起動後は、検出順序、デスクトップの自動マウント、古いマウントディレクトリ、重複したラベル、競合するfstabエントリなどにより、あるディスクがBACKUPではなくBACKUP_1のようなパスに現れることがあります。ディスク自体は正常でも、バックアップジョブが誤ったディレクトリを対象にしている可能性があります。ファイルを移動したりパスを編集したりする前に、ディスクの識別情報を確認してください。
予期しないパスの背後にあるファイルシステムを特定する
接続されているローテーションディスクごとに、実際のデバイス、ファイルシステムUUID、ラベル、シリアル番号またはby-idパス、マウント元、マウント先、ファイルシステムの種類、オプションを記録します。
Linuxのfindmntコマンドはマウント先をアクティブなソースに対応付けます。これにより、誤解を招くフォルダー名を意図したバックアップディスクと取り違えるのを防げます。
サフィックス付きのディレクトリが正しいUUIDに属している場合、問題はパスの割り当てです。別のディスクに属している場合は、誤ったローテーションセットに書き込まれる前にバックアップを停止してください。
重複したファイルシステムラベルまたはUUIDを確認する
現在オフラインのディスクについて記録がある場合は、それらも含め、ローテーション対象の全ディスクでUUID、ラベル、PARTUUID、シリアル番号、by-id名を比較します。
ArchWikiでは、ラベルはUUIDより重複しやすいと説明されています。そのため、複数のバックアップディスクが意図的に同じ分かりやすい名前を共有している場合、ラベルだけに依存した自動マウントは危険です。
ファイルシステムを複製すると、UUIDも複製されることがあります。無人でローテーションを行う前に、各ファイルシステムに固有の識別情報を割り当て、どの物理ディスクがどのIDを所有しているかを記録してください。
自動マウント機構がサフィックスを追加する理由を理解する
fstabやバックアップサービスが動作する前に、デスクトップセッション、NASサービス、UDisksヘルパー、リムーバブルメディア管理サービスなどがディスクをマウントしていないか確認します。
Filesystem Hierarchy Standardでは、複数のデバイスに似たマウント場所が必要な場合、リムーバブルメディアのマウントディレクトリに数字を追加できると定められています。
サフィックスの正確な付与ルールは自動マウント機構によって異なりますが、診断の原則は同じです。デバイスが接続された時点で、優先パスが使用できないか、または曖昧だったのです。
優先マウントディレクトリがすでに使用されていないか確認する
ディスクを接続する前に、想定されるディレクトリを調べます。別のマウント、ディスクがない間に誤って書き込まれたファイル、バインドマウント、または古いプロセスの作業ディレクトリが存在しないか確認してください。
Oracleのリムーバブルメディアに関するガイダンスでは、メディアのラベルがマウントパスの名前に使用されると説明されています。複数のメディアが同じラベル由来のパス名を示すと、衝突が発生します。
使用中のディレクトリにバックアップがルートファイルシステムへ誤って書き込まれていないか確認するまで、削除しないでください。不要なファイルと確認できたデータは、管理された復旧手順で移動します。
ローテーションディスクごとに固定のfstabマウントポイントを定義する
安定した方針を選びます。各物理ディスクに専用の固定ディレクトリを割り当てるか、ローテーションスクリプトで、識別情報を確認したうえで現在選択されているUUIDを1つの管理下にあるバックアップパスへマウントします。
Red Hatでは、UUIDと固定マウントポイントを指定したfstabによる永続マウントについて説明しています。これにより、無人運用のパスから検出順序や分かりやすいラベルの衝突を排除できます。
同じ対象ディレクトリを奪い合う複数のアクティブなfstabエントリを作成しないでください。ローテーションのワークフローでは、次のディスクを接続する前に、古いディスクがアンマウントされていることを確認する必要があります。
検証済みのマウントに依存してバックアップを開始する
USBの検出とマウントが完了する前にスケジューラーが起動していないか確認します。UUID、マウントポイント、書き込み可能な状態、想定されるマーカーファイルを確認する事前チェックを追加してください。
Debianのsystemdマウントに関するドキュメントでは、fstabエントリがsystemdのマウント依存関係になると説明されています。これにより、バックアップサービスは任意のディレクトリではなく、特定のマウントを待機できます。
ディレクトリの存在だけを確認する方法では不十分です。ディスクがない場合でも、空のディレクトリ自体は存在するためです。マウントされたファイルシステムの識別情報を検証してください。
再起動とディスク交換を含むローテーション全体をテストする
各ディスクについて、正常なアンマウント、取り外し、再起動、再接続、識別情報の検証、テスト用の書き込み、バックアップのドライラン、読み戻し検証を実施します。想定されるパスとUUIDを記録してください。
ZimaSpaceのUUIDマウントと安定したアプリパスに関する記事では、より広範な固定パス設計を扱っています。この記事では、リムーバブルバックアップディスクを複数ローテーションすることで生じる衝突に焦点を当てています。
繰り返し再起動とディスク交換のテストを行った後、すべてのローテーションディスクが記録されたパスに対応し、想定されるUUIDが存在しないか別の場所にマウントされている場合にバックアップが実行されなければ、問題は解決しています。
おすすめ商品
サポートとヒント
もっと読む
Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか？
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。
Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。
リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか？
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。
