Home Assistantのバックアップでデータベースの不整合な状態が取得されるのを防ぐ方法

エヴァ・ウォン

IceWhale author

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

How to Prevent Home Assistant Backups From Capturing Inconsistent Database State - Zima Store Online

Home Assistantにライブデータベースの状態を調整させるか、rawファイルシステムコピーの前に書き込みを停止して、バックアップの不整合を防ぎます。

危険なのは、単に「Home Assistantの稼働中にバックアップする」こと自体ではありません。問題は、トランザクションの状態を把握せずに、関連するデータベースファイルとアプリケーションファイルを異なる時点で取得するコピー方法です。組み込みバックアップはHome Assistantのコンポーネント間を調整できますが、汎用のrsyncやスナップショットツールにはそれができない場合があります。どの仕組みが整合性を担保するのかを明確にし、データベース負荷の高いジョブが重ならないようにし、以前の正常なバックアップを保持し、分離した復元環境で各ポリシーを検証してください。

稼働中のSQLiteデータベースを通常の静的ファイルとして扱わない

汎用のバックアッププロセスが設定ディレクトリをコピーしている間も、Home Assistant Recorderは書き込みを続けることがあります。SQLiteでは、コミット済みの状態がメインデータベースとジャーナルまたはWALファイルにまたがる場合があるため、異なる時点の状態を混在させると、アーカイブ内にすべてのファイル名が存在していても、不完全または復元不能なコピーになる可能性があります。

稼働中のSQLiteデータベースをバックアップするテストでは、メインデータベースファイルだけをコピーすると、コピー先のデータベースが整合性チェックに合格していても、WALに残っていたコミット済みの行が気付かないうちに欠落する可能性が示されました。このWALを使用したコピーの失敗があるため、rawファイルコピーではデータベース対応のスナップショットを使用するか、データベースを正常に停止させた後に実行してください。

これは、バックアップのたびにHome Assistantを停止しなければならないという意味ではありません。バックアップの仕組みが、整合性のある復旧ポイントを作成する方法を把握していなければならないという意味です。稼働中のインストールにはHome Assistantの組み込みバックアップを使用し、停止後のファイルシステムコピーは、移行、オフラインアーカイブ、またはアプリケーション対応の連携機能を持たない外部ツールに限定してください。

同じ時間帯に競合するバックアップやメンテナンスジョブを実行しない

アプリケーション対応のバックアップであっても、別のプロセスがロックを保持している場合や、ストレージパスが通常とは異なるメンテナンス負荷にさらされている場合、データベースの準備に失敗することがあります。家の中が静かだからといって、2つ目のアドオンバックアップ、データベースメンテナンス、NASスナップショット、Home Assistantバックアップを同じ時刻に開始するようスケジュールしないでください。

実際のHome Assistantバックアップ失敗では、データベースロック準備エラーが報告されており、別のバックアップアドオンが競合の原因だったと突き止めたユーザーもいます。これは予防のためのサインです。競合するツールの実行時間を分け、バックアップ前の準備段階が完了したことをアプリケーションログで確認してください。

メンテナンスの時間帯をずらし、想定所要時間を記録してください。バックアップがRecorderの処理待ちになることが常態化している場合は、まずロックの所有者またはデータベースの健全性に関する問題を特定します。むやみにタイムアウトを延長したり、並列でコピーを増やしたりしないでください。バックアップジョブを増やすと、解消しようとしている競合がかえって悪化する可能性があります。

rawファイルシステムコピーではHome Assistantを停止し、状態ファイル一式を保持する

設定ディレクトリを直接コピーするポリシーが必要な場合は、コピー前にHome Assistantを正常に停止し、プロセスが書き込みを行っていないことを確認してから、メインデータベースファイルだけを選別するのではなく、必要な状態データ一式をコピーしてください。外部データベースのバックアップは、独自の整合性確保方法で管理します。

既存のZimaSpaceによるHome Assistantの稼働中バックアップと停止後バックアップの比較でも、同じ境界が示されています。アプリケーション対応の稼働中バックアップとrawファイルシステムコピーは異なる手順であり、1つのルールに混在させるべきではありません。

コピー後はサービスを再起動し、Recorderが正常に動作することを確認してください。バックアップ先がネットワークストレージの場合は、ネットワークマウントが解除される前にファイル一式のコピーが完了したことも確認します。停止後のコピーでも途中で中断されれば、コピー元が静止していたという狭い意味での整合性しかなく、完全な復旧ポイントにはなりません。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

分離した復元に成功して初めてバックアップを信頼する

一時的なHome Assistantインスタンスまたは復旧先を作成し、本番環境から変更されるファイルを借用せずに候補のバックアップを復元してください。既存のユーザー、履歴データ、ダッシュボード、インテグレーション、自動化の定義、そして少なくとも1回の再起動を確認します。復元にかかった時間と、インスタンスを使用可能にするために必要だった手動修正を記録してください。

Home Assistant Core 2026.7.2では、バージョン限定のリグレッションにより、バックアップ前の準備段階でRecorderがWALチェックポイントに失敗し、その後バックアップマネージャーがデータベースロックの解除を待ってタイムアウトしたことが記録されています。このバックアップ前の失敗シグナルは、その影響を受けた経路に関する証拠、および復旧ポイントの失敗としてのみ扱ってください。すべてのロックタイムアウトが同じ原因で発生することを示す証拠ではありません。

一度に整合性を担保するバックアップの仕組みが1つだけであり、データベース準備段階が完了し、以前の正常なコピーが保持され、復元によってユーザー、履歴、設定、通常の再起動動作が再現できれば、ポリシーに合格です。復元テストに失敗した場合は証拠を保存し、古い復旧ポイントを削除する前に、サポート対象の新しいバックアップまたは管理された停止後コピーを作成してください。