現在のHome Assistantのインストールでは、まず組み込みのバックアップシステムを使用し、Home Assistantをオンラインにしたまま実行してください。サービスを停止または静止させるのは、単純なファイルシステムのコピーを作成する場合や、稼働中のデータベースと連携しない別の方法を使用する場合だけにしてください。
したがって本当の判断基準は、単純な「稼働中か停止中か」ではなく、「サポート対象のアプリケーションバックアップか、汎用的なファイルコピーか」です。rsync、SMBコピー、VMスナップショット、アーカイブコマンドが正常に完了しただけでは、データベースとHome Assistantのその他の状態が、同一の一貫した復旧ポイントとして取得されたことにはなりません。
まずは組み込みのバックアップ経路を使用する
Home AssistantのBackup統合は現在、さまざまなインストール方式でバックアップの作成と復元に対応しています。CoreおよびContainerでは、backup.createアクションにHome Assistantの設定とデータベースが含まれ、システムをオンラインにしたまま実行できます。
このサポート対象の経路を、通常の復旧ポイントの基準にしてください。暗号化キーまたは緊急キットはHome Assistantホストの外部に保管し、少なくとも1つのバックアップをホスト外へ移し、アップグレードや移行に使用する前にバックアップを復元できることを確認してください。
組み込みバックアップでは対応できない理由がある場合に限り、手動のファイルシステムコピーへ移行し、その際はデータベースの整合性をどのように確保するかを明確にしてください。
単純な/configコピーの場合のみHome Assistantを停止する
サービスを停止することは、汎用的な設定ディレクトリのコピーを内部的に一貫した状態で作成する最も簡単な方法です。まず保存先、権限、空き容量を準備し、その後Home Assistantを停止してツリーをコピーし、処理を確認してからサービスを再起動してください。
実用的なコンテナ移行の手順では、まさにこの境界を使用します。SQLiteを基盤とする永続設定をコピーする前にコンテナを停止します。これは生のファイルシステム転送には適していますが、組み込みバックアップを行うたびにHome Assistantを停止する理由にはなりません。
停止後にパスの誤りを発見してダウンタイムを延ばさないでください。事前に保存先を検証し、停止時間は最終的な正式コピーだけに使用してください。
データベース対応のライブバックアップなら安全に実行できる
SQLite自体がオンラインバックアップの仕組みに対応しており、ソースデータベースを稼働させたまま、一貫性のある独立したコピーを作成できます。これは、汎用的な同期ツールでデータベースファイルとWALを個別にコピーする方法とは大きく異なります。
最近のホームラボ向けバックアップ手順では、SQLiteのページ対応 .backup コマンドにより、単純なライブrsyncで発生する不整合なメインファイルとWALの組み合わせを回避できる理由が説明されています。
カスタムのライブバックアップを構築する場合は、まずデータベース対応のコピーを別途準備し、互換性のある方式で残りの設定をコピーして、復元テストで全体の結果を検証してください。データベースの整合性だけでは、欠落したカスタムファイル、シークレット、実行時定義までは保持できません。
データベース対応のライブバックアップと汎用スナップショットを分けて考える
データベース対応のライブバックアップ方式やHome Assistant独自のバックアップインターフェースに、「rsyncでは停止する」というルールをそのまま適用しないでください。整合性の保証は、ツール名に「スナップショット」や「バックアップ」という語が含まれているかではなく、使用するバックアップ手段によって決まります。
Containerインストールでは、実行環境の定義もHome Assistantの外部に保持してください。Composeファイル、ホスト側の設定パス、デバイスマッピング、ネットワークモード、外部サービスの依存関係などが含まれます。バックアップアーカイブだけでは、文書化されていないコンテナレイアウトまで自動的に再現することはできません。
ZimaSpaceのNASとは別にHome Assistant独自の復旧計画を用意する例は、対象範囲の境界を明確にしています。データ保護では、アプリケーションの状態だけでなく、それを実行するために必要な環境も対象にする必要があります。
バックアップは復元結果で評価する
最近のバックアップを分離された対象へ復元し、ユーザー、統合、ダッシュボード、自動化、ヘルパー、デバイスレジストリ、必要に応じて履歴、さらに代表的なローカル制御経路を1つ確認してください。その復元先を一度再起動してから、バックアップが検証済みだと判断してください。
毎晩正常に完了していても、動作するシステムを復元できないバックアップ方式は、短時間のメンテナンス停止と、テスト済みの復旧結果を提供する方式よりも運用上劣ります。必要なダウンタイムの条件を満たし、繰り返し復元可能な状態を作れる、最も簡単な方法を選んでください。
FAQ
組み込みのバックアップ機能を使用する前にHome Assistantを停止する必要がありますか?
いいえ。組み込みのバックアップワークフローを設計どおりに使用してください。停止を推奨するのは、Home Assistantの稼働中のデータベースや状態と連携しない、通常のファイルレベルのコピーを作成する場合です。
ファイルシステムまたはVMのスナップショットは、自動的に安全なライブバックアップになりますか?
自動的に安全になるわけではありません。スナップショットの有用性は、取得されたデータの整合性と、その後に行う復元テストによって決まります。スナップショットの取得中もアプリケーションとデータベースが書き込みを続ける場合は、そのスナップショット方式が、復旧計画で必要とする整合性の保証を提供することを確認してください。
サポートとヒント
もっと読む

アイドル時間中にHome Assistantサーバーが高温になったり、うるさくなったりするのはなぜですか?
冷却やCPU制限を変更する前に、Recorder、バックアップ、連携機能、同一ホスト上のジョブと、Home Assistantのファン回転数や温度の急上昇との相関を確認してください。

Home Assistantは修理するより再構築すべきなのはいつですか?
まず、Home Assistantで最小限の故障レイヤーを修復し、次に既知の正常な状態へ復元します。永続設定を信頼できない場合にのみ再構築してください。

Home Assistantがバックグラウンドジョブ用に確保すべき空き容量はどのくらいですか?
Home Assistantの空き容量は、Recorderデータベース、バックアップの増加、メンテナンス時のピーク、復旧作業を考慮して見積もり、画一的な割合では決めないでください。

