スタックを再作成すると、Home Assistant が永続データにアクセスできなくなるのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Home Assistant Lose Access to Persistent Data After Stack Recreation?

同じ永続的な/configデータを再度マウントするのであれば、Home AssistantのDockerまたはComposeスタックを再作成しても設定が消えることはありません。再作成後にオンボーディング画面が表示されたり、インテグレーションが見つからなくなったりした場合、まず疑うべきなのは、Home Assistantが家庭内の状態を削除したことではなく、新しいコンテナが異なるストレージを参照していることです。

古いバックアップを復元する前に、実際のマウント、ホストパス、名前付きボリューム、隠しファイル、権限を確認してください。誤った空のディレクトリは設定が失われたように見えても、元のデータがホスト上の別の場所に無傷で残っている場合があります。

/configに実際にマウントされているものを確認する

実行中のコンテナを調べ、/configに割り当てられているマウント元を確認します。見慣れたフォルダー名だけを頼りにせず、以前のComposeファイルやデプロイ記録と照合してください。

Dockerのバインドマウントは、対象ディレクトリに対するコンテナ側の見え方を置き換えます。現在のバインドマウントのドキュメントでは、ホストディレクトリを空でないコンテナパスにマウントすると、そこにあったファイルが見えなくなると説明されています。そのため、空または誤ったソースパスを指定すると、Home Assistantには空の/configとして認識されます。

マウントが正しいと確認できるまで、オンボーディングを実行したり、新しいインテグレーションの作成を始めたりしないでください。誤ったディレクトリへの新たな書き込みによって、後の復旧がさらに複雑になります。

バインドマウントと名前付きボリュームを区別する

Composeスタックでは、明示的なホストパスまたはDocker管理の名前付きボリュームを使用できます。異なるプロジェクト名、ボリューム名、パスでプロジェクトを再作成すると、古いボリュームが残ったまま、新しい空の永続ストレージが作成されることがあります。

現在のDockerボリュームガイドでは、名前付きボリュームは個々のコンテナから独立してデータを保存し、コンテナの置き換え後に再接続できると説明されています。したがって、コンテナの削除は、永続ストレージの削除や置き換えとは異なります。

古いボリュームと新しいボリュームを一覧表示し、Dockerを通じてマウントポイントを調べ、作成時刻と内容を比較してください。どのボリュームにHome Assistantの正式な状態が保存されているか分かるまで、pruneコマンドは実行しないでください。

隠しファイルがあると、コピーが完全に見えても実際には不完全な場合がある

Home Assistantは、.storageなどの隠しパスに重要なUI管理状態を保存します。*のようなグロブを使ったシェルコピーや、ドットファイルを非表示にするファイルマネージャーでは、YAMLファイルだけが移動され、重要なレジストリやインテグレーションの状態が気付かないまま取り残されることがあります。

2025年のDockerからComposeへの移行事例では、まさにこの問題が再現されています。コピー操作でHome Assistantの隠し状態がコピーされなかった、または適切に扱われず、設定ツリー全体とメタデータを正しくコピーして初めて移行が安定しました。

ドットファイルを含むディレクトリ一覧を比較し、データ自体が破損していると判断する前に、所有者、タイムスタンプ、想定される隠しディレクトリの存在を確認してください。

Featured

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

ZimaCube2

データを再度コピーする前に権限を確認する

再作成したコンテナに読み書き権限がない場合、正しいディレクトリでも使用できないように見えることがあります。これは、データを新しいファイルシステムに移動した場合、Dockerの動作モードを変更した場合、別のホストから復元した場合、UID/GIDのマッピングを変更した場合によく発生します。

2026年に確認されたDocker Engineのトラブルシューティングガイドでは、こうした問題の原因を、実際のホストパス、コンテナのUID/GID、親ディレクトリへのアクセス、マウントモード、セキュリティ境界に絞り込んでいます。読み取り専用設定や所有者の不一致により、ファイルが見えていてもHome Assistantが状態を更新できないことがあります。

設定ツリー全体に誰でも書き込める権限を付与するのではなく、限定的な所有権またはマウントの問題を修正してください。

永続パスが正しいと確認してからスタックを再作成する

問題なく動作していたCompose定義、イメージタグ、ネットワークモード、デバイス、/configのソースをそのまま使用してください。Home Assistantを起動し、移行や新しい設定変更を許可する前に、想定されるユーザー、ダッシュボード、インテグレーション、オートメーション、ヘルパーが戻っていることを確認します。

ZimaSpaceの単一コンテナの復旧手順でも同じ原則を適用します。つまり、スタックの無関係な部分を復元または置き換える前に、実際のマウントを確認し、正常な依存関係を再接続します。

正式なデータが本当に失われている場合は、バックアップの復元に進んでください。データが存在しているのに新しいコンテナから見えない、または変更できない場合、問題はHome Assistantの設定そのものではなく、ストレージのマッピングまたは権限の境界にあります。