古いサーバーを廃止する前に Immich の復元を検証する方法

エヴァ・ウォン

IceWhale author

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

How to Verify an Immich Restore Before Retiring the Old Server - Zima Store Online

新しいダッシュボードが読み込まれ、写真が表示されるからといって、古いImmichサーバーを廃止しないでください。ユーザー、アルバム、人物、検索、サンプルしたオリジナル、新しいアップロード、バックグラウンドジョブ、再起動、そして新しいバックアップについて、復元したシステムが問題ないことを確認してから廃止します。その間、古いホストはロールバック先として利用できる状態にしておきます。

検証中は、2つのインスタンスが異なる状態でアップロードを受け付けないよう、古いサーバーの電源を切り、変更せずに保管してください。まず復元したホストに管理されたテスト用アドレスを割り当て、古いシステムのベースラインを記録し、タイムラインが完全に見えるという印象だけに頼らず、同じ家庭内のワークフローを比較します。

復元のベースラインを確立する間、古いサーバーをそのまま維持する

切り替え前に、ユーザー数、アセット数、代表的なアルバムをいくつか、名前付きの人物、お気に入り、共有項目、外部ライブラリのパス、ユーザーや日付の異なるオリジナルのサンプルを複数記録します。また、古いImmichとPostgreSQLのバージョン、および復元に使用したバックアップアーティファクトも記録します。フォルダーやストレージの整合性チェックは有効な判定基準ですが、関係レベルの検証の代わりにはなりません。

検索可能なフォトライブラリを復元する方法におけるZimaSpaceの復旧モデルでは、オリジナル、カタログ／データベースの状態、パスを定義する設定を1つの復旧単位として扱います。画像ファイルだけでは、アルバムへの所属、所有者、人物、検索の関係が維持されたことを証明できないため、これは適切なベースラインです。

古いディスクを消去したり、古いIPアドレスを恒久的に再利用したり、最後に正常だったバックアップをまだ削除したりしないでください。検証の目標は、問題があった場合に元に戻せることです。重要な関係が1つでも欠けていれば、その原因がバックアップ、復元方法、パスのマッピング、新しいランタイムのどれにあるのかを判断するために、古い状態が必要になります。

写真の表示だけでなく、関係を検証する

想定されるユーザーのうち複数のユーザーとしてログインし、それぞれのアカウントで正しいアセットと共有項目が表示されることを確認します。既知のアルバム、名前付きの人物、お気に入り、思い出、その他ファイルだけから再構築するのが難しい家庭内固有の関係を開きます。記録した古いサーバーのベースラインと照らし合わせ、少数の項目を比較します。

PostgreSQLの復元後にアルバムが欠落したImmichの移行に関する議論は、これが重要な理由を示しています。写真が残っていてもアルバムの状態が欠落する可能性があり、その後にデータベースを再ダンプすると結果が変わりました。ログインに成功したことやタイムラインが表示されることは、完全な復元テストではないという事例証拠として扱ってください。

メタデータ、および有効にしているビジュアル機能や人物機能を使って、既知のアセットをいくつか検索します。オリジナルは存在するのに関係や検索結果が欠落している場合、その状態が復元されるべきだったのか、それとも意図的に再生成されているのかを確認します。この区別が解決するまで、古いサーバーを廃止しないでください。

読み取り、書き込み、依存関係、再起動の経路を検証する

復元したストレージから古い写真や動画を直接開き、その後、モバイルまたはWebクライアントから使い捨ての新しいアセットをアップロードします。オリジナルが意図したパスに書き込まれ、正しいユーザーに表示され、バックグラウンドジョブが進行することを確認します。外部ライブラリやリモートアクセスのテストは、ローカルの読み書き経路が安定してから行います。

復元テストでは、バイト列のコピー後にアプリケーションを検証する必要があります。現在の災害復旧テストガイドでは、完了したバックアップや復元ジョブだけで終わらせず、データベース、権限、ネットワーク接続、サービスを含むアプリケーションレベルの検証を推奨しています。Immichスタックを2回再起動し、新しいホストを1回再起動します。各サイクルの後、同じマウント、ユーザー、サンプルアセット、データベース、プロキシまたはローカルエンドポイント、ジョブの動作が復元されることを確認します。最初のホスト再起動までしか動作しないサービスは、移行に合格していません。

-15% OFF

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

Single board computer zimaboard2

ロールバック期間を終了する前に、新しいバックアップを作成する

データベースと整合した新しいバックアップを作成し、復旧設計で必要とされるメディアと設定の範囲を保護します。少なくとも小規模な検証対象を復元するか、切り替え前と同じ手順でバックアップを検査します。自分で復元可能なバックアップを作成できない復元サーバーを、本番環境の唯一のコピーにしてはいけません。

新しいホストを、通常のスマートフォンからのアップロード、閲覧、検索、バックグラウンド処理、スケジュールされたバックアップ、少なくとも1回の夜間サイクルを含む、定義済みの観察期間で運用します。状態が分岐しないよう古いホストの電源は切ったままにしますが、新しいシステムが説明のつかない差異なくこれらのイベントを乗り切るまで、古いホストは変更せずに保持します。

移行を進めるためには、重要な関係の一致、オリジナルの読み取り、新しい書き込みの成功、安定した再起動、新しく検証済みのバックアップが必要です。

ユーザーが消える、件数が大きく食い違う、パスエラーが再発する、またはデータベースが整合性の問題を報告する場合は、新しいインスタンスの電源を切り、調査前に両方の状態を保存します。その後で初めて、古いサーバーを消去または再利用してください。