Immichのインストールは、修復ではなく再構築すべきタイミングとは？

エヴァ・ウォン

IceWhale author

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

When Should You Rebuild Rather Than Repair an Immich Installation? - Zima Store Online

障害が局所的で、永続データが明らかに無傷である場合はImmichを修復します。構成の乖離が広範囲に及んでいても、検証済みのデータベース、メディアライブラリ、デプロイ定義、ロールバック用コピーがあり、それらを使って安全にサービスを再構築できる場合は、ランタイムを再構築します。

再構築は、すべてを削除することと同じではありません。コンテナとネットワークは使い捨てにできますが、データベースとオリジナルファイルはライブラリの記録です。まず、完全性、影響範囲、再現可能性を分類してください。データベースが破損している可能性がある場合や、写真のコピーが1つしかない場合は、それを保全して停止します。その証拠を残したままクリーンな状態でやり直すと、診断可能なインシデントが恒久的なデータ損失につながる可能性があります。

障害が局所的で可逆的な場合は修復する

1つのマウント、権限、環境変数、依存関係、ジョブ、または固定済みイメージで障害を説明でき、既知の変更前にはシステムが正常に動作していた場合は、修復を優先します。ログを取得してバックアップを作成し、その1つの層だけを変更して、トリガーを再実行します。

成功とは、欠落したアセット、データベースエラー、新たな起動警告を発生させずに、失敗していた機能が復旧することです。再作成後も同じ障害が再発する場合、原因はデプロイ定義または永続状態にある可能性があるため、コンテナを繰り返し置き換えることは、もはや根拠に基づく修復とはいえません。

データベース破損に関する議論は、データベースが疑わしい層になったとき、復旧方法の選択がいかに急速に高リスク化するかを示しています。検証されていない破壊的なコマンドではなく、修復前に保全する教訓を活用してください。

構成の乖離が制御不能な場合はランタイムを再構築する

イメージのバージョン、ネットワーク、環境変数、マウント、手動で変更されたコンテナを再現できなくなっていても、検証済みの永続コンポーネントが無傷で残っている場合は、クリーンなランタイムを再構築します。削除するのではなく、バージョンを固定し、ポートを分離した状態で旧インスタンスの隣に構築してください。

ホストが侵害された後や、サポート対象外のインストールに不明な変更が蓄積した後も、再構築が適しています。信頼できるデプロイ入力を復元することで、新たな監査境界を作成できるためです。公開された認証情報をローテーションし、クリーンな対象に接続する前にバックアップを確認してください。

ZimaSpaceによるセルフホスト型アプリのデプロイの概要は、サービススタック全体を理解するうえで役立ちます。ただし、Immichではデータベースとメディアの対応関係を個別に検証する必要があります。

不確かな永続データを上書きして再構築しない

データベースとアップロードライブラリの同期が崩れている可能性がある場合、唯一のバックアップをまだテストしていない場合、または正本となるコピーが不明な場合は停止します。データベースの復旧やメディアの整合化を試みる前に、候補となるすべてのデータをスナップショットまたはクローンし、タイムスタンプを記録してください。

Unraidの復旧スレッドは、バックアップのコンポーネントとバージョンが一致しない状態でImmichを復元することの運用上の難しさを示しています。その復元境界に関する議論は、本番パスを上書きするのではなく、分離した環境でテストすることを支持しています。

オリジナルファイルは無傷でもデータベースを復旧できない場合は、両方を保全し、新しいライブラリへのインポートを検討する前に、その結果を記録してください。これは通常の修復ではなく、データ再構築の判断です。アルバム、共有状態、顔データ、お気に入り、過去のメタデータが失われる可能性があります。

Featured

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

ZimaCube2

クリーンな対象で永続データを検証する

コピーした永続データをクリーンな対象に復元または接続し、ユーザー、タイムラインの件数、サンプル抽出したオリジナルファイル、アルバム、検索、顔データ、外部ライブラリ、新しいアップロード、ジョブ、新しいデータベースバックアップをテストします。結果を保全した元データの証拠と比較してください。

複数の日付、ユーザー、メディア種別にわたって、データベースのアセット数とサンプルファイルを比較します。外部ライブラリのパス、派生ジョブ、本番アドレスを割り当てる前の新しいデータベースダンプを確認してください。ログイン画面が表示されるだけでは、データの完全性は証明できません。

コンテナとホストを2回再起動します。成功の条件は、マウントが安定していること、構成を再現できること、マイグレーションループがないこと、元のワークロードが動作することです。クリーンな対象でも同じデータベースエラーまたはファイルエラーが再現される場合、原因はランタイムの乖離ではなく、専門家によるデータ復旧に進むほうが安全です。

ロールバック境界を設けて切り替える

分離環境でのチェックに合格した後にのみ本番アドレスを移行し、旧システムは合意した観察期間中、電源を切った状態で復旧可能にしておきます。両方のインスタンスが同時にアップロードを受け付けたり、同じ自動化処理を提供したりしないようにしてください。

切り替え後、通常どおり家族によるアップロード、閲覧、検索、共有、バックアップのワークフローを実行します。次回の再起動後も件数とオリジナルファイルが維持されれば成功です。不一致があれば、どちらのデータセットも上書きせず、保全した対象へトラフィックを戻します。

クリーンな対象でも同じデータベースエラーまたはファイルエラーが再現される場合は、修復または専門家による復旧に戻ります。原因はランタイムではありません。件数またはオリジナルファイルが異なる場合は切り替えをロールバックします。バージョン、チェックサム、バックアップのタイムスタンプ、最初のエラー、コピーした状態と新たに作成した状態の正確な境界を添えてエスカレーションしてください。