ストレージパスの変更後、Home Assistantに古いデータが表示される

エヴァ・ウォン

IceWhale author

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

Home Assistant Shows Stale Data After a Storage Path Change - Zima Store Online

ストレージパスを変更した後に Home Assistant のデータが古いままになる場合、通常は Home Assistant がメモリから古い状態を再生成したのではなく、想定とは異なる /config またはデータベースを実行中のインスタンスが読み取っていることを意味します。

パスの変更をいったん止め、古いデータ場所と新しいデータ場所の両方を保持してください。実行中のコンテナから、マウント元、アクティブなデータベースとインスタンスを特定し、タイムスタンプと固有の状態を比較してから、1つのマッピングだけを修正します。履歴やレジストリが上書きされる可能性がある場合は、コピーや名前変更を行う前に Home Assistant を停止してください。

実行中のコンテナが実際に認識しているパスを確認する

Compose ファイルだけでなく、実行中のコンテナを調べてください。/config に割り当てられたホスト側のソース、バインドマウントか名前付きボリュームか、解決されたソースが存在し、想定した設定ファイルを含んでいるかを確認します。宣言が正しく見えても、再作成が不完全だった場合は、実行中のコンテナと異なることがあります。

解決済みの移行に関する議論では、コンテナの移動には、適切な権限で使用できるバインドマウントされた設定フォルダーが必要だと強調されています。これはまず実際のマッピングを確認する根拠になりますが、古いデータが表示されるすべてのケースが権限の問題だと証明するものではありません。

Home Assistant を停止した状態で、意図したホスト側のパスに害のないマーカーファイルを作成し、一時的な検査用コンテナ内の /config から同じマーカーが見えることを確認します。存在しなければマッピングを修正してください。存在する場合は、データベースとインスタンスの識別情報を確認します。

古いファイルコピーと外部データベースを区別する

古いパスと新しいパスについて、変更日時といくつかの固有の設定情報を比較します。たとえば、自動化の名前、ダッシュボードの変更、ヘルパー、または最近のバックアップなどです。新しいディレクトリが単に古いコピーである場合、Home Assistant の実行中にファイルを選択的に統合しないでください。正しい一式を選び、停止した状態で一貫した単位としてコピーします。

Recorder のデータベース URL を確認します。/config を移動しても、外部の MariaDB や PostgreSQL データベースは移動せず、復元した設定が以前のデータベースを指したままになっている可能性があります。現在のエンティティが正しいのに履歴だけが古い場合は、設定全体の不一致よりもデータベースの問題である可能性が高くなります。

ZimaSpace のスタック再作成後の永続データに関する記事では、隣接する障害パターンについて説明しています。空のマウントはデータ損失のように見える一方、古いマウントはデータが過去の状態に戻ったように見えることがあります。

重複したインスタンスとクライアント側だけのキャッシュを除外する

ブラウザーの URL、サーバー名、IP アドレス、インスタンス ID、証明書が、意図した Home Assistant ホストのものであることを確認します。移行中は、古い DNS レコード、リバースプロキシの転送先、モバイルアプリのサーバー登録、または電源が入ったままの古いホストによって、クライアントごとに異なるインスタンスへ接続されることがあります。

プライベートブラウジングセッションと別のクライアントで、同じエンティティと履歴のタイムスタンプを比較します。1つのクライアントだけが古く、サーバーログと別のクライアントが最新である場合は、ストレージを再度変更するのではなく、そのクライアントの接続またはキャッシュされたフロントエンドデータを消去します。

クライアントによって古い状態と新しい状態が交互に表示される場合は、古いインスタンスを停止し、DNS、プロキシ、またはロードバランサーの転送先を修正します。識別情報を調査している間、同じデバイスに対して2つのコントローラーで自動化を実行させないでください。

Featured

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

ZimaCube2

1つのマッピングを修正し、ロールバック用コピーを保持する

Home Assistant を停止し、候補となる両方のパスをスナップショットまたはコピーして、ホスト、日付、既知の状態を記録したラベルを付けます。/config とデータベースを、対応する一組の復旧セットとして選択します。確認済みの不一致の原因となっているコンテナのマッピングまたはデータベース URLだけを修正します。

起動する前に、所有者と書き込み権限を確認します。コンテナが選択したパスを読み取れても書き込めない場合、最初は正しく見えても、その後新しい状態の永続化に失敗することがあります。サービスの実行ユーザーと想定される所有権を確認せずに、広範な再帰的権限変更を行わないでください。

Home Assistant を一度起動し、さらに編集する前にログを確認します。想定したエンティティ、ダッシュボード、履歴、最近の変更が表示されたら、永続化のテストを続けます。表示されない場合は、2つのデータツリーを統合するのではなく、停止してラベル付きコピーへロールバックしてください。

再作成と再起動後も正しいデータが保持されることを確認する

一時的なヘルパーを作成する、またはテスト用自動化の名前を変更するなど、元に戻せるテスト変更を1つ行います。Home Assistant を再起動し、変更が保持されることを確認します。その後、保存したデプロイ設定からコンテナを再作成し、もう一度確認します。

成功と判断できる結果は、同じインスタンス識別情報、想定した履歴、最新のレジストリ、正しいマウント元、書き込みの成功、重複したコントローラーが存在しないことを示します。新しいバックアップに選択した状態が含まれていることを確認し、両方の移行パスから離れた場所に保管します。

クライアントによってデータが変化する場合、履歴がライブ状態とは別のデータベースから取得されている場合、または再起動後に正しいパスが読み取り専用になる場合は、詳しい調査が必要です。マウントの検査結果、データベース URL、タイムスタンプ、ログ、手を付けていない2つのロールバック用コピーを保持し、次の対応で残った可能性を特定できるようにしてください。