Home Assistantのアプリデータ、キャッシュ、バックアップを分離する方法

Eva Wong は テクニカルライター であり、 生粋の技術好き としてZimaSpaceで活動しています。ホームラボやオープンソースソフトウェア をこよなく愛する生粋のギークで、複雑な技術概念をわかりやすく、実践的なガイド にまとめることを得意としています。Evaは、セルフホスティングは難しいものではなく、楽しむものだと考えています。チュートリアルを通じて、初めてのNAS構築からDockerコンテナの使いこなしまで、コミュニティがハードウェアのセットアップをわかりやすく理解できるよう 支援しています。、初めてのNAS構築からDockerコンテナの習得まで。

Home Assistantのアプリデータ、キャッシュ、バックアップを分けるには、まず、障害時にも残す必要があるもの、自動的に再構築できるもの、Home Assistantホストの外部に保存すべきものを決めます。永続的な設定やデータベースの状態には、安定したストレージとバックアップが必要です。破棄可能なキャッシュや一時ファイルには、同じ保持ルールを適用しないでください。また、バックアップは、復旧対象のディスクに依存しないようにしてください。

最も安全なのは、フォルダー名ではなく役割に基づいてデータを配置することです。すぐに容量が増えるというだけで、ディレクトリを「キャッシュ用ストレージ」に移さないでください。破棄可能と見なす前に、Home Assistantまたは連携サービスがそのデータを履歴、識別情報、ペアリング、認証情報、復旧に必要としているか確認してください。

データを正本、再構築可能なデータ、復旧用コピーに分類する

正本となるアプリデータには、Home Assistantの設定、シークレット、インテグレーションの状態、自動化の定義、そして保持したいデータベースやその他の状態が含まれます。再構築可能なデータには、ダウンロード済みのイメージ、一時ファイル、パッケージキャッシュ、トランスコードデータ、サービスが家庭内の設定を失うことなく再作成できるインデックスなどがあります。復旧用コピーは、障害発生後に正本の状態を再構築するためのバックアップやエクスポートです。

この分類はサービスごとに行う必要があります。Home Assistant、MQTT、データベース、リバースプロキシ、Zigbee2MQTTでは、それぞれ永続化が必要な状態が異なる場合があります。管理インターフェースにはスタック定義が保存されていても、ワークロードデータそのものは含まれないことがあります。コンテナ管理のバックアップにワークロードの状態が含まれないことがある理由を見ると、「Dockerをバックアップした」という説明が、想定よりもはるかに限定的な意味になり得ることがわかります。

Home Assistantの設定とアクティブなデータベースは安定したストレージに保管する

コンテナ環境では、Home Assistantの設定パスをコンテナイメージとは独立して永続化する必要があります。レコーダーデータベースがその設定ツリー内にある場合、それはキャッシュではなく、アプリケーションのアクティブな状態です。このデータは、通常のデータベース処理や復旧作業に十分な空き容量がある、信頼性の高いSSDなどの低レイテンシーストレージに保存してください。

レコーダーの処理では継続的に細かな書き込みが発生することがあり、特に多くのエンティティが頻繁に変化する場合に顕著です。Home Assistantコミュニティで長く議論されているレコーダーの保持期間がデータベースの増大に与える影響は、設定ツリー全体を一時ストレージに移してデータベースの書き込みを隠すのではなく、不要な履歴を減らすことに焦点を当てているため、参考になります。

破棄可能と確認できたキャッシュと一時データのみを移動する

キャッシュや一時データは、高速なスクラッチ用デバイス、容量を制限したメモリ上のファイルシステム、または削除ルールを設けた専用ディレクトリに保存できます。ただし、失われても問題がない場合に限ります。テスト用コピーを削除した後、関連サービスを再起動し、必要なデータが再構築されることを確認してください。サービスがペアリング情報、履歴、ユーザー、認証情報、または設定を失う場合、そのデータは破棄可能ではありません。

変化の多いデータを分離すると、書き込みを減らし、バックアップを小さくできます。ただし、マウント先に必要なファイルを隠したり、RAMへの隠れた依存を生じさせたりしてはいけません。ZimaSpaceのHome Assistantのキャッシュと一時ストレージの分離では、マウントを変更する前に再生成可能なデータを特定するための方法を詳しく説明しています。

バックアップは異なる障害ドメインに保存

稼働中の設定と同じ場所に保存したバックアップは、誤った編集からは保護できますが、SSDの故障、ホストの盗難、ファイルシステムの破損、ストレージコントローラーの故障には備えられません。回避したい障害に応じて、Home AssistantのバックアップをNAS、別のサーバー、リムーバブルストレージ、またはオフサイトの保存先にコピーしてください。Home Assistant自体が停止しているときにも利用できる場所に、復旧キーや認証情報を保管してください。

バックアップの内部整合性も必要です。ボリュームのアーカイブは便利ですが、状態を持つサービスでは、連携したダンプやスナップショット、またはサービスを停止した状態でのコピーが必要な場合があります。独立した永続ボリュームのバックアップと復元のパターンでは移植性の問題を説明し、バックアップが使えることを証明する復元テストでは、有用な状態を復旧できるまではバックアップジョブの有効性は証明されないことを強調しています。

削除、再起動、復元の訓練でレイアウトをテスト

パスを分離したら、それぞれの役割が約束どおり機能するかテストします。破棄可能なキャッシュを消去し、再構築されることを確認します。Home Assistantコンテナを作り直し、永続化された設定が残っていることを確認します。ホストを再起動し、依存するサービスの起動前にマウントが完了することを確認します。最近のバックアップを一時的な保存先に復元し、ユーザー、自動化、インテグレーション、代表的な履歴または連携サービスの状態を確認します。

次に、所有者と権限を記録します。ディスク上でパスを完全に分離していても、新しいコンテナのUID/GIDで読み取れなければ、移行後に問題が起きることがあります。マウントポイント、ファイルシステムの所有権、バックアップの対象範囲、保持期間、各ディレクトリの削除を許可されているサービスを記録してください。

データの役割 一般的なストレージ 復旧ルール
Home Assistantの設定/データベース 安定したSSD/アプリデータプール 永続化してバックアップ
破棄可能なキャッシュ/一時データ スクラッチ用SSDまたは容量を制限した一時ストレージ 安全に再構築できること
バックアップ ホスト、メディア、オフサイトの保存先を分離 復元テスト済み
大容量アーカイブ 容量重視のストレージ 価値に応じて保護

キャッシュを削除してもHome Assistantが壊れず、コンテナを作り直してもアプリの状態が消えず、プライマリアプリデータ用デバイスを失っても唯一の復旧用コピーが失われないなら、ストレージの分離は成功です。障害が発生する前に、ストレージの役割から障害時の挙動が明確に分かるようにしておきましょう。

NASとサーバーのセットアップ

続きを読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.