Home Assistantの復旧時間を決定するハードウェアとソフトウェアの要因は？

高速なHome Assistantの復旧は、高速な起動と同じではありません。復旧時間は元のサービスが利用できなくなった時点から始まり、必要な家庭機能が復元され、検証されるまで続きます。バックアップのダウンロード、復号、アプリの再インストール、データベースの移行、ストレージの再接続、無線機器の復元、重要な自動化の検証などが、障害ごとに復旧時間の大部分を占める可能性があります。

したがって有用な指標は、明確に定義した対象範囲に基づく復旧時間目標です。破損した設定ファイルを1つ復元する場合と、故障したサーバーを新しいハードウェア上で再構築する場合では、目標が異なります。

バックアップサイズは転送、展開、再インストールの時間を左右する

サイズの大きなバックアップは、移動、展開、検証、復元により長い時間がかかります。Home Assistantの設定自体が小規模でも、メディアや共有フォルダーによってアーカイブサイズが大きくなることがあります。

Home Assistantの現在のバックアップガイダンスでは、大規模なインストールでは復元に約45分かかる場合があり、移行の準備時には不要なバックアップ範囲を減らすことが推奨されています。この時間は保証ではありませんが、復旧時間がインストールの規模と内容に大きく左右されることを示しています。

Home Assistantとともに戻す必要があるものに、復旧用アーカイブの対象を絞りましょう。大容量で置き換え可能なメディアは、含めることで制御システムの復元が毎回遅くなる場合、別の保護方法を使用できます。

ストレージとCPUは、状態をどれだけ速く再構築できるかを左右する

復元作業はネットワーク転送だけではありません。アーカイブの復号と展開、ファイルの書き込み、アプリやコンテナの再インストール、データベースの起動や移行も必要になる場合があります。

高速なSSDストレージは、低速または故障しかけたフラッシュストレージと比べて、メタデータを多用する復元作業を短縮できます。暗号化、展開、データベース移行、多数のアプリケーションの再構築が発生する場合は、CPUがより重要になります。最も時間のかかる段階は、バックアップとプラットフォームによって異なり、普遍的なハードウェアの優劣で決まるものではありません。

復旧時間が重要なら、実際の対象ハードウェア上で復元を測定してください。高速なワークステーションでのみ検証したバックアップからは、低消費電力の本番ホストでの性能についてほとんど判断できません。

永続的なランタイム状態があれば、コンテナの復旧を大幅に高速化できる

コンテナ環境では、イメージは置き換え可能であり、永続的な設定は別途マウントされます。ホストのファイルシステムと/configが存続している場合、古いアプリケーションバックアップから復元するよりも、ランタイムを再作成する方がはるかに高速になることがあります。

Dockerのストレージモデルでは、一時的なコンテナレイヤーと、コンテナのライフサイクルから独立して永続化されるボリュームおよびバインドマウントが分離されています。信頼できる状態を使い捨てのイメージの外部に保持する復旧設計により、多くのイメージ障害を完全なデータ復旧ではなく、ランタイムの置き換えとして処理できます。

ただし、永続パスが同じ故障ディスク上にある場合、記録されていない場合、または正しい権限で再マウントできない場合、この利点は失われます。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

外部依存関係が直列的な復旧手順を増やす

MQTTブローカー、外部データベース、リバースプロキシ、DNS、NAS共有、ZigbeeやZ-Waveのサービス、ローカルAIコンポーネントなどは、Home Assistantのバックアップ対象外であったり、独立したタイムラインで起動したりする可能性があります。

ZimaSpaceの復旧可能なローカルスマートホームアーキテクチャに関するガイドが関連するのは、重要な自動化に必要な依存関係が再び利用可能になって初めて、制御システムの復旧が完了するためです。

照明、ロック、空調、アラーム、センサーに必要なサービスを記録しておきましょう。オプションの分析機能は後から復旧できます。重要な制御経路が、サーバー上のすべての不要なアプリの復旧を待つべきではありません。

リカバリーモードは修復可能な状態に到達するまでの時間を短縮する

すべての障害で完全な復元が必要になるわけではありません。設定によって通常の起動が妨げられている場合、Home Assistantは最小限のリカバリー環境にフォールバックできます。この環境では、ユーザー統合が読み込まれていない状態でUIとログを利用できます。

Home Assistantの現在のドキュメントでは、リカバリーモードを、設定、エンティティ、履歴を削除せずに起動障害を修復するための、最小限の動作システムと説明しています。これにより、復旧目標は「すべてを再構築する」ことから「安全な修復環境にすばやく到達する」ことへ変わります。

そのため、優れた復旧計画には複数の経路があります。範囲が限定された設定障害にはその場での修復、永続データが健全な場合にはランタイムの再作成、信頼できる状態が破損または失われた場合にはバックアップからの復元を行います。

検証時間も復旧時間に含まれる

• 想定されるユーザー、ダッシュボード、統合、エンティティが存在することを確認する。
• 重要なローカル自動化を1つ、最初から最後まで検証する。
• Recorderが新しい履歴を書き込んでいることを確認する。
• 使用している場合は、ネットワークストレージと外部データベースを再接続する。
• 無線接続されたデバイスと、移行したコーディネーターを検証する。
• もう一度再起動し、復旧した状態が安定して維持されることを確認する。

これらの確認を通過していない最速の復元は、単なる起動時間にすぎません。復旧時間が終了するのは、家庭に必要な機能が利用可能で、かつ再現性をもって動作すると確認できた時点です。