コンテナの更新に失敗した後にHome Assistantを復元する方法

Home Assistantコンテナの更新に失敗した場合、通常は新しいインストールを作成するのではなく、ランタイムを置き換える問題として扱うべきです。ホストにマウントされた/configディレクトリが無事なら、その状態を保持し、ボリュームのマッピングを確認し、既知の正常なイメージを起動して、古いバックアップを復元する前に既存のインストールをテストするのが最も安全な復旧方法です。

危険なのは、新しいコンテナを誤った、または空のホストパスに対して起動することです。その場合、Home Assistantは設定が消えたかのようにオンボーディング画面を表示することがありますが、元の状態はディスク上の別の場所に残っている可能性があります。まず変更を停止し、正式な設定ディレクトリを特定してください。復旧したインスタンスが合格するまで、古いコンテナやディレクトリを削除しないでください。

新たな書き込みを停止し、本当の/configパスを見つける

失敗したコンテナを停止し、それを作成したランタイム定義を確認します。/configに割り当てられているホストディレクトリまたは名前付きボリュームを確認し、その場所にYAMLファイル、.storage、カスタムコンポーネント、シークレット、データベースがあるか調べます。

Dockerのアップグレード後に発生したあるコミュニティの復旧事例では、「まったく新しい」Home Assistantインスタンスが表示された原因は、コンテナが誤った設定フォルダを参照していたことでした。永続データが消去されたのではなく、置き換えられたランタイムが正しくマウントしていなかっただけです。

所有者、パス、データベースファイルを変更する前に、現在の設定ディレクトリをコピーまたはスナップショットしてください。部分的に壊れた状態でも貴重な手がかりとなり、最後のバックアップより新しいオートメーションや認証情報が含まれている可能性があります。

インストールを作り直さずにランタイムを再作成する

更新前に正常に動作していたコンテナと同じネットワークモード、タイムゾーン、デバイスマッピング、USB無線機器へのアクセス、権限またはケイパビリティ、そしてホストの/configマウントを使用します。イメージは交換可能ですが、これらのランタイム入力と永続データによって、サービスが同じHome Assistantインスタンスとして復帰できるかどうかが決まります。

コンテナの永続性は、コンテナのファイルシステムではなくホストマウントに依存します。Home Assistant Containerの例では、永続的なホストボリュームを直接/configにマウントしているため、ランタイムを再作成しても家庭の設定は再作成されません。更新中にこのマッピングが変わると、元の状態が別の場所に残ったまま、置き換えたコンテナが初期状態のように見えることがあります。

古いコンテナのファイルシステムを新しいイメージにコピーしないでください。文書化したComposeまたはrun定義からデプロイメントを再作成し、永続状態を明示的に再接続してください。

古い状態を復元する前にイメージをロールバックする

設定マウントが正しいにもかかわらず、新しいHome Assistantのバージョンが起動しない、または重要なインテグレーションを壊している場合は、保持した同じ/configに対して、以前正常に動作していたイメージをテストします。これにより、「新しいランタイムが現在の状態と互換性がない」のか、「状態そのものが壊れている」のかを切り分けられます。

現在のHome Assistant Containerのワークフローでは、イメージと永続状態を明確に分離しています。まずバックアップを取り、対象イメージを取得してコンテナを再作成し、ダウングレードが必要な場合は特定の古いイメージタグを使用するという手順です。維持すべき復旧の境界はここにあります。正式な設定パスを保持したまま、ランタイムだけを交換してください。

ロールバック時は、一部のアップグレードでデータ構造が移行されることに注意してください。新しいバージョンによってすでにアップグレードされた状態を古いバージョンが安全に読み取れない場合は、移行前に取得したバックアップを使用します。永続データの唯一のコピーに対して、バージョンを何度も切り替えないでください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

現在の状態を信頼できない場合にのみバックアップを復元する

永続的な設定が欠落している、破損している、一部上書きされている、または安全に実行できるバージョンと互換性がなくなっている場合は、バックアップを使用します。可能であれば、復元先を分離した環境またはクリーンな環境にして、復元した状態と破損したコピーを比較できるようにしてください。

バックアップを開くために必要な暗号化パスワードまたは緊急キットは、障害が発生したホストの外部に保管してください。同じディスクにしか存在しないバックアップや、復号できないバックアップは、復旧手段になりません。

ZimaSpaceによる、Home Assistantの復旧をストレージホスト自体から分離する例も、同じ原則を示しています。アプリケーションの状態には、稼働中のディスクをミラーリングするだけでなく、独立した復元経路が必要です。

何も削除する前に復旧したコンテナを検証する

• 想定していたユーザー、ダッシュボード、インテグレーション、オートメーション、ヘルパー、エリアが存在することを確認します。
• Zigbee、Z-Wave、Bluetoothを使用している場合は、ローカルデバイスのパスを1つ、無線ベースのパスを1つ確認します。
• Recorderでデータベースまたは移行エラーを確認します。
• 復旧したコンテナを再起動し、同じ状態が戻ることを確認します。
• この2回目の起動が成功するまで、古いイメージタグ、設定のコピー、最後に正常だったバックアップを保持します。

元の設定で古いイメージが動作するなら、更新の失敗は主にランタイムまたはバージョンの問題です。すべてのイメージが同じ状態に対して失敗する場合は、設定の修復またはバックアップの復元に進みます。空の/configでしかクリーンなコンテナが動作しない場合は、永続状態の何が復旧を妨げているのかを理解するまで、新しいセットアップを「修正済み」と見なさないでください。

よくある質問

トラブルシューティングの前に、失敗したHome Assistantコンテナを削除すべきですか？

いいえ。まず停止し、ランタイム定義とマウントされた設定パスを保持してください。失敗したコンテナを削除せずに置き換え用のコンテナを作成できるため、新しいランタイムを検証する間もロールバック情報を利用できます。

更新後にHome Assistantでオンボーディング画面が表示されるのはなぜですか？

コンテナ固有の最も一般的な理由は、置き換えたランタイムが元の/configパスを参照していないことです。設定が消去されたと考えたり、より新しい状態に古いバックアップを上書きして復元したりする前に、ホストマウントを確認してください。