ファイルシステムUUIDでマウントすれば、再起動後にアプリのパスが使えなくなるのを防げますか？

ファイルシステムをUUIDでマウントすると、デバイス名が変わってアプリが別のディスクを参照してしまうのを防げます。しかし、ファイルシステムがアプリの起動前に想定どおりのパスへマウントされることまで保証するわけではありません。

信頼性の高い構成には、一意なファイルシステム識別情報、固定のマウントポイント、検証済みのマウントオプション、サービスの依存関係、安定したホストパスを参照するアプリケーション設定が必要です。UUIDが解決するのは、この一連の仕組みのうち1つのレイヤーです。

UUIDマウントで実際に解決できる問題とは？

/dev/sdb1などのLinuxデバイス名は、デバイスの検出順序によって決まります。UUIDはファイルシステム自体を識別するため、カーネルが別の一時的なデバイス名を割り当てても、システムはそのファイルシステムを特定できます。

続いて、/etc/fstabのエントリで、その識別情報を/srv/mediaなどの任意のディレクトリに割り当てます。基盤となるデバイス名が変わっても、アプリケーションはそのディレクトリを一貫して使用できます。

これにより、デバイスの順序変動から保護できます。詳しいfstabによるディスクマウントガイドでは、UUIDの指定は設定の一部にすぎない理由を解説しています。再フォーマット、UUIDの重複、ドライブの欠落、誤ったマウント先によって、依然として問題が発生する可能性があります。

アプリのパスで、依然として問題が起きる可能性がある箇所

正しいUUIDが設定されていても、アプリがファイルの欠落を報告することがある理由を表にまとめています。ファイルシステムの識別情報から、各マウントやマッピングを経て、アプリケーションに保存された正確な場所に至るまでの経路をたどります。

UUIDを使ったマウントはどのように設定すればよいですか？

ログインセッションによって変わらない、システム管理のマウントディレクトリを選びます。UUIDとファイルシステムの種類を確認し、設定をバックアップして、テスト済みのエントリを追加します。

UUID=8f12-example  /srv/appdata  ext4  defaults,nofail  0  2

ディスクがなくても安全に起動を続けられる場合に限り、nofailを使用します。重要なアプリケーションデータでは、何事もなく起動を続けるより、起動やサービスの失敗が明示されるほうが安全です。

編集後、設定をテストし、マウント元を調べ、アプリの実行に使うのと同じアカウントで権限を確認します。rootでマウントが成功しても、サービスアカウントの権限エラーは防げません。

アプリが早すぎるタイミングで起動するのを防ぐには？

平均的な起動時間に頼らず、サービスがマウントに依存するようにします。マウント順序とsystemdの自動マウントの解説では、明示的な依存関係が重要な理由を説明しています。同じ原則から、起動順序によってホームサーバーのアプリが動作しなくなる理由も分かります。

コンテナスタックは、ホスト側のパスに想定どおりのファイルシステムがマウントされてから起動する必要があります。そうしないと、ランタイムがルートファイルシステム上の空のディレクトリをコンテナにバインドし、アプリがそこで別のライブラリを初期化する可能性があります。

既知のマーカーファイル、想定されるUUID、またはファイルシステムの種類を確認する、起動前チェックを追加します。これにより、誤ったパスでの無言の起動を、明確で復旧可能な失敗に変えられます。

UUIDによるマウントに失敗するとどうなる？

マウントディレクトリは、親ファイルシステム上の通常のディレクトリとして残っています。アプリケーションはそこに書き込めるため、データディスクに空き容量があってもシステムパーティションの容量不足がNASアプリに影響することがあります。

実際のファイルシステムが後からマウントされると、そこにあるファイルはその下に隠れます。それらのファイルはルートボリュームの容量を消費し続け、データファイルシステムのマウントを解除すると再び表示されます。

• マウントを調べる前に、アプリケーションを停止します。
• ディレクトリの内容だけで判断せず、findmntでマウント元を確認します。
• タイムアウトやファイルシステムエラーがないか、起動時とマウントユニットのログを確認します。
• マウントが安全に解除されているときに限り、空のマウントディレクトリを確認してください。
• 実際のアプリケーションデータセットと比較した後に限り、別の場所にあるデータを移動してください。

2つのアプリケーションデータベースを安易に統合しないでください。どちらのインスタンスに書き込みが行われたかを特定し、アプリケーションがサポートする復旧またはインポート手順を使用してください。

コンテナの設定内にもUUIDは必要ですか？

通常は不要です。ホスト側では安定したパスにUUIDでファイルシステムをマウントし、コンテナの設定ではそのホストパスを安定したコンテナパスにバインドします。

たとえば、ホスト側では/srv/mediaにマウントし、コンテナ側では/mediaとして割り当てられます。アプリには/mediaを保存し、永続的なデバイス識別は引き続きホスト側で管理します。

この分離により、ハードウェアの詳細をコンテナの外部に保てます。それでも、マッピングの両側を記録してください。どちらかのパスを変更すると、既存のライブラリが空に見える可能性があります。

再起動後の確実なテストとは？

1. 想定したUUIDが存在し、一意であることを確認します。
2. 設定されたホストパスにマウントされていることを確認します。
3. 読み書き可能な状態、所有権、空き容量を確認します。
4. マウント後にサービスが起動したことを確認します。
5. コンテナまたはバインドマウントのソースパスと宛先パスを確認します。
6. 既知のファイルを開き、アプリから破棄可能なテストオブジェクトを作成します。
7. 今後のマウント失敗や起動前チェックの失敗をアラートで通知します。

カーネル、ストレージ、コンテナランタイム、またはファイルシステムに変更を加えた後は、このテストを再度実施してください。永続性は運用上の特性であり、一度設定すれば済むものではなく、監視が必要です。

よくある質問

ファイルシステムのUUIDは変わることがありますか？

はい。再フォーマットすると新しいファイルシステムが作成され、通常は新しいUUIDが割り当てられます。管理ツールでUUIDを変更することもでき、クローンによって重複する場合もあります。

ファイルシステムのラベルはUUIDと同じくらい安全ですか？

ラベルは読みやすい一方で、重複や編集が起きやすくなります。一意性を確認済みであれば、UUIDのほうが通常、無人マウントで安全です。

なぜ再起動後、アプリが新しい空のライブラリを作成したのですか？

本物のファイルシステムがない状態でアプリが起動し、空のマウントディレクトリか別のフォールバックパスにデータを初期化した可能性があります。

UUIDでマウントすればデバイス名の変動を防げますが、アプリのパスを確実に保つには、依存関係の全体を明示し、テストし、監視する必要があります。