この情報源が証明していない最も重要なことは、ZimaOSがNASを独自にスキャンして通常の写真ライブラリを削除したということです。ユーザーは、Immichのアンインストール／再インストール作業後にファイルが消え、「設定を削除」オプションを疑っていました。しかし、削除が実際に発生した正確なイベントは、IceWhaleによって再現も診断もされていません。
後に投稿された設定から、それがZimaOS StoreのImmichパッケージではなく、カスタムDocker Composeによるデプロイだったことが分かりました。データベース、機械学習キャッシュ、ライブラリは、/mnt/bigdrive/data/immich/...以下にバインドマウントされていました。Zima-Giorgioも、そのアプリがZimaOS Store由来ではないことを明確に確認しています。そのため、Storeの通常のアンインストール動作が損失の原因だったと主張するのは危険です。ここから得られる確実な教訓は、代替のきかない写真データとデータベースのバックアップを、完全には理解していないクリーンアップ処理の対象外に保管することです。
ユーザーはアンインストール／再インストール後に代替のきかない写真が消えたと報告
情報源のユーザーは、Immichを削除する際に設定を削除するオプションにチェックを入れた可能性があると考えていました。また、クラッシュループ、障害発生中にログへ十分アクセスできなかったこと、そして最終的に画像を復元できずZimaOSの利用をやめたことも説明しています。
これは深刻なデータ損失の報告ですが、フォーラムでは、どの操作がどのファイルを実際に削除したのかを示す再現可能な手順は得られませんでした。
最初の説明はコミュニティによる仮説だった
コミュニティからの返信では、アンインストール時のクリーンアップが設定やユーザーデータとみなすアプリフォルダー内に、オリジナルデータが保存されていた可能性が指摘されました。特に、設定・データベース・オリジナルメディアを1つのAppDataツリーに混在させている場合、これは注意を促すうえで妥当な危険性です。
ただし、この特定の事例の原因として確認されたわけではありません。
投稿されたComposeでは、通常のStore AppDataの例とは異なる場所にデータがマッピングされていた
その後、ユーザーは次のようなホスト側パスを含むCompose定義を投稿しました。
/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/libraryImmichサーバーはライブラリフォルダーを/dataにマッピングしていました。これは重要な証拠です。なぜなら、先に提案された「すべてのオリジナルデータが/ DATA/AppData/immich配下にあった」という単純な説とは一致しないからです。
IceWhaleは、ZimaOS StoreのImmichパッケージではないことを確認した
設定を確認した後、Zima-Giorgioはアプリの入手元を尋ねました。ユーザーは、ImmichのDocker Composeファイルから導入したと回答しました。その後、GiorgioはZimaOS Storeからアプリをインストールすることを推奨しました。
この推奨だけではファイルを削除した原因は特定できませんが、アプリ管理の境界が明確に示されています。
現在のZimaOSでは、コンテナとマッピングされたデータは別のものとして扱われる
現在のIceWhaleのドキュメントでは、コンテナ自体は破棄可能であり、重要なアプリケーションデータはマッピングされたホストフォルダーに保存されると説明されています。これらのホストフォルダーをバックアップし、AppDataを適切なストレージに保存することも明示的に推奨されています。
ステートフルなアプリを削除する前に、現在のZimaOSのアプリデータモデルを確認してください。
Immichではアセットとデータベースの両方を保護する必要がある
ディスク上の写真や動画は、Immichを復旧するための要素の半分にすぎません。アルバム、ユーザー、メタデータ、ファイル情報、アプリケーションの状態はPostgreSQLに保存されています。安全な計画では、アセットツリーと互換性のあるデータベースバックアップの両方を保護します。
アプリのアンインストール時のチェックボックスをバックアップ戦略にしないでください。
写真管理アプリをアンインストールする前に
- ホスト側のすべてのボリュームマッピングを記録する。
- 写真／動画アセットの実際の保存先を確認する。
- 独立したデータベースバックアップを作成し、復元をテストする。
- 代替のきかないアセットを別のデバイス／ストレージにコピーする。
- 「ユーザーデータ／設定を削除」などのオプションが何を対象とするのか正確に理解する。
- その後でのみ、アプリを削除または再作成する。
ファイルが突然消えた場合は、さらなる書き込みを最小限に抑える
状態を把握するまでアプリを停止し、影響を受けたファイルシステムに対して、コンテナのインストールや再作成、新しいデータのコピーを行わないでください。まず、検証済みのバックアップから復元します。バックアップがなく、ファイルが本当に消えている場合は、メディアを保全し、影響を受けたファイルシステムへの書き込みを繰り返すのではなく、ファイルシステムに適した復旧の専門家へ相談してください。
情報源のコミュニティでは復旧ツールが紹介されていましたが、それらはIceWhaleの手順ではなく、すべてのRAID／ファイルシステムで安全であるとは限りません。
Immichのデータ損失に関するFAQ
ZimaOS Storeのアンインストールによって情報源のユーザーの写真が削除されたと、IceWhaleは確認しましたか？
いいえ。アプリはカスタムComposeによるデプロイであり、正確な削除メカニズムは確定していません。
投稿されたComposeでは、ライブラリは/DATA/AppData/immich配下にありましたか？
いいえ。/mnt/bigdrive/data/immich配下にライブラリ、データベース、キャッシュのバインドマウントが示されていました。
最も安全な予防策は何ですか？
アンインストール、リセット、またはスタックのマッピング変更を行う前に、オリジナルの写真／動画アセットとImmichのデータベースを、それぞれ独立してバックアップしてください。
