Home Assistant の起動後に依存関係のいずれかが失敗した場合は、インストールを再構築するのではなく、最初に利用できなくなった依存関係を特定できる時間だけメインサービスを稼働させておきます。
プロセスが正常でも、システムが不完全な状態であることがあります。MQTT エンティティが利用できない、外部データベースによって履歴がブロックされる、マウントの欠落によってバックアップが壊れる、DNS によってクラウドやローカルのエンドポイントを解決できない、といったケースです。最初に発生したエラーを記録し、Home Assistant の実行環境から指定されたエンドポイントをテストして、依存関係の外側から順にサービスを復旧します。
最初に失敗した依存関係を特定する
影響を受けた統合またはサービスについて、起動後に最初に発生したエラーを記録します。依存関係の名前、エンドポイント、例外クラス、再試行間隔、タイムスタンプを含めてください。後続の警告は、最初の接続、認証、マウント、スキーマの失敗ではなく、利用できないエンティティやセットアップ失敗といった結果を示していることがよくあります。
基本的な MQTT のケースでは、統合を設定することと、実際にブローカーを利用できることの違いが分かります。解決済みのブローカーの可用性に関する違いは、必要なサービスが存在しない、または実行されていないときに、クライアント側の変更を繰り返すのを防ぐうえで役立ちます。
すべての二次的なエラーに先立って同じ依存関係名が現れる場合は、それを復旧対象にします。複数の無関係な依存関係が同時に失敗している場合は、各統合を個別に修復する前に、共通する DNS、ネットワーク、ストレージ、または認証情報をテストします。
到達性、認証、準備完了状態を順番にテストする
Home Assistant が使用するのと同じコンテナ、VM、またはホストの名前空間から、依存関係のホスト名を解決し、必要なポートを開き、設定済みの ID で認証し、利用可能な最小限の読み取り専用準備完了チェックを実行します。ホスト側で到達できても、アプリケーションの名前空間や認証情報が機能することの証明にはなりません。
コンテナの起動順序は、アプリケーションの準備完了状態と同じではありません。ヘルスチェックで起動を制御する依存関係を使えば、準備が整っていないデータベースやブローカーに対してクライアントが起動するのを防げます。起動順序と準備完了状態の違いは、失敗条件を理解した後にのみ実際のヘルスチェックを追加することを支持しています。
名前解決に失敗する場合は、DNS またはサービス名を修正します。ポートへの接続に失敗する場合は、依存関係のプロセスまたはネットワーク経路を復旧します。認証に失敗する場合は、値を表示せずに設定済みの認証情報の取得元を比較します。接続後に準備完了チェックが失敗する場合は、依存関係自身のログとストレージの状態を確認します。
最も影響の少ない変更で依存関係を復旧する
確認済みの障害だけを修正します。欠落したマウントを復元する、ブローカーを起動する、データベースサービスを修復する、認証情報の参照を更新する、ネットワークエイリアスを修正する、といった対応です。まず依存関係を再起動し、準備完了チェックが成功するまで待ちます。その後、クライアントが自動的に再接続しない場合に限り、Home Assistant を一度だけ再起動します。
コアサービスの起動後もワーカーや統合がオフラインのままの場合は、ワーカーの準備完了状態に関するトラブルシューティング手順を使って、起動の遅延と永続的な依存関係の境界を区別します。
依存関係が以前の正常な状態に戻せない場合、またはスキーマの削除、データベースの再作成、認証情報の露出が必要になる場合は、ロールバックします。既知の最後の正常な設定を復元し、より侵襲的な復旧を試みる前に、双方のログを保存してください。
元の機能を再現し、停止点を定義する
失敗した機能そのものを再テストします。使い捨ての MQTT 値を 1 件送受信する、最近の履歴範囲を読み込む、意図した保存先にテストバックアップを作成する、影響を受けた自動化を 1 回実行する、といった方法です。単に直後から利用できるだけでなく再接続できることを確認するため、依存関係を計画的に再起動した後にも繰り返します。
合格とみなすには、依存関係のヘルスチェック、Home Assistant の統合状態、ユーザー向け機能が一致している必要があります。エンティティが利用できない状態でコンテナが実行中でも復旧とはいえません。書き込みに失敗しているのにダッシュボードが正常表示されても、復旧とはいえません。
元の機能が 2 回成功し、新たな依存関係エラーが発生しなくなった時点で停止します。サービスに到達できるにもかかわらずプロトコルまたはスキーマのネゴシエーションに失敗する場合は、最初の例外、エンドポイントの種類、準備完了チェックの結果、依存関係のバージョン、復旧手順を添えてエスカレーションします。
復旧後の起動契約を記録する
どのコンポーネントが依存関係を管理しているか、その準備完了シグナル、再試行動作、認証情報の取得元、ネットワーク名、ストレージパス、復旧順序を文書化します。次の担当者が、インシデントを再調査しなくても、プロセスの起動と利用可能なサービスを区別できるようにします。
メンテナンス時間帯に依存関係を計画的に 1 回再起動し、記録した許容範囲内に Home Assistant が再接続することを確認します。手動介入がまだ必要な場合は、依存関係が完全にレジリエントであると印を付けるのではなく、その制限を明記します。
監視によって依存関係の失敗と機能の復旧の両方を検知できるようになってから、インシデントを終了します。メインプロセスが実行中であることしか監視していない場合は、不完全な起動状態を引き起こしたのと同じ見落としが残ります。
サポートとヒント
もっと読む

同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。

Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。

データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。

