高速なImmichリカバリを可能にするハードウェアとソフトウェアの要因とは？

エヴァ・ウォン

IceWhale author

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

What Hardware and Software Factors Enable Fast Immich Recovery?

Immichの迅速な復旧は、表面的なCPU速度よりも、完全な状態、互換性のあるサービス、読み取り可能なバックアップ、そしてリハーサル済みの復元手順に左右されます。

サーバーがすぐに起動しても、データベースが欠落していたり、メディアのパスが異なっていたり、派生ファイルの再構築が必要だったりすると、使用できない状態が続くことがあります。復旧時間の終点は、コンテナが初めて正常状態を報告した時点ではなく、代表的な家庭内ワークフローが再び機能する時点とすべきです。

復旧は適切な永続状態から始まる

Immichの永続データには、元のメディアと、ユーザー、アセット、アルバム、関連付け、処理状態を記述するデータベースレコードが含まれます。ファイルだけを復元すると写真は保持できますが、同じアプリケーションライブラリを再構築できるとは限りません。データベースだけを復元すると、パスが対応するメディアを指さないレコードが生成される可能性があります。

ZimaSpaceのImmichバックアップガイドでは、包括的なバックアップにはアップロード済みの写真と動画に加え、Immichのデータベースが必要だと説明しています。この組み合わせは復旧時間計画の基盤です。必要な要素のどちらか一方が欠けていれば、その後のハードウェアや自動化の改善はすべて意味を持たないからです。

永続データの保存場所をすべて列挙し、それぞれを復元先に対応付けます。外部管理の元データ、プロフィールデータ、マウントとIDの再現に必要なシークレットや設定も含めます。派生ファイルは別に分類してください。再生成できる場合もありますが、省略すればバックアップ容量を減らせる一方、復元後の処理時間が長くなります。

ソフトウェアの互換性が状態を起動できるかどうかを決める

バックアップは、特定のアプリケーション、データベースエンジン、拡張機能、コンテナ設定、パス構成によって解釈されます。互換性のないスタックにデータを復元すると、ハードウェアの速度が問題になる前に失敗する可能性があります。そのため復旧キットには、Compose定義、固定されたバージョンまたは文書化されたアップグレード手順、シークレット、ストレージマッピングが必要です。

メジャーバージョン変更後にImmichのデプロイが壊れたというコミュニティ報告では、データベースのベクトル拡張機能の不一致が原因とされています。1件の報告ですべてのアップグレードを定義できるわけではありませんが、「最新のコンテナに古いデータを組み合わせる」だけでは、完全な復旧手順にならないことを示しています。

最後に正常動作していたソフトウェア構成と、復旧時の目標構成を保存します。分離されたテスト環境では、まず互換性のあるバージョンで復元してライブラリを確認し、その後に必要な移行を実行します。災害復旧と未検証のアップグレードを同時に行うと、障害原因の特定が難しくなり、クリティカルパスも長くなります。

復元時間を決めるのは読み取りスループットと小規模I/Oのレイテンシ

復旧では、データの移動と検証、データベースレコードの復元、派生ファイルの再生成が行われる場合があります。大容量の元データではシーケンシャルスループットが重要ですが、データベースの復元や数百万個に及ぶ小さなファイルの処理では、レイテンシとメタデータ操作が大きく影響することがあります。リモートバックアップでは、ネットワーク帯域、再送、認証もクリティカルパスに加わります。

実践的なImmichバックアップ記事では、データベースのダンプとメディアディレクトリを分け、外部のコピー先を使用しています。この構成により、2種類の異なる復元ワークロードが明らかになります。そのため、大容量ファイルのコピーだけを測定すると、データベースのリプレイや小さなファイルの復元が完了するまでの時間を過大評価する可能性があります。

取得、チェックサム、データベース復元、メディア配置、起動、派生ファイルの再生成を、それぞれ個別に計測します。最も時間のかかるフェーズでは、CPU、デバイスレイテンシ、ネットワークスループットを監視します。すべての復旧手順が高速化すると仮定してプロセッサを交換するのではなく、測定したクリティカルフェーズを短縮するリソースを強化してください。

-15% OFF

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

Single board computer zimaboard2

時間を計った復元訓練で、コンポーネントを復旧に変える

空のストレージを用意し、本番環境の書き込みパスにはアクセスできない分離されたターゲットを作成します。バックアップの取得を開始する前に時計をスタートします。文書化された依存関係の順序に従って、データベースと必要なファイルを復元します。その後、通常のクライアントからのログイン、タイムライン表示、元データのダウンロード、アルバムへの所属、既知の検索結果を確認します。

独立したImmichバックアップガイドでは、必須の元データとデータベースのバックアップを、再生成可能なサムネイルやエンコード済み動画と区別しています。この区別により、訓練では2つの目標を測定できます。まず、かけがえのないコンテンツと関連付けを保護するまでの時間を測定し、次に利便性の高い機能と派生ファイルが完全に利用可能になるまでの追加時間を測定します。

あらかじめ定義したワークフローに合格するまで訓練を終了せず、合計時間とすべての手動判断を記録します。コピー自体が速くても、その後にパスの修正に数時間かかるなら、復旧は遅いということです。バージョン、ストレージ構成、認証、バックアップツールを変更した後は再度実施してください。変更のたびに、それまでの結果が無効になる可能性があるためです。