Home Assistantの永続データの役割とは何か、そしてなぜ重要なのか？

Home Assistantの永続データは、すべてを一括した「設定」として扱うのではなく、役割ごとに分けると運用しやすくなります。スマートホームのアイデンティティや動作を定義する状態、過去の観測データを保存する状態、認証情報を含む状態、そしてHome Assistantを中心とした実行環境を再構築するためだけに存在する状態があります。

これらの役割が重要なのは、復旧時の価値がそれぞれ異なるためです。1か月分の履歴を失うことは、エンティティレジストリを失うことと同じではありません。また、Dockerイメージを再作成することは、デバイスのマッピング、シークレット、家庭の自動化を形作る設定を再現することとは異なります。

設定とレジストリの状態がインストール環境を定義する

永続的な設定ツリーには、YAML、UIで管理されるストレージ、インテグレーション設定、ダッシュボード、ヘルパー、デバイスおよびエンティティのレジストリ、カスタムコンポーネントなど、あるHome Assistantインスタンスをクリーンインストールと異なるものにするファイルが含まれます。

コンテナの永続化では、書き込み可能なコンテナレイヤーの外部に状態を保存する必要があります。Dockerの現在のストレージガイダンスでは、ボリュームとバインドマウントによって、コンテナのライフサイクルに依存せずアプリケーションデータを永続化できると説明されています。イメージは再作成できますが、家庭固有の状態が自動的に戻るとは限りません。

この役割には、慎重なバックアップ、管理された移行、そして明確な復元手順が必要です。キャッシュや使い捨てのコンテナレイヤーと同じクリーンアップポリシーを適用すべきではありません。

Recorderの履歴は価値あるデータだが、設定とは異なる

Recorderには、履歴、ログブック、ダッシュボード、分析で使用される過去の状態、イベント、統計が保存されます。特にエネルギー、環境の傾向、トラブルシューティングにおいて重要なデータですが、Home Assistantは未加工の履歴を無制限に保持しなくても、現在の状態を表現できます。

履歴をアイデンティティから分離すると、復旧時の判断が変わります。破損または肥大化したRecorderデータベースについては、健全な自動化やインテグレーション設定を破棄せずに、修復、復元、あるいは履歴だけを再構築することが可能です。

履歴データには、サンプリングレート、保持期間、集約、インデックス、バックアップ世代など、独自のライフサイクルが必要です。これらがストレージの増加を決める要因は、自動化ルールの数とは別です。インストール環境を定義する設定およびレジストリの状態とは分けて、保持に関する判断を行ってください。

シークレットと復旧キーには異なる障害時の要件がある

認証情報、トークン、証明書、暗号化キー、バックアップ用の緊急復旧情報は、バイト数は小さくても復旧時の価値が高い場合があります。復号できないバックアップや、有効な認証情報を持たない復元済みインテグレーションは、システムを部分的に利用不能にする可能性があります。

Home Assistantのバックアップ戦略では、異なるメディアとオフサイトの場所に、暗号化された復旧用コピーを保管することが明確に推奨されています。この保護が役立つのは、ホストを失った後でもバックアップの復元に必要なキーを利用できる場合に限られます。

設定をバージョン管理しているからといって、すべてのシークレットを公開Gitリポジトリに入れてはいけません。シークレット情報は保護された仕組みで保管し、復旧時にどこから取得するのかを文書化してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

実行環境の定義が、状態を取り巻く環境を再現する

交換用ホストが、USB無線アダプターのマッピング、ネットワークモード、ポート、ホストパス、データベースサービス、MQTTブローカー、環境変数、タイムゾーン、権限など、元のデプロイメントが想定していた要素を再現できなければ、復元した設定ツリーも正常に動作しない場合があります。

Home Assistant Containerのガイダンスでは、更新と永続状態を分け、既知のDockerパラメーターから実行環境を再作成することを前提としています。現在のContainerのワークフローでは、バックアップとイメージの置き換えを別々の操作として扱っています。これは、復旧計画でも維持すべき分離です。

Composeファイルまたは同等のデプロイメント定義を、外部サービスのドキュメントとともに保存してください。実行環境の設定はHome Assistantのデータベースではありませんが、動作するサービスを再現するための一部です。

バックアップは復旧用コピーであり、別の稼働データ役割ではない

バックアップは、復旧対象となる障害を乗り越えられる場所に存在すべきです。すべてのバックアップがアクティブな設定やRecorderデータベースと同じシステムSSDに保存されている場合、1回のストレージ障害で3つの役割すべてを同時に失う可能性があります。

復旧用コピーは、Home Assistantホストを失っても残る必要があります。3-2-1バックアップモデルでは、異なるメディアに複数のコピーを保持し、少なくとも1つをオフサイトに保管します。暗号化されたHome Assistantバックアップでは、緊急復旧キットまたは対応するキーも、障害が発生したシステムの外部に保管しておく必要があります。

• 設定とレジストリ: アイデンティティと自動化の動作を定義するため、復元するか慎重に修復します。
• Recorderと統計: 破損したのが履歴レイヤーだけの場合は、独立して修復、復元、または再構築します。
• シークレットとキー: 障害が発生したホストの外部にある保護されたストアから復旧します。
• 実行環境の定義: マウント、デバイス、ネットワーク、サービスの依存関係を再作成します。
• バックアップ: 稼働環境と同じ障害範囲の外部に復旧用コピーを保管します。

ZimaSpaceのHome Assistantデプロイメント例は、この分離を理解するうえで役立ちます。サーバープラットフォームが変わっても、アプリケーションの状態と復旧に関する責任は、論理的に別々のものとして維持できます。

永続データの役割を分けることが重要なのは、障害が発生した最小のレイヤーだけを修復できるようになるからです。データベースの問題がクリーンインストールにつながる必要はなく、コンテナの更新が設定の喪失につながる必要もありません。