Home Assistantのストレージ構成では、1台のディスク、ホスト、マウント、認証情報、または文書化されていないパスに障害が発生すると、稼働状態と利用可能な復元コピーがすべて失われるという、復旧上のリスクが生じます。
この警告は、障害が発生する前から現れることがよくあります。バックアップがVMの隣に保存されている、ネットワーク共有が別のパスで再接続される、データベースは外部にあるものの復元順序が文書化されていない、またはアーカイブが自分自身を再帰的に含んでいる、といったケースです。永続的な役割ごとに、その役割と障害ドメインをすべて把握し、何かを移動または削除する前に、読み取り専用の復旧レビューを実施してください。
データの役割と実際の障害ドメインを把握する
システムディスク、設定、アクティブなデータベース、アドオンの状態、メディア、ログ、ローカルスナップショット、独立したバックアップ、暗号化キー、復元手順の文書を一覧にします。各役割について、物理ディスク、ストレージプール、ホスト、ネットワークパス、認証情報、管理者権限の要否を記録してください。
1つのプール上にある2つのディレクトリは別々のパスですが、ストレージ障害ドメインは同じです。VMのスナップショットとホストストレージは同時に障害を起こす可能性があります。NASのバックアップも、本番環境の復旧に必要な同じスイッチ、パスワードストア、または管理者アカウントに依存している場合があります。
重要な役割の所有者が不明な場合、またはすべての復旧コピーが本番のディスク、プール、ホスト、認証情報を共有している場合は、レイアウトレビューを不合格とします。空き容量が少なくなるまで待ってから、その依存関係を修正してはいけません。
容量とマウントに関する警告パターンを確認する
データベース、バックアップ、ログ、メディア、一時ファイルごとに、7日間の増加量を測定します。ジョブ開始時にバックアップ先がマウントされているか、マウントが見つからない場合にローカルのフォールバックディレクトリへ書き込まれるか、アーカイブパスに過去のアーカイブが含まれる可能性があるかを確認してください。
再帰的なバックアップパスは、復旧可能な履歴を増やすことなく、急速な容量増加を引き起こす可能性があります。再帰は、容量を購入する理由ではなく、設定上の障害として扱ってください。
増加が安定しており、原因と所有者が明確な場合は、保持期間および復元時間の目標と比較します。増加が段階的に跳ね上がる、マウントが消える、またはパスが重複する場合は、新しいバックアップジョブを停止し、保存先を修正する前に、既知の正常なコピーを1つ保全してください。
管理された損失シナリオで独立性をテストする
各主要な障害ドメインについて、そのドメインが利用できない場合でも、バックアップファイル、復号キー、クリーンな復元先、手順が利用可能かを確認します。正常を示すジョブステータスを確認するだけでなく、独立したコピーを読み取り、分離された環境で復元を実行して検証してください。
バックアップを本番ドライブの外部に保存することで別の障害ドメインを作れるのは、認証情報と復旧手順も本番環境の損失を免れる場合に限られます。
合格とするには、障害が発生した本番パスを使わずに到達できる復旧コピーが必要です。不合格の場合は、アクティブなレイアウトを変更する前に、バックアップとキーを移動または複製してください。そうしなければ、移行自体がリスクを高めます。
1つのリスクを修正し、復旧をリハーサルする
影響が最も大きい共有障害ドメインを最初に分離し、マウントとデータベースの復旧順序を文書化し、再帰を削除し、測定した増加量に基づいて保持期間を設定し、各バックアップ前に保存先の存在を監視します。新しいコピーが検証されるまで、以前のレイアウトを利用可能な状態に保ってください。
アクティブな状態をリモートマウントに置く前に、ネットワークストレージの信頼性の境界を確認してください。
本番環境に名前付きのプライマリ保存場所があり、すべての重要な役割に保護方法があり、独立した復元が復旧目標を満たした時点で停止します。ストレージI/Oエラー、繰り返すアンマウント、破損したアーカイブ、原因不明の所有者変更が発生した場合は、さらなる移行を行う前にエスカレーションしてください。
修正後もレイアウトを監視する
変更後は、空き容量、データ分類ごとの増加量、マウントの存在、バックアップの経過時間、アーカイブサイズ、復元テストの日付を追跡します。アラートでは、ディスク全体の使用率だけでなく、影響を受けた役割と保存先を特定できるようにしてください。
最初の2回のバックアップサイクルを文書化したレイアウトと比較し、ローカルのフォールバックディレクトリや再帰的なパスが再び現れていないことを確認します。保持処理が意図した古いコピーだけを削除し、独立した復旧コピーが引き続き利用可能であることを検証してください。
データベース、ストレージプール、マウントプロトコル、暗号化キー、またはバックアップ先が変更された場合は、復旧レビューを再度実施します。トポロジー変更前に合格したレイアウトは、以前のシステムに対する証拠であり、新しいシステムに対する証拠ではありません。
サポートとヒント
もっと読む

同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。

Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。

データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。

