ユーザー、履歴、設定を失わずにHome Assistantのデータを移行する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Move Home Assistant Data Without Losing Users, History, or Settings - Zima Store Online

完全なアプリケーション状態を保持し、移行先が完全な検証に合格するまで旧インスタンスをそのまま維持することで、Home Assistantのデータを移行します。

ユーザーや設定は、目に見えるYAMLファイルだけではありません。ダッシュボードをコピーしても履歴は再作成されません。移行では、Home Assistantの設定ディレクトリまたはサポート対象のバックアップ、履歴が必要な場合はRecorderデータベース、非表示のストレージ、シークレット、カスタムコンポーネント、それらに関連するランタイム固有のデバイスおよびネットワークマッピングを保持する必要があります。最も安全な手順は、インベントリ作成、一貫性のあるコピー、分離した状態での起動、検証、そして移行元の廃止です。

移行前に永続状態と外部依存関係を一覧化する

Containerインストールでは、使い慣れたファイルをいくつか選ぶのではなく、マウントされたHome Assistant設定ディレクトリ全体を復旧の基本単位として扱います。.storage内の非表示状態、認証データ、インテグレーションレジストリ、ダッシュボード、オートメーション、デフォルトのRecorderデータベースは、すべてそのパス以下に保存される可能性があります。外部MariaDB、MQTT、Zigbeeゲートウェイ、シークレットストア、NASマウントは別途一覧化する必要があります。

Home Assistantコンテナの移行手順では、ファイル単位で状態を再構築するよりも設定ディレクトリ全体の移行の方が安全である理由が示されており、ファイルシステムをそのままコピーする前に旧コンテナを停止することも強調されています。

移行元パス、移行先パス、所有者のUID/GID、データベースの場所、USBまたはシリアルデバイス、ネットワークモード、公開ポート、外部サービス、現在のHome Assistantバージョンを含むマニフェストを作成します。文書化されていない依存関係が1つでもある場合は、旧インスタンスを削除しないでください。新しいホストがその依存関係を文書化された情報から再現できるようになるまで、移行の準備は完了していません。

データをコピーする前に一貫性のあるロールバックポイントを作成する

インストール環境が対応している場合は、組み込みバックアップまたはアプリケーション対応の別の方法を使用します。Containerをそのままコピーする場合は、稼働中の設定データベースと関連ファイルをコピーする前にHome Assistantを停止します。単純な稼働中コピーでは、アプリケーションファイルが異なる時点の状態で取得される可能性があり、これは管理された移行とは正反対です。

Home Assistantのバックアップ機能の刷新により、インストール方法をまたいだ復元サポートが拡張されました。そのため、ランタイムを変更する際には、サポート対象のバックアップが高い移植性を持つ境界になります。インストール環境をまたいだバックアップ復元から得られる実践的な教訓は、新しいランタイムが変わっても、アプリケーション状態が継続性の境界として維持されるということです。

2つのコピーを保持します。1つは移行前の変更していない復旧ポイント、もう1つは移行に使用する作業用コピーです。新しいHome Assistantインスタンスを、唯一の正常な移行元コピーに対して起動させないでください。移行先で移行処理が実行されたり、新しいレジストリ状態が書き込まれたりしても、旧バージョンと旧ホストへ戻れるクリーンな経路を確保しておく必要があります。

ランタイム固有のハードウェアとネットワークマッピングを個別に再構築する

アプリケーションデータによって、ホストのデバイスパスまで自動的に再現されるわけではありません。ZigbeeまたはZ-WaveのUSBコーディネーターは別のデバイス名で認識されることがあり、Bluetoothへのアクセス条件が異なる場合もあります。ホストネットワークの変更によって検出動作が変わったり、外部データベースやMQTTブローカーが別のアドレスで解決されたりすることもあります。データ損失によってインテグレーションが利用できないと判断する前に、これらのインターフェースを明示的に再構築してください。

独立したContainerからHAOSへの移行手順では、Home Assistant Coreの状態を復元しても、MQTT、Zigbee2MQTT、Node-REDなどのサイドカーサービスは自動的に再作成されないことが示されています。そのサイドカー再マッピング移行手順では、Recorder履歴の継続性、USBコーディネーターへのアクセス、そしてロールバック経路として停止済みだが完全な状態で保持された旧スタックも検証します。

移行先は管理されたLAN経路で起動し、意図的に分離していない限り、同じ無線機器、Webhook、クラウドアカウント、オートメーションを両方のインスタンスで実行しないでください。2つのHome Assistantインスタンスを同時に稼働させると、アクションが重複して送信されたり、同じコーディネーターを奪い合ったりして、正しいデータ移行であっても壊れているように見えることがあります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

切り替え前にユーザー、履歴、設定、デバイス制御を検証する

既存の非管理者アカウントでログインし、管理者アカウントを確認し、移行前の履歴グラフを開き、インテグレーションを点検し、代表的なオートメーションを実行し、重要な各プロトコルから少なくとも1台のデバイスを検証します。その後、Home Assistantを再起動し、移行先ホストを再起動して、通常のライフサイクルイベント後も復元した状態が維持されることを確認します。

ZimaSpaceの関連記事であるHome Assistantの永続データの役割では、移行時の有用な復旧境界が説明されています。永続的なID、設定、履歴は、キャッシュや一時ファイルとは異なるものとして扱う必要があります。

ローカルテストに合格してから、DNS、プロキシ、またはリモートアクセスを切り替えます。旧ホストは、少なくとも通常利用の1サイクルが完了するまで、電源を切った状態で復旧可能にしておきます。ユーザー、履歴、設定、オートメーション、無線機器、外部サービス、バックアップ作成、再起動がすべて期待どおりに動作してから廃止してください。最初にダッシュボードが正常に表示されたことだけでは、ロールバック経路を消去する十分な根拠にはなりません。