データベースボリュームがいっぱいになった後にHome Assistantを修復する方法
Home Assistantのデータベースボリュームがいっぱいになったら、まず新しい書き込みを停止します。稼働中のデータベースを削除せずに作業領域を確保し、コピーを保存したうえで、復旧方法としてパージ、修復、復元のどれを選ぶか決める前に、Recorderがデータベースを開いて維持できるか確認します。
ボリュームがいっぱいになると、問題解決のために実行しようとしたクリーンアップ操作自体がブロックされることがあります。特に、再パックやデータベースの再構築には一時的な空き容量が必要です。手順は慎重に進めます。Home Assistantを停止し、実際にどのファイルシステムがいっぱいなのかを確認し、関係のないファイルを移動するかボリュームを拡張し、データベースをコピーしてから、ログと整合性を確認し、結果に合った最も破壊的でない復旧方法を適用します。
書き込みを停止し、実際にいっぱいのファイルシステムを確認する
データベースへの書き込みエラーが繰り返し発生したら、すぐにHome AssistantまたはRecorderを停止します。稼働中のデータベースが存在するファイルシステム、マウント、シンボリックボリュームを確認し、総容量、空き容量、inode、データベースサイズ、ログ、バックアップ、コンテナの書き込み可能レイヤーを比較します。システムディスクがいっぱいの場合と、外部データベースボリュームがいっぱいの場合では、必要な対処が異なります。
データベースだけが容量を消費していると決めつけないでください。古いバックアップ、デバッグログ、エクスポート、スナップショット、関係のないコンテナレイヤーが、安全に緊急用の空き容量を確保できる対象かもしれません。用途とバックアップ状況が分かっているファイルだけを移動または削除してください。稼働中のデータベース、WAL、ジャーナル、データベースエンジンのファイルを個別に削除してはいけません。
マップされたデータ以外でDockerのディスク使用量を確認するためのZimaSpaceガイドは、設定されたデータベースパスが小さいように見えるのにホストのシステムディスクが枯渇している場合に、同様の確認を行うための適切な資料です。
作業領域を確保し、データベースを保護する
ボリュームを拡張するか、関係のないアーカイブを検証済みの別ディスクへ移動する方法を優先してください。それが不可能な場合は、メンテナンスを試みる前に、停止したデータベースと関連ファイルを十分な容量のあるストレージへコピーします。所有者、権限、エンジン、Home Assistantのバージョン、データベースURLを記録してください。
ファイルシステムがいっぱいの状態で、緊急対応として最初に再パックを行うのは避けてください。かなりの一時領域が必要になる可能性があるためです。コミュニティでのトラブルシューティングでは、SQLiteの再パックにデータベースサイズと同程度の空き容量が必要になる場合があるとされています。実務上の要点は、ほぼ満杯のボリュームを信用するのではなく、再パックの前に作業領域を確保することです。
空き容量を確保したら、ファイルシステムが書き込み可能で安定していることを確認します。読み取り専用で再マウントされている場合、ハードウェアエラーが報告される場合、またはすぐに再び空き容量が失われる場合は、データベースを開く前に停止し、ストレージ層を修復してください。
パージ、整合性修復、既知の正常なバックアップからの復元を選択する
Home Assistantは、Recorderのログとデータベースの状態を確認するために必要な時間だけ起動します。データベースが問題なく開く場合は、保持期間を短縮するか、更新頻度の高いエンティティを除外し、まず再パックを行わずにパージを実行します。これにより、一時領域を最も多く必要とする手順を避けながら、論理的なデータ量を減らせます。
整合性エラーが表示された場合は、再び書き込みを停止し、コピー上で作業します。データベースエンジンがサポートする整合性チェックおよび復旧ツールを使用するか、既知の正常なバックアップを復元してください。破損したデータベースに対してHome Assistantを繰り返し起動しないでください。新しい書き込みによって復旧が複雑になり、元の障害が分かりにくくなる可能性があります。
使用可能なデータベースのコピーやバックアップがない場合は、新しいRecorderデータベースを作成すれば動作を復旧できますが、履歴は失われます。これは最後の復旧手段とし、失敗したデータベースは後の分析のために保存してください。また、設定とレジストリは履歴に関する判断とは分けて扱います。
サービスを再開する前に増加要因を減らす
何がボリュームをいっぱいにしたのかを特定します。過剰なエンティティ更新、長すぎる保持期間、大量のログ、バックアップの蓄積、失敗したパージ、データベースの肥大化、想定より小さいボリュームなどが考えられます。すべてのクリーンアップオプションを一度に適用するのではなく、測定した原因を修正してください。
妥当な保持期間を設定し、更新頻度が高く履歴の価値が低いエンティティを除外し、ログをデバッグから通常レベルに戻し、バックアップのコピーをホスト外へ移動します。空き容量と増加率の両方に対してアラートを設定してください。アップグレード、バックアップ、スキーマ変更、メンテナンスのための作業領域も残しておきます。
破損や整合性エラーが繰り返し発生し、既知の正常なバックアップから復元するほうが継続的な修復より信頼できる場合は、ZimaSpaceのデータベースのメンテナンスと交換の判断基準と復旧したデータベースを比較してください。
Recorderの負荷下で復旧を検証する
Home Assistantを起動し、現在の状態、新しい履歴の書き込み、ログブックのクエリ、自動化アクション、データベースサイズを確認します。障害の前に発生していた更新頻度の高い負荷を再現しながら、空き容量、書き込みエラー、データベースの遅延、増加率を監視します。
Home Assistantを2回再起動し、次回のスケジュール済みパージまたはバックアップを実行します。データベースが再び開き、履歴が更新され、空き容量が停止基準を上回ったまま維持され、整合性エラーや読み取り専用エラーが再発しなければ、復旧は成功です。
メンテナンスによって新たな破損が発生した場合、履歴が予期せず消えた場合、またはボリュームが同じ速度で再びいっぱいになり始めた場合は、保存しておいたコピーまたは既知の正常なバックアップへ戻します。ストレージ障害、データベースエンジンのエラー、再現性のあるRecorderの障害については、ログと保存したタイムラインを添えてエスカレーションしてください。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けにHome Assistantのデータベース接続を最適化する方法
実測したアクティブ接続数とレイテンシーに基づいて外部Recorderデータベースを調整し、最大接続数を増やしたり、別のホストのプールをコピーしたりしないでください。
Home Assistantでジョブやインポートの重複を防ぐ方法
トレースと一意の操作キーを使用して、重複するアクションやレコードを生成せずに自動化とインポートを安全に再試行できるようにします。
Home Assistantは、欠落したファイルを誤った所有者で再作成するのはなぜですか？
実行時のUIDとGIDをホストのパスに合わせ、停止中に影響を受けたファイルのみを修復し、再作成後に所有権を確認します。
