元のデータが明らかに失われたわけではありませんでした。ZimaOS をリセットした後も RAID6 は存在しており、次のようなディレクトリも残っていました。 upload, pgdata, thumbs, profile、および encoded-video 以前の状態のままで存在していました。問題は、再インストールした Immich スタックが、以前の写真カタログを復元できる形で古いデータベースやライブラリの状態に接続されていなかったことでした。
最も安全な元の内容の助言は、以前の upload フォルダーと pgdata フォルダーをまだ削除したり移動したりしないでください。 Immich は、ディスク上に画像ファイルがあることを確認しただけでは、完全なカタログを再構築しません。データベースには、ファイルパス、ユーザー、アルバム、メタデータ、アプリケーションの状態が保存されています。現在の Immich v3 のドキュメントでも、この関係が明確に示されており、アセットファイルとデータベースの両方をバックアップすることが推奨されています。
まず、実際の RAID マウントパスを確認する
元の内容で使用されていたのは次のコマンドです。
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)そして、次の結果が見つかりました。
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadこれにより、以前の Immich フォルダーが RAID 上に残っていることが確認されました。
/media/ZimaOS-HD → /DATA では、Immich が OS ドライブを使用していることは証明できなかった
ユーザーが不安を感じたのは、次の表示でした。
/media/ZimaOS-HD -> /DATAしかし、コミュニティは、これは ZimaOS のマウントとシンボリックリンクの関係だと正しく説明しました。これが存在していても、Immich コンテナが実際に使用しているホストパスは分かりません。
Docker の実効マウントを確認する
スレッドでは次の確認が推奨されていました。
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'スクリーンショットや古い記憶が実行中のコンテナ設定を反映していると決めつけるよりも、こちらの方が確実です。
以前の pgdata は以前の写真ファイルと同じくらい重要
再インストール時に古いデータベースではなくまったく新しいデータベースが初期化された場合、ファイルが残っていても Immich は空のように表示されることがあります。
現在の Immich では UPLOAD_LOCATION と DB_DATA_LOCATION を使用します
現在の Immich v3 の Compose では、ホスト上のアセットの場所と Postgres の場所を分離しています。 UPLOAD_LOCATION および DB_DATA_LOCATION。アップストリームでは、データベースパスにネットワーク共有を使用することはサポートされていないと明記されています。
現在の Immich のストレージモデルを使用してください。
バージョンをまたいで稼働中の古い pgdata ディレクトリを再接続するより、データベースバックアップの方が安全です
ソース環境は Immich v2.7.2 でした。現在の Immich は v3 です。バージョンをまたいで復旧する場合、古い Postgres のデータディレクトリを新しいデータベースイメージに単純に接続できると想定するよりも、アップストリームのデータベースバックアップおよび復元ワークフローを使用する方が安全です。
現在の Immich のバックアップおよび復元プロセスを参照してください。
Immich の内部アセットフォルダーを手動で並べ替えないでください
現在の Immich のドキュメントでは、次のようなフォルダーについて警告しています。 library, upload, thumbs, profile、および encoded-video アプリケーションによって管理されています。Immich の背後にある個々のファイルを移動または削除すると、アセットが見つからなくなったり、追跡対象外になったりする可能性があります。
ソースユーザーは復旧の成功を確認していません
コミュニティのメンバーは、単一の親マウントを含む複数のマッピング方法を提案しましたが、jerlo は最終的にその課題を保留し、別のシステムで最初からやり直しました。そのため、このフォーラムでは、特定のパスマッピングを最終的な解決策として認定していません。
現在の Immich は、すべての子フォルダーを手動でマッピングするよりも、管理対象のアップロードルートを優先する
元のスクリーンショットでは、手動でマッピングされていました。 upload, thumbs, profile, library, encoded-videoとバックアップを1つずつ。現在の上流 Compose では、ホスト側の設定は次を中心に構成されています。 UPLOAD_LOCATIONで、Immich がそのルート配下の内部子ディレクトリを管理する構成です。
新しい Immich リリースで再構築する場合は、パッケージが特に要求しない限り、過去の子マッピング一式を再現するのではなく、現在の Compose／ストレージレイアウトを使用してください。
Postgres のデータパスはサポート対象のローカルストレージに保持する
現在の Immich ドキュメントでは、ネットワーク共有はサポートされていないと明記されています。 DB_DATA_LOCATION。ローカルに接続した RAID／ストレージファイルシステムは適している場合がありますが、SMB／NFS でマウントしたデータベースディレクトリは、サポートされているデータベースの保存先ではありません。
Immich の完全な復旧にはアセットとデータベースの両方が必要
現在の Immich のバックアップドキュメントでは、データベースのバックアップにはメタデータとユーザー情報が含まれますが、写真／動画のアセットは含まれないと説明されています。アセットツリーは別途バックアップし、互換性のあるデータベースバックアップと併せて復元する必要があります。
このため、元のケースで「アップロードファイルがまだ残っている」ことは安心材料ではあっても、それだけでは不十分だったのです。
古い稼働中の pgdata ディレクトリを、別の Postgres／イメージバージョンに安易に接続しない
Postgres の生のデータディレクトリは、バージョンに依存します。古い環境と新しいパッケージで Postgres または Immich のバージョンが異なる場合は、サポートされているデータベースのダンプ／リストア、または文書化された移行手順を優先してください。古い pgdata 実験する前に。
Immich 復旧 FAQ
ZimaOS のリセットによって、元の RAID6 の写真フォルダーは消去されましたか？
いいえ。ユーザーの説明では、RAID と既存のディレクトリ／ファイルはそのまま残っていました。
古い写真ファイルだけをマッピングすれば、Immich ライブラリは復元されますか？
必ずしもそうではありません。Immich には対応するデータベース／カタログの状態も必要です。
実験する前に、何を保護すべきですか？
完全なアセットストレージと、データベースまたは検証済みのデータベースバックアップ。
