現在の永続状態が信頼できる復旧元ではなくなり、既知の正常なバックアップを復元してもインストールを復旧できない場合にのみ、Home Assistantを再構築してください。ほとんどの障害は、まずランタイム、統合、設定、データベース、ストレージ、ネットワークの問題に分類し、最も小さな層で修復するべきです。
再インストールが自動的に再構築を意味するわけではありません。コンテナイメージを置き換えても /config はそのまま残る場合がありますが、本当の再構築ではアプリケーション状態を新しく作成し、統合、デバイス、ダッシュボード、ヘルパー、オートメーションを復元または再作成する作業を受け入れることになります。この判断は、現在の症状への苛立ちではなく、状態の状況に基づいて行ってください。
3つの異なる対応を使い分ける:修復、復元、再構築
修復では、現在の設定を維持したまま、障害が発生したコンポーネントを直します。復元では、損傷または互換性のない状態を既知の正常なバックアップで置き換えます。再構築では、クリーンなHome Assistantインストールから始め、信頼できると意図的に判断した状態だけをインポートまたは再作成します。
この区別により、コンテナやパッケージの問題が不必要なデータ損失に発展するのを防げます。現在のユーザー、エリア、デバイス、オートメーションがまだ残っているなら、新規インストールによって、修復できる情報よりも多くの既知の正常な情報を失う可能性があります。
ファイルを変更する前に、3つのうちどの対応を行うのかを書き留めてください。この簡単なラベルによって、誤って修復から破壊的なリセットへ移行しにくくなります。
永続状態に一貫性があるなら、まず修復する
Home Assistantが想定どおりのインスタンスを開き、設定ディレクトリにデータがあり、エラーを特定の統合、YAMLの変更、カスタムコンポーネント、データベースファイル、マウント、またはランタイム設定に結び付けられる場合は、修復が適しています。
Safe ModeとRecovery Modeが用意されているのは、多くの起動障害を設定を放棄せずに切り分けられるようにするためです。最新の復旧ガイドでは、正確な起動エラーを確認し、Safe Modeでカスタムコードを切り分け、再構築の前に最小限の修復手段としてRecovery Modeを使用することを推奨しています。
カスタム統合を1つ無効化または更新する、無効な設定項目を1つ修正する、ストレージパスを修復する、またはランタイムのバージョンをロールバックしてから、もう一度テストしてください。障害の範囲が限定されている間は、インストール全体をリセットしないでください。
履歴を残す価値がある場合のみ、データベースを修復する
ログがデータベースエラーで埋まるため、Recorderの破損は深刻に見えることがあります。しかし、RecorderデータベースはHome Assistantの完全な設定と同じものではありません。現在の設定と統合が正常なら、アプリケーション全体を再構築するより、新しい履歴データベースを作成するほうがリスクが低い場合があります。
履歴に価値がある場合は、実用的な復旧手順でHome Assistantを停止し、SQLiteの復旧ツールを使って、破損したHome Assistantデータベースを新しいファイルに再構築する方法が紹介されています。
作業は必ずコピーに対して行い、元の破損したデータベースを保存し、復旧が部分的になる可能性を受け入れてください。履歴の修復に失敗しても、正常なオートメーションや統合を破棄する理由にはなりません。
継続的な修復より既知の正常なバックアップが安全なら、復元する
特定可能な更新や編集の後に障害が始まり、その変更前に作成したテスト済みのバックアップがある場合は、復元してください。移行または部分的に変更された多数のファイルを手動で元に戻すより、速く安全なことが多い方法です。
長年利用されているHome Assistantの復元ガイドでは、まず障害の原因を直し、その後、障害が発生したシステムから別の場所へコピーしたバックアップを復元することを推奨しています。故障した電源、ディスクの問題、不正なマウント、互換性のないランタイムを取り除かずに復元すると、同じ障害を再現するだけです。
復元したシステムが正常に動作するまで、破損した状態を保持してください。そこには、最近追加したオートメーション、シークレット、設定変更が含まれている可能性があり、比較または選択的な復旧が必要になる場合があります。
状態と復旧手段が信頼できなくなったら、再構築する
設定ディレクトリが失われている、広範囲に破損している、複数のバックアップで復元テストに失敗する、ランタイムの定義が不明である、または繰り返し修復しても記録されていない状態が残り再現できない場合は、クリーンな再構築が妥当になります。
重要な設定が使い捨てのコンテナ内部に閉じ込められているなど、構成が不適切なデプロイから移行する場合も、再構築のほうが適切な選択になることがあります。ただし、その前に信頼できる状態をすべてエクスポートしてください。
ZimaSpaceのローカル自動化ガイドでは、復旧可能性をスマートホームプラットフォームの基本要件として強調しています。新しいインストールのバックアップ、復元、運用が、放棄した状態より容易になって初めて、再構築は成功したと言えます。
古い状態を削除する前に、判断表を使う
| 状態 | 推奨する対応 |
|---|---|
| 単一の統合または設定エラー | 修復 |
| ランタイムまたはイメージの更新に失敗したが、設定は正常 | ランタイムの修復またはロールバック |
| データベースが破損しているが、設定は正常 | データベースの修復または置き換え |
| 広範囲の損傷が発生する前の、既知の正常なバックアップがある | 復元 |
| 設定とバックアップを信頼または再現できない | 再構築 |
選択した方法で再起動を行い、通常の家庭内利用を1サイクル完了するまで、古い設定、データベース、バックアップ一式を削除しないでください。
よくある質問
Home Assistantのコンテナを再インストールすると、再構築に該当しますか?
いいえ。新しいコンテナが同じ永続 /config ディレクトリに再接続する場合、置き換わるのはランタイムであり、同じインストール状態は維持されます。再構築では、新しい状態から開始するか、古い状態を意図的に放棄します。
Recorderデータベースが破損したら、Home Assistantを再構築すべきですか?
通常は必要ありません。Recorderの履歴は、Home Assistantの他の部分とは別に修復、復元、または置き換えができます。履歴だけでなく設定と復旧状態も信頼できなくなった場合にのみ、インストール全体を再構築してください。
サポートとヒント
もっと読む

Home Assistantを稼働中にバックアップすべきか、それとも先にサービスを停止すべきか?
Home Assistantの組み込みバックアップは稼働中でも実行できますが、単純なファイルシステムのコピーでは、データベースを一貫性のある状態でバックアップしない限り、Home Assistantを停止または休止させる必要があります。

アイドル時間中にHome Assistantサーバーが高温になったり、うるさくなったりするのはなぜですか?
冷却やCPU制限を変更する前に、Recorder、バックアップ、連携機能、同一ホスト上のジョブと、Home Assistantのファン回転数や温度の急上昇との相関を確認してください。

Home Assistantがバックグラウンドジョブ用に確保すべき空き容量はどのくらいですか?
Home Assistantの空き容量は、Recorderデータベース、バックアップの増加、メンテナンス時のピーク、復旧作業を考慮して見積もり、画一的な割合では決めないでください。

