データベースのボリュームがいっぱいになった後に Immich を修復する方法
Immichのデータベースボリュームが満杯になった場合は、新しいImmichへの書き込みを停止し、PostgreSQLのデータディレクトリを保全してから、復旧を試みるための安全な作業領域を確保してください。大きいという理由だけで、pg_walやその他のPostgreSQL内部ファイルを削除しないでください。
データベースのファイルシステムが満杯になると、チェックポイントやクラッシュリカバリが中断される可能性があります。そのため、写真アプリケーション自体が正常に見えても、再起動を繰り返すと失敗し続けることがあります。まず、満杯なのがどのファイルシステムなのか（PostgreSQLのデータ領域、Dockerのルートストレージ、共有メモリ、その他のマウント）を特定し、ロールバックに必要な証拠を破壊せずに、その層を復旧してください。
満杯のファイルシステムを特定し、追加の書き込みを停止する
PostgreSQLのマウント、Dockerのデータルート、ホストのルートファイルシステム、エラーに記載されたtmpfs／共有メモリのパスについて、バイト容量とiノードの空き状況を確認します。時刻をPostgreSQLのログと照合してください。pg_walから「デバイスに空き領域がありません」というメッセージが出た場合、イメージキャッシュやサムネイル用パーティションが満杯の場合とは意味が異なります。
Immichのデータベース復旧に関するディスカッションでは、ストレージが満杯になったため、一時WALファイルを書き込めず、PostgreSQLがリカバリを中止しています。この事例は古く、デプロイ環境にも依存しますが、ファイル権限を変更したりスタックを再起動したりしても、容量不足は解決しないことを示しています。
アップロードとバックグラウンドジョブを一時停止し、新しいデータベース処理を生成するアプリケーションコンポーネントを停止します。最初に失敗したログの範囲とマウント構成を保全してください。満杯のファイルシステムが実際にはPostgreSQLのデータファイルシステムでない場合は、データベースを不必要に移動するのではなく、実際の場所を修復します。
容量を確保する前にPostgreSQLの状態を保全する
PostgreSQLを停止した状態で、ストレージとツールが許す場合は、データベースのデータディレクトリのファイルシステムスナップショットまたは完全なコピーを作成します。WALディレクトリと、デフォルト以外のテーブルスペースがある場合は、それらも1つの状態として含めてください。この安全コピーがあれば、次の復旧試行で状況が悪化した場合に、インシデント発生時点へ戻ることができます。
PostgreSQLのディスク容量不足からの復旧ガイドでは、重要なルールが明確に示されています。WALは単なる不要なログではなく、データベースの整合性の一部であり、手動で削除するとデータベースが破損する可能性があります。代わりに、ボリュームを拡張または移動するか、無関係で安全なデータを削除して容量を確保してください。現在の状態が復旧不能だと判断し、そのバックアップ以降の変更を失うことを受け入れるのでない限り、失敗したデータベースを直ちに最新バックアップで上書きしないでください。満杯になったインスタンスを保全しておけば、ロールバックポイントと、容量が失われた原因を調査するための証拠の両方を確保できます。
まずPostgreSQLを復旧し、その後Immichの修復が必要か判断する
十分な空き容量を確保したら、PostgreSQL単体、または必要最小限のスタックで起動し、リカバリログを監視します。コンテナのステータスが「実行中」であることよりも、正常な起動、正常なヘルスチェック、通常の読み取りアクセスのほうが確かな判断材料になります。データベースが安定して処理できる状態になったら、できるだけ早くデータベースネイティブの新しいバックアップを取得してください。
ZimaSpaceのImmichデータベースのメンテナンスと交換に関するガイドでは、次の判断基準が示されています。通常のサイズやパフォーマンスの問題だけで再構築を行うべきではありません。一方、再現性のある整合性エラーやリカバリの失敗がある場合は、検証済みのデータベースコピーからの復元を検討できます。
PostgreSQLが正常な状態を維持していることを確認してから、Immichを起動します。
ユーザー、タイムライン、複数のオリジナル画像、アルバム、検索機能、そして管理下で行う新しいアップロードを1件確認してください。データベースは起動するもののアプリケーションのクエリが一貫して失敗する場合は、新しいログを保全し、現在の問題が空き容量ではなく、スキーマやバージョンの互換性、またはデータ整合性にあるのかを判断します。
増加原因を解消し、再び安全に容量を使えることを確認する
どの部分が増加したのかを測定します。通常のデータベーステーブル、WALの保持、同じボリュームに保存されたバックアップ、ログ、Dockerレイヤー、または想定外のパスを確認してください。アーカイブやレプリケーションの失敗、あるいは別のサービスがデータベースボリュームへ書き込んでいたことが原因なら、単に容量を増やすのではなく、その原因を修正します。
PostgreSQLがチェックポイントやリカバリを実行できなくなる前に、十分な余裕を持ってアラートを設定してください。空き容量は割合と絶対値の両方で監視します。大容量ボリュームでは空き容量の割合が小さくても作業領域が十分に残っている場合がありますが、小容量のデータベースボリュームはすぐに危険な状態になる可能性があります。データベースのバックアップは、保護対象と同じ障害境界の外に保管してください。
最後に、通常のアップロードとバックグラウンド処理のサイクルを再実行し、新しいデータベースバックアップを作成してから、スタックを再起動し、ホストを再起動します。空き容量の減少が安定しており、WALやリカバリのエラーがなく、過去と新しいアセットの両方を読み取れ、書き込みが再び失敗する前に対応できるしきい値が文書化されていれば、復旧は成功です。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
Immichはなぜ所有者が間違った状態で欠落ファイルを再作成するのですか？
Immichは、失われたソース元ファイルを黙って再作成すべきではありません。再生成されたファイルの種類と作成者を特定し、作成時の識別情報を修正してください。
