スタックを再作成すると、Immichが永続データにアクセスできなくなるのはなぜですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does Immich Lose Access to Persistent Data After Stack Recreation? - Zima Store Online

スタックを再作成した後にImmichが空に見える、またはライブラリを読み取れない場合は、古い永続データが削除されたと考える前に、接続されていないか読み取り不能になっている可能性を確認してください。

コンテナを再作成すると、Composeプロジェクトの識別子、バインドマウントのソース、名前付きボリュームの接続先、ネットワーク共有のマウントタイミング、データを読み取るUID/GIDが変わることがあります。新しく見えるインスタンスが大量の新しい状態を書き込む前に停止し、ホスト上の古いデータベースとメディアのパスを特定して、再作成後のスタックと最後に正常だったマッピングを比較してください。まず既存の状態を再接続することが目的です。状態が実際に失われた、または破損していると確認できた場合にのみ、バックアップからの復元を行います。

新しいインスタンスを停止し、古いデータがまだ存在することを確認する

再作成直後にセットアップウィザードが表示される、タイムラインが空になる、外部ライブラリが見つからないといった現象は、永続化に関する警告です。新しいファイルをアップロードしたり、空の新しい設定を受け入れたりする前にImmichを停止し、ホスト側のデータベースとメディアの場所を調べてください。新たな書き込みが行われると、後でパスを比較しにくくなることがあります。

古いディレクトリについて、想定されるファイル数、更新日時、データベースファイルまたはダンプ、元の画像の代表例を確認してください。ホスト上にデータが存在するなら、問題は消失ではなくアクセスまたはマッピングです。所有者を変更したりディレクトリを移動したりする前に、その状態の読み取り専用スナップショットまたはバックアップを作成してください。

想定されたパスで古いデータが見つからない場合は、何かを削除する前にストレージプールとDockerのボリューム一覧を検索してください。判断は二択です。既存の状態を特定して保護できた場合はその状態を使い、完全に利用できない場合はマウント修復ではなく、既知の正常なバックアップを使った復旧に切り替えます。

再作成したマウントを以前のスタックと比較する

覚えているComposeテキストだけでなく、再作成したImmichのサーバーコンテナとデータベースコンテナに実際に適用されているマウントを確認してください。相対バインドパスは別のプロジェクトディレクトリを基準に解決されることがあり、Composeプロジェクト名を変更すると、古い名前付きボリュームを未使用のまま残して新しい名前付きボリュームに接続されることがあります。

マウントの失敗、変更、欠落により、ホスト上には想定データが存在しているのに、コンテナ内では空のディレクトリとして見えることがあります。すべての永続的なImmichパスについて、Dockerボリュームのマウント確認を使い、Source、Destination、マウントタイプ、名前付きボリュームの識別情報を比較してください。ここでの不一致は、新しく初期化されたように見えるインスタンスを直接説明できます。

誤っているマウントマッピングだけを修正し、ボリュームを削除せずにコンテナを作成または起動してください。変更後に想定ファイルが同じコンテナパスに表示されるなら、データはそのままにしてください。マウント一覧が正しいのにアクセスできない場合は、マッピングを維持したまま、別のボリュームを作成するのではなく、ホストストレージの利用可能性と権限を確認してください。

Immichの起動前に外部ストレージがマウントされていたことを確認する

ImmichのデータがHDDプール、NAS共有、統合ストレージ層、その他の外部マウントに保存されている場合は、Dockerがスタックを起動する前に、そのストレージがホスト上で実際にマウントされていることを確認してください。/mnt/photosのようなパスは、実際のデバイスが存在しない場合でも、通常のローカルディレクトリとして残っていることがあります。

コンテナを置き換えてもDockerの永続データが保持されるのは、意図したボリュームまたはバインドマウントが正しく再接続されている場合だけです。基盤となるDockerボリュームの永続化モデルによって、存在しないホストディスクやネットワーク共有が自動的に表示されるわけではありません。そのため、Immich内で同じパスを確認する前に、ホスト上でストレージデバイスと既知のファイルを確認してください。

実際のストレージが存在しない間に、空のマウントポイントへフォールバックファイルが書き込まれていた場合は、その上にデバイスをマウントする前にImmichを停止してください。それらのファイルは個別に整理し、ストレージマウントの起動依存関係またはヘルスチェックを追加してから、スタックを再起動してください。ホストストレージが安定していて、コンテナパスを引き続き読み取れない場合は、権限の確認に進みます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

すべてを書き換えずにUID、GID、ディレクトリ権限を確認する

再作成したスタックでは、以前とは異なる数値ID、ユーザーネームスペース、またはセキュリティコンテキストでサービスが実行されることがあります。マウントが見つからない場合とは異なり、パスは存在し、ホストからファイルも見えますが、Immichのログには権限エラーが表示されたり、想定ファイルを作成できなかったりします。

影響を受けているホストディレクトリの数値所有者、所有グループ、モードビットを、再作成したコンテナ内のユーザーIDと比較してください。まず安全な読み取りをテストし、次に同じマウント配下の使い捨て場所で、元に戻せる書き込みをテストします。どのサービスに書き込み権限が必要で、元のファイルのどれを変更せずに残すべきかが分かるまでは、写真アーカイブ全体に対して再帰的な所有者変更を行わないでください。

問題を説明できる最小限のディレクトリまたはIDの不一致だけを修正し、一度再起動してログを再確認してください。マウントと権限が一致しているのにアクセスできない場合は、ファイルシステムの変更を続けず、再作成時に変わったデータベース接続、環境変数の置換、またはセキュリティ層を調べてください。

元の状態を再接続し、別の再作成で検証する

古いデータベースとメディアのパスが接続され、読み取り可能になったら、Immichを起動して、以前のユーザー、アルバム、人物、代表的なアセットが表示されることを確認してください。ホームページが表示されたからといって修復完了とは判断しないでください。新しく初期化されたデータベースではなく、アプリケーションが元の状態を読み取っていることを確認します。

重要なのは、コンテナは使い捨てにできる一方で、アプリケーションの状態はコンテナのライフサイクル外にある安定したストレージに保持する必要があるという点です。修正後のマウント名とホストパスを文書化し、次回のスタック再作成でも同じデータに接続できるよう、永続的なファイルサーバーストレージの役割を活用してください。

最後に、管理された条件でスタックをもう一度再作成し、最初に行った確認を繰り返してください。同じデータベースとメディアが再作成後、さらにホストの再起動後にも再び表示されて初めて、修正が証明されます。古い状態が再び消える場合、またはデータベースがアクセスエラーではなく破損を報告する場合は、保護したコピーに戻し、マウントの試行を続けるのではなく、データベースまたはバックアップからの復旧に切り替えてください。