メインコンテンツにスキップ

バックアップと復元

データを保護するためには3-2-1バックアップ戦略が推奨されます。完全なバックアップソリューションを実現するために、アップロードされた写真や動画、およびImmichデータベースのコピーを保持する必要があります。このページでは、データベースのバックアップ方法とユーザーがアップロードした写真や動画の保存場所の概要を説明します。cronジョブとして実行可能なテンプレートbashスクリプトはこちらに提供されています。

危険

このページの指示は、Immichインスタンスをバックアップできるよう準備する方法と、どのファイルをバックアップすべきかを示しています。実際のバックアップツールを使用してバックアップを自分で作成することはまだ必要です。

データベース​

注意

Immichはデータベースにファイルパスを保存しますが、ライブラリフォルダをスキャンしてデータベースを更新しないため、バックアップは非常に重要です。

情報

Postgresデータベースのバックアップと復元に関する詳細は公式のPostgresドキュメントを参照してください。

注意

DB_DATA_LOCATIONフォルダを直接バックアップすることは推奨されません。データベースが稼働中にそれを行うと、復元できない破損したバックアップが生成される可能性があります。

自動データベースダンプ​

警告

自動データベースダンプは、Postgresデータベースファイルに損傷が発生した場合にデータベースを復元する際に使用できます。 これらのダンプの監視は行われず、失敗した場合に通知されることはありません。

注意

データベースダンプには写真や動画は含まれておらず、メタデータのみが含まれています。以下に示すようにUPLOAD_LOCATION内の他のファイルのコピーと併せて使用する必要があります。

災害復旧目的のために、Immichは自動的にデータベースダンプを作成します。これらのダンプはUPLOAD_LOCATION/backupsに保存されます。 以下で示す資産フォルダと一緒に、独立したデータベースのバックアップを自分で作成してください。 管理者設定でスケジュールや保持されるデータベースダンプの数を調整できます。 デフォルトでは、Immichは最後の14回分のデータベースダンプを保持し、毎日午前2時に新しいダンプを作成します。

ダンプのトリガー​

管理者ジョブステータスページでデータベースダンプをトリガーできます。 ページにアクセスし、右上の「ジョブ作成」モーダルを開き、「データベースダンプ作成」を選択して「確認」をクリックします。 ジョブが実行されダンプがトリガーされます。ログやbackups/フォルダを確認して正常に動作したことを検証してください。 これらのダンプは設定に基づいて保持される最後のX回分としてカウントされます。

復元​

将来のバージョンでは復元をより簡単にする予定ですが、現時点ではホストのUPLOAD_LOCATION/backupsフォルダにデータベースダンプが保存されています。 その後、以下のセクションの手順に従ってデータベースを復元してください。

手動バックアップと復元​

バックアップ
docker exec -t immich_postgres pg_dumpall --clean --if-exists --username=<DB_USERNAME> | gzip > "/path/to/backup/dump.sql.gz"
復元
docker compose down -v  # 注意: Immichの全データを削除して最初からやり直します
## 次の行をアンコメントしてPostgresパスをDB_DATA_LOCATIONに置き換えてデータベースを永続的にリセット
# rm -rf DB_DATA_LOCATION # 注意: Immichの全データを削除して最初からやり直します
docker compose pull             # Immichの最新バージョンに更新(必要に応じて)
docker compose create           # ImmichアプリのDockerコンテナを作成しますが、実行はしません
docker start immich_postgres    # Postgresサーバーを起動
sleep 10                        # Postgresサーバーが起動するまで待機
# デフォルトから変更した場合はデータベースユーザーを確認してください
gunzip --stdout "/path/to/backup/dump.sql.gz" \
| sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
| docker exec -i immich_postgres psql --dbname=postgres --username=<DB_USERNAME>  # バックアップの復元
docker compose up -d            # Immichアプリの残りを起動

データベース復元を適切に進めるには、完全に新規のインストールが必要です(つまり、Dockerコンテナを作成してからImmichサーバーが一度も稼働したことがない状態)。Immichアプリが稼働した場合、データベース復元時にPostgresの競合が発生する可能性があります(関係がすでに存在している、外部キー制約の違反、複数の主キーなど)。この場合、データベースをリセットするためにDB_DATA_LOCATIONフォルダを削除する必要があります。

ヒント

一部のデプロイメント方法では、サーバーを開始せずにデータベースを開始するのが困難です。このような場合は、環境変数DB_SKIP_MIGRATIONS=trueを設定してサービスを開始してください。これにより、復元プロセスを妨げるマイグレーションがサーバーで実行されるのを防ぎます。データベースが復元された後、この変数を削除してサービスを再起動することを忘れないでください。

ファイルシステム​

Immichはファイルシステムに2種類のコンテンツを保存します：(a)オリジナルの未加工の資産(写真と動画)、(b)生成されたコンテンツ。UPLOAD_LOCATIONのすべての内容をバックアップすることを推奨しますが、重要なのは以下のフォルダに保存されているオリジナルのコンテンツのみです：

  1. UPLOAD_LOCATION/library
  2. UPLOAD_LOCATION/upload
  3. UPLOAD_LOCATION/profile

これらのフォルダのみをバックアップすることを選択した場合、バックアップから復元した後にすべての資産についてトランスコーディングとサムネイル生成のジョブを再実行する必要があります。

注意

これらのフォルダの一部を別のストレージデバイス(例: profile/)に移動した場合は、バックアップパスをセットアップに一致するように調整してください

資産タイプと保存場所​

一部の保存場所はストレージテンプレートによって影響を受けます。以下の詳細を参照してください。

ノート

UPLOAD_LOCATION/libraryフォルダは、バージョン1.92.0以降を実行している新しいマシンではデフォルトで使用されません。それはシステム管理者がストレージテンプレートエンジンを有効にした場合のみ使用されます。 詳細はリリースノートをご覧ください。

1. ユーザー固有のフォルダ:

  • 各ユーザーは、それを表す一意の文字列を持っています。
  • アカウント設定 -> アカウント -> ユーザーIDで自分のユーザーIDを確認できます。

2. 資産タイプと保存場所:

  • ソース資産:

    • ブラウザインターフェイス、モバイル、CLI経由でアップロードされたオリジナル資産。
    • UPLOAD_LOCATION/upload/<userID>に保存されます。

  • アバター画像:

    • ユーザープロフィール画像。
    • UPLOAD_LOCATION/profile/<userID>に保存されます。

  • サムネイル画像:

    • 各資産のプレビュー画像(小さいサムネイルと大きなプレビュー)および顔認識サムネイル。
    • UPLOAD_LOCATION/thumbs/<userID>に保存されます。

  • エンコード済み資産:

    • 広範な互換性のために元の動画を再エンコードしたもの。元の動画は削除されません。
    • UPLOAD_LOCATION/encoded-video/<userID>に保存されます。

  • Postgres

    • Immichデータベースで、システムが正常に動作するために必要な情報を含んでいます。 注意: このフォルダは、v1.102.0で言及された変更を行った(任意・非必須の変更)ユーザーまたはこのバージョンで開始したユーザーにのみ表示されます。
    • DB_DATA_LOCATIONに保存されます。
    危険

    このフォルダのバックアップはデータベースのバックアップとしては不十分です！ 正しいバックアップ方法を学ぶにはこちらにある指示に従ってください。

危険

バックアップを取る場合を除き、これらのフォルダー内のファイルにはいかなる状況で触れるべきではありません。アセットを変更または削除すると、追跡が外れたりファイルが欠落する可能性があります。 これを名前を言ってはいけないアプリのように考えることができます。アセットの閲覧、変更、削除への唯一のアクセス手段はモバイルまたはブラウザインターフェイスを通じてのみです。

バックアップの順序​

Immichのバックアップには、データベースとアセットファイルの両方を含める必要があります。これらをバックアップする際に同期が取れず、復元後に壊れたアセットとなる可能性があります。 これを最良の方法で対処するには、バックアップを取る間にimmich-serverコンテナを停止させることです。何も変更されない場合、バックアップは常に同期されています。

コンテナを停止できない場合、推奨される順序はデータベースを最初にバックアップし、次にファイルシステムをバックアップすることです。この方法では、最悪の場合として、ファイルシステムにデータベースで認識されていないファイルが残るだけです。必要であれば、復元後にこれらを手動で再アップロードすることができます。逆向きにバックアップを行った場合、つまり最初にファイルシステムをバックアップし次にデータベースをバックアップすると、復元されたデータベースがファイルシステムバックアップに存在しないファイルを参照する可能性があり、壊れたアセットとなります。