ユーザー、履歴、設定を失わずにImmichのデータを移行する方法

エヴァ・ウォン

IceWhale author

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

How to Move Immich Data Without Losing Users, History, or Settings - Zima Store Online

Immichはフォルダーのコピーではなく、アプリケーション状態の移行として移動してください。データベース、メディアツリー、設定、シークレット、それらを結び付けるパスを保持する必要があります。

新しいディスクにすべてのJPEGが存在していても、アカウント、アルバム、人物、共有、お気に入り、過去の関連情報が欠落していれば、移行は成功したように見えることがあります。まずロールバックポイントを作成し、一貫性のあるソース状態を取得して、識別子を変更せずにコピーします。分離したターゲットで復元し、家庭内での利用手順が一致することを確認してから切り替えてください。

一緒に移行する必要がある状態を一覧化する

PostgreSQLデータベース、アップロード済みメディア、保持する予定の生成データ、外部ライブラリの定義、Composeまたはアプリの設定、環境変数、シークレット、ネットワーク名、現在のストレージマッピングを一覧にします。どの項目が正本で、どれが復旧後に再生成できるかを明確にしてください。

移行中にImmichのユーザーを保持する方法についての2026年の議論でも、重要な点が強調されています。ユーザーとライブラリの状態はコンテナイメージではなく、データベースとマウントされたパスに結び付いています。コミュニティのコマンドは例として扱い、実際にデプロイされているバージョンに合わせて調整してください。

移行前に、確認用の小さなセットを用意します。2人のユーザー、複数のアルバム、お気に入り、共有アイテム、1人の人物または検索結果、古いアセットと新しいアセット、使用している場合は外部ライブラリのパスを含めます。これらの既知のレコードがあれば、ファイルサイズの合計だけを比較するよりも、移行後の検証をはるかに強固にできます。

コピー前に一貫性のある復旧ポイントを作成する

新しいアップロードを停止するか、メンテナンス時間を設定して、移行状態を取得している間にソースが変更されないようにします。データベース固有のバックアップを取得し、ソースのメディアと設定を保護してください。取得後は、移行先の検証が完了するまで元のインスタンスを変更せずに保持します。

フォトライブラリのコンポーネントを一緒に復元する方法を説明したZimaSpaceの復旧ガイドでは、オリジナル、カタログ状態、パスを定義する設定が、互換性のある復旧ポイントを構成する必要がある理由を解説しています。これは移行にも必要な境界です。

稼働中に変更されている本番データベースのディレクトリを、通常のファイルコピー先として使用しないでください。停止時間を短くする必要がある場合は、データベースを認識できるダンプと、取得順序を理解しているストレージ方式を使用します。移行の復旧可能性を決めるのは、コピーしたファイル数ではなく、復元できるポイントです。

パスと権限を維持したままメディアをコピーする

移行中にフォルダー構成を変更せず、メディアツリーを移行先へコピーします。所有者、権限、タイムスタンプ、デプロイが依存するファイルシステム機能を保持してください。コンテナから見えるパスを同じにする必要がある場合は、コンテナ内のマッピングを維持したまま、ホスト側のバインド元を変更します。

現在のrsync移行ワークフローでは、アーカイブモード、ドライラン、再開可能な転送、破壊的なミラーオプションの危険性が強調されています。削除を行う前にドライランで比較し、コマンドが完了したからといってアプリケーションの移行も完了したと決めつけず、移行先を検証してください。

ファイル数とサイズを比較し、古い写真、新しい写真、動画、大容量ファイルから代表的なサンプルを選んでチェックサムも検証します。ソースの変更によってコピーエラーや「消失したファイル」が発生した場合は、アップロードを停止して差分コピーをやり直してください。見た目だけ整った移行先にするために、ソースを削除してはいけません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

分離したターゲットでデータベースと設定を復元する

検証中にモバイルクライアントがアップロードできないよう、移行先を一時的なホスト名または分離したネットワークで起動します。コピーしたメディアを想定されたコンテナ内のパスに接続し、対応するデータベースを復元します。そのバージョンに必要な環境変数、シークレット、ネットワーク、プロキシ設定も再現してください。

2026年に報告された別の段階的なサーバー移行の事例からも、古いホストを廃止する前に新しいホストをテストする重要性が分かります。このような報告は障害の想定に役立てつつ、移行で実際に状態が保持されたかどうかは、用意した既知のレコードで判断してください。

移行先が新規インストールとして開く、ストレージが見つからないと報告される、または破壊的な初期化を提案される場合は停止します。通常、これらの症状はデータベースまたはマウントが想定したものではないことを示します。まずパスまたは復元先を修正してください。空のように見えるインスタンスに新しいファイルをアップロードして、競合する2つの履歴を作成してはいけません。

ユーザー、履歴、新しい書き込みを確認してから切り替える

各確認用ユーザーでログインし、アルバムのメンバー構成、お気に入り、共有、検索または人物の状態、代表的なオリジナル、タイムスタンプ、想定されるライブラリ数を確認します。次に、新しいテスト用写真を1枚アップロードし、表示されて処理されること、そしてコンテナの再起動後も保持されることを確認してください。

分離環境でのテストに合格してから、本番のDNSまたはプロキシの接続先を変更します。両方のシステムが同時に書き込みを受け付けないよう、古いインスタンスは停止したまま、復旧可能な状態で保持してください。新しいホストで通常のバックアップが完了し、少なくとも1回の復元テストが終わるまで、移行前のデータベースバックアップとソースメディアを保存します。

件数が一致しない、既知の関連情報が消える、新しいアップロードが誤ったディスクに書き込まれる、または再起動後に移行先が正常に動作しない場合は、ロールバックしてください。問題をエスカレーションする際は、ソースとターゲットのバージョン、データベースバックアップのタイムスタンプ、マウントマップ、コピーのログ、権限の差異、最初に失敗した確認項目を添えてください。