Immich Liveをバックアップすべき？それとも先にサービスを停止すべき？
最もシンプルで説明しやすい整合性の境界を求めるなら、まず Immich を停止してください。ライブバックアップを使うのは、データベースネイティブなダンプを取得し、メディアの取得またはスナップショットを調整して、両者の復元上の関係を把握できる場合に限ります。
Immich はアセットの記録を PostgreSQL に保存し、オリジナルファイルと派生ファイルをストレージ上に保存するため、通常のライブ再帰コピーでは異なる時点の状態を取得する可能性があります。小規模な家庭環境では、複雑なオーケストレーションよりも短いメンテナンス時間を設けるほうが安全な場合が多くあります。継続的なアップロードが必要な場合は、サービスを稼働させたままデータベース対応ツールを使用し、取得順序を記録し、新しく到着するアセットを保護したうえで、分離環境への復元によってバックアップを評価してください。
復元時に再作成が必要なすべてのコンポーネントを定義する
PostgreSQL データベース、アップロードライブラリ、ポリシー上必要な生成メディア、外部ライブラリの定義、Compose ファイルと環境ファイル、シークレット、プロキシ設定、暗号化キーを一覧化します。Immich が管理する項目と、再生成できる項目を分類してください。
実践的なデータベースバックアップ記事では、稼働中のデータベースディレクトリを通常のファイルとして扱うのではなく、PostgreSQL ダンプを使用する方法を解説しています。そのデータベース対応バックアップ方法はライブ環境に対応していますが、実際のデプロイ環境に合わせてコマンドとバージョンを確認してください。
オリジナルファイルを保護していても、その記録を復元できなければ、またデータベースを保護していてもメディアを含めていなければ、計画は失敗します。ダウンタイムを許容できるかどうかを決める前に、バックアップの順序と並べて復元の順序を書き出してください。
最も明確な境界を得るには停止状態でバックアップする
アップロードを一時停止し、Immich のアプリケーションとワーカーを正常に停止してから、データベースネイティブなバックアップを取得し、メディアとデプロイ用ファイルをコピーまたはスナップショットします。ダンプに必要な場合に限って PostgreSQL を稼働させるか、そのサービス向けに設計されたストレージレベルのスナップショットを取得する前に、PostgreSQL を正常に停止してください。
サービスを停止しても、パスの誤りや対象範囲の不足は解決しません。そのため、マウントとアーカイブサイズを確認してください。成功条件は、取得中に Immich による書き込みが行われていないこと、データベースバックアップが正常に完了すること、メディアのサンプルを読み取れること、チェックサムが取得されていること、再起動時刻が記録されていることです。
ZimaSpace のバックアップキーと復元の検証に関するガイドも、静止した状態でのコピーは、認証情報と復元手順をテストするまで復元可能とはいえないことを示しています。
稼働継続が必要な場合は調整済みのライブバックアップを使用する
ライブ方式では、データベースネイティブな整合性のあるダンプを作成し、タイミングと書き込み動作を把握したストレージスナップショットまたはファイル取得と組み合わせます。開始時刻と完了時刻を記録し、新しく到着したアップロードは次回のバックアップまで保持し、稼働中のデータベースディレクトリをそのままコピーすることは避けてください。
稼働中のデプロイ環境から Immich をバックアップする方法についてのコミュニティディスカッションでは、データベースとアップロードファイルを分けて考える必要がある理由が示されています。このライブバックアップの境界は、復元テストの代わりではなく、実践的な参考情報として利用してください。
ライブ設計が成功するのは、データベースツールが正常に完了し、ファイルシステムの取得がアトミックであるか、その順序が文書化されており、実行中に作成されたアップロードが把握されている場合に限ります。それ以外の場合は、停止方式を選ぶか、バックアップ頻度を高めてメンテナンス時間を短縮してください。
分離環境で復元し、最終判断を行う
保存したデプロイ用ファイルを使い、選択したデータベースとメディアを分離した対象環境に復元します。ユーザー、アセット数、サンプルとして選んだオリジナル、アルバム、お気に入り、検索、外部ライブラリ、新しいアップロードを確認してください。対象環境を再起動し、重要な確認を繰り返します。
ダウンタイムが家庭環境に適合し、シンプルさによってエラーを減らせる場合は、停止バックアップを選択してください。可用性によって追加のツール導入が正当化され、繰り返しの復元テストによって手順の有効性が証明される場合は、調整済みのライブバックアップを選択します。ライブラリのサイズやアップロード頻度が増えれば、判断は変わる可能性があります。
復元でファイル欠落や孤立レコードのエラーが発生した場合は、本番環境の廃止を中止してください。両方のバックアップ構成要素とログを保持し、タイムスタンプと対象範囲を照合します。データベースのバージョン、ダンプ方式、ファイルシステムの方式、取得時刻、不一致数を添えてエスカレーションしてください。ライブ方式が独立して合格するまでは、最後に取得した停止バックアップを削除しないでください。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
