Home AssistantのメタデータをSSDに、バルクデータをHDDに保存すべき？

エヴァ・ウォン

IceWhale author

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

Should You Put Home Assistant Metadata on SSD and Bulk Data on HDD? - Zima Store Online

通常はそのとおりです。Home Assistantのアクティブな設定、レジストリ、メタデータ、ローカルデータベースは信頼性の高いSSDに保持し、大容量メディア、カメラ録画、エクスポート、二次バックアップコピーはHDDストレージに配置します。

重要な境界は、単純に小さなファイルと大きなファイルを分けることではありません。Home Assistantの/configツリーには密接に関連した永続状態が含まれ、Recorderは頻繁にデータベース処理を行い、外部マウントは起動順序や可用性への依存関係を追加します。アクセスパターンごとにデータを分け、すべてのマウントを記録し、分離構成を信頼する前に再起動とリストアを検証してください。

アクティブなHome Assistantの状態はSSD上でまとめて保持する

/configを1つの復旧単位として扱います。通常、YAML、シークレット、.storageディレクトリ、レジストリ、インテグレーションの状態、そしてSQLiteを使用している場合はアクティブなデータベースが含まれます。個々の隠し状態ファイルをマウント間で分割すると、所有範囲、起動順序、リストア対象の把握が難しくなります。

Recorderは継続的に書き込むため、そのストレージ動作は時々開くだけのアーカイブとは異なります。独立したトラブルシューティングガイダンスでは、アクティブなHome Assistantデータベースには高速ストレージを推奨しています。頻繁な読み書きによって低速なメディアが履歴表示や自動化の遅延として表面化する可能性があるためです。確認すべき有用な根拠は、アクティブなデータベースに高速ストレージを使用することであり、すべてのSSDがあらゆるボトルネックを解消するという保証ではありません。

外部のMariaDBまたはPostgreSQLサービスを使用する場合、データベースは独自のバックアップ、認証、ネットワーク、アップグレード境界を持つ、別個のステートフルシステムになります。データベースURLの変更を、単純なファイル配置の変更として扱わないでください。

容量を大きく消費するデータは、明確な境界がある場合にのみ移動する

大容量のメディアファイル、長時間のカメラ録画、エクスポートしたレポート、追加のバックアップコピーは、そのパスにライブ設定やデータベースが含まれていない場合、HDDストレージに移すのが合理的です。これらのワークロードでは通常、小さなランダムI/Oのレイテンシーよりも容量が重視されます。

ホスト上のパスを明示的に作成し、安定したコンテナ内の場所にマウントします。/config全体を覆う広範な親マウントを指定しないでください。空のホストパスや、遅れてマウントされたホストパスによって想定していたデータが隠れ、Home Assistantが新規インストールされたように見える可能性があります。コンテナの起動前にHDDがマウントされていることを確認し、利用できない場合の動作も決めておきます。

Home Assistantのメタデータと履歴の増大に関する関連するZimaSpaceの記事は、各クラスをストレージ階層に割り当てる前に、レジストリ、Recorderの履歴、ログ、バックアップを分けて考えるのに役立ちます。

両方のストレージ階層にまたがるバックアップを計画する

どのバックアップが/config、アクティブなデータベース、HDD上のパス、外部データベースを取得するのかを書き出します。別途マウントされたメディアやデータベースのパスが、完全に見えるアーカイブから除外されることがあります。また、データベースへの書き込み中にファイルシステムコピーを取得すると、一貫性がなくなる可能性があります。

少なくとも1つのバックアップコピーはHome Assistantホストの外部に保管してください。SSDとHDDの分離は配置を改善しますが、削除、電源障害、コントローラーの故障、両方のディスクに及ぶ不適切な移行から保護するものではありません。暗号化キーと認証情報は同じマシン上ではなく、復旧計画とともに記録してください。

マウントを変更する前に、正常性が確認されたバックアップを作成し、現在のエンティティ数、インテグレーション、最近の履歴、ダッシュボード、自動化、メディアパスを記録します。これらの観察結果は、再作成後の受け入れテストになります。ログインページが開くかどうかだけを確認するよりも有用です。

Featured

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

ZimaCube2

再起動、負荷、リストアを通じて分離構成を検証する

マウントの順序をテストするため、Home Assistantだけでなくホストも再起動します。Home Assistantが書き込みを開始する前に、/configがSSDのパスを解決し、すべての大容量データ用マウントが意図したHDDのパスを解決することを確認してください。どちらかの場所に空のディレクトリがある場合は、作業を中止すべき状態です。

元のワークロードを実行します。履歴を開き、負荷の高い自動化をトリガーし、録画またはメディアファイルを書き込み、バックアップを作成してください。合格条件は、操作性が維持され、意図したディスクにデータが書き込まれ、データベースや権限に関する警告がなく、ホストのI/Oレイテンシーが通常範囲に収まることです。

最後に、隔離したテストインスタンスへリストアし、両方のストレージ階層を検証します。Home Assistantが空のレジストリで起動する、履歴が古い、メディアが見つからない、またはマウント依存の障害が発生する場合は、分離構成を元に戻してください。より単純なSSD上の/configとHDD上の大容量データという境界では容量や可用性の要件を満たせない場合にのみ、外部データベースやストレージ構成の再設計を検討します。