組み込みのバックアップシステムを主要な復旧手段とし、実行環境は交換可能なものとして扱うことで、Home Assistantの設定が失われるのを防ぎます。Home Assistantのバージョン、コンテナイメージ、ホストは変更される可能性がありますが、元のマシンが失われたときにも、バックアップ、暗号化キー、実行環境の定義、外部依存関係を利用できる状態にしておく必要があります。
最新のHome Assistantバックアップは、Containerを含むさまざまなインストール方式で利用できます。役立つ場合は設定ツリーの手動コピーも別途保持して構いませんが、サポートされているバックアップと復元のワークフローを無視して、ファイルの手動コピーだけをアップグレード計画の中心にしないでください。
手動でコピーしたYAMLフォルダーではなく、組み込みバックアップから始める
「設定」をconfiguration.yamlだけに限定しないでください。Home Assistantのサポート対象バックアップシステムは、設定やデータベースの内容など、復旧に必要なアプリケーション状態を取得します。さらに新しいバックアップワークフローでは、自動化、保持期間、ホスト外の保存先にも対応しています。
2025年に行われたバックアップ機能の刷新では、暗号化された自動バックアップ、保持設定、オフサイトのバックアップ保存先が追加されました。これにより、不完全な手動コピーに頼るのではなく、アップグレード前に組み込みバックアップを最初の復旧資産として確認できるようになります。
ただし、設定ルート、データベースの種類、シークレットの参照先、カスタムコンポーネント、SSL関連のファイル、統合に必要な外部ファイルやサービスは記録しておきましょう。バックアップによってHome Assistantの状態は復元できますが、USBデバイス、ネットワークパス、データベースホスト、周辺のコンテナパラメーターまですべて自動的に記録できるわけではありません。
コンテナの永続化と実行環境の設定を明示する
Dockerでは、/configを所有するバインドマウントまたはボリュームを確認し、ネットワークモード、デバイスマッピング、タイムゾーン、権限、外部サービスを再現できるCompose定義またはrun定義を保持してください。コンテナのファイルシステム自体は、破棄可能なものにしておくべきです。
Docker版Home Assistantのバックアップに関する議論では、障害のパターンが明確に示されています。ユーザーが完全な設定ディレクトリではなく、1つのファイルだけをマッピングすると、重要な状態がコンテナ内に取り残され、実行環境を置き換えた際に消失する可能性があります。
アップグレード前にホストのマウントを確認し、バックアップと同じ場所に実行環境の定義を保管してください。アプリケーションの状態と、無線機器、ポート、ネットワーク、ストレージを公開するために必要な手順の両方があらかじめ分かっていれば、復旧は大幅に速くなります。
少なくとも1つの暗号化バックアップをホスト外に移す
同じSSD上にあるバックアップは、一部の設定ミスからは保護できますが、ホストの喪失、ファイルシステムの破損、盗難、ストレージデバイスの故障には対応できません。少なくとも1つの復旧用コピーをNAS、別のコンピューター、または故障したHome Assistantホストに依存せずアクセスできるリモートバックアップ先に保存してください。
バックアップの暗号化キーまたは緊急用キットも、Home Assistantの外部に保管してください。Home Assistant 2026.4では、新しい暗号化バックアップが監査済みのSecureTar v3形式と、より強力な最新の暗号化方式に移行されました。これによりバックアップの安全性は向上しますが、キーの管理が復旧可能性の明確な一部になります。
同じファイルを上書きするのではなく、バックアップにバージョンを付けてください。アップグレード後、数日経ってから問題が判明することがあり、その時点で最新の復旧ポイントに、避けたい移行後または破損した状態がすでに含まれている可能性があります。
バックアップだけでは実行環境の定義を置き換えられない
設定だけでは、USB無線機器、ホストネットワーク、タイムゾーン、デバイスパススルー、データベースサービス、MQTT、リバースプロキシの関係を復元できない場合があります。実行環境を再構築するために必要なComposeファイル、イメージのバージョン方針、環境変数、ホストパス、デバイスマッピング、サービス依存関係を保持してください。
Composeファイルをバージョン管理するためだけに、公開リポジトリへ平文のシークレットを入れないでください。シークレットの値は保護された場所に保管し、復旧プロセスがどこから取得するのかだけを記録してください。
ZimaSpaceのZimaBoardへのHome Assistant導入ガイドは、ホームサーバープラットフォームと、将来の導入方法の変更後も保持すべきアプリケーション状態を分けて考えるうえで役立つ情報です。
アップグレードが緊急事態になる前に復元テストを行う
アーカイブが存在するだけでは、バックアップが実証されたことにはなりません。隔離した環境または一時コンテナに復元し、可能な範囲で代表的なデバイスとパスを再接続して、ユーザー、ダッシュボード、統合、自動化、ヘルパー、期待される状態が戻ることを確認してください。
テストを利用して、運用システムがまだ動作しているうちに、不足しているパスワード、古いホストパス、記録されていないデバイスマッピング、肥大化したデータベースを見つけます。テストに成功したら復元手順を記録してください。記憶だけでは復旧計画になりません。
アップグレードの直前に、新しい復旧ポイントを作成し、現在のHome Assistantのバージョンとコンテナイメージを記録して、統合に影響するリリース変更を確認してください。アップグレード済みのインスタンスが通常の利用時間と再起動の両方を問題なく乗り切るまで、以前の実行環境を利用できる状態にしておきます。
4項目のアップグレード安全チェックを使用する
| 復旧資産 | 保護する対象 | 欠けている場合の障害 |
|---|---|---|
| 組み込みバックアップ | Home Assistantの設定と復旧可能なアプリケーション状態 | サポートされた復元ポイントがない |
| 暗号化キー/緊急用キット | 保護されたバックアップへのアクセス | バックアップは存在するが開けない |
| 実行環境の定義 | マウント、デバイス、ネットワーク、環境 | 状態は正しいがサービスにアクセスできない |
| ホスト外のコピー+復元テスト | ホスト障害と手順の有効性 | 本番環境とともに復旧手段が失われる、または必要なときに復旧できない |
4項目すべてを確保できている場合にのみ、アップグレードしてください。設定ツリーの手動コピーは追加の保護層として残せますが、主要な復旧計画は、復号して復元でき、文書化された実行環境とともに利用できる、サポート対象のバックアップにしてください。
サポートとヒント
もっと読む

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

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

Home Assistantは修理するより再構築すべきなのはいつですか?
まず、Home Assistantで最小限の故障レイヤーを修復し、次に既知の正常な状態へ復元します。永続設定を信頼できない場合にのみ再構築してください。

