正常なバックアップから Immich データベースを復元する方法

エヴァ・ウォン

IceWhale author

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

How to Recover an Immich Database From a Known-Good Backup - Zima Store Online

既知の正常な Immich データベースバックアップも、管理された状態に復元し、復旧したデータベースがサーバーから実際に認識できるメディアを参照していることを確認して初めて役に立ちます。

復旧は、単一のインポートコマンドではなく、一連の手順として扱ってください。まず障害のあるインスタンスを保存し、Immich のバージョンとバックアップのタイムスタンプを特定します。次に、互換性のあるクリーンなデータベースの復元先を起動し、アプリケーションが空のスキーマに先に書き込まない状態で復元します。その後、アカウント、タイムラインデータ、メディアパス、新規書き込みを検証します。どの手順でも不明点がある場合は、最後に復元可能なコピーを置き換える前に停止してください。

復元前に障害のある状態を凍結する

復旧作業を始める前に、影響を受けた Immich インスタンスへの新しいアップロードとバックグラウンド書き込みを停止します。現在の Compose ファイル、環境変数、マウントパス、イメージのバージョン、最近のログ、そしてストレージに余裕があれば破損したデータベースの状態を保存してください。障害のあるデータベースにも原因を解明する手がかりが残っている可能性があり、上書きするとその証拠が失われます。

信頼するバックアップが正確にどれなのかを特定します。タイムスタンプ、作成方法、ファイルサイズ、テスト復元の実施有無を記録してください。データベースが作成した SQL ダンプは、稼働中の PostgreSQL データディレクトリをそのままコピーしたものとは異なる復旧資産です。両者を同じものとして扱わないでください。

可能であれば、復旧先を別のディレクトリまたは分離したスタックに作成します。この段階の終了条件は明確です。元の障害状態が保存され、選択したバックアップが読み取り専用になっており、復元によって再接続する対象のデプロイバージョンとストレージパスが把握できていることです。

バックアップが実際に復元可能か確認する

再適用する前にバックアップを調べます。圧縮された SQL ダンプは正常に解凍でき、失敗した処理によって作られた空のアーカイブではなく、認識可能な PostgreSQL ダンプの内容を含んでいる必要があります。チェックサムやリポジトリの検証結果がある場合は、復旧途中で破損に気付くのではなく、ここで照合してください。

PostgreSQL ダンプは、稼働中のデータベースディレクトリを手軽にコピーしたものより安全な復旧資産です。データベースを意識したツールで作成され、クリーンな復元先に再適用できるためです。データベースダンプによるバックアップ方式では、データベースとメディアのコピーも分離されるため、復旧前にそれぞれを検証しやすくなります。

また、バックアップ時点に対応するメディアと設定がまだ存在することも確認してください。データベースだけを復元すると、ユーザー、アルバム、メタデータ、ファイル参照は戻せても、参照先のライブラリパスが失われていれば、すべてのアセットが壊れたままになる可能性があります。ダンプとメディア・設定一式が既知の復旧時点に対応している場合にのみ進めてください。

互換性のあるクリーンなデータベースの復元先を先に起動する

復元方法は、バックアップを作成したバージョンに合わせてください。現在の Immich リリースでは、Administration > Maintenance と新規インストール時のオンボーディングフローからデータベースを復元できますが、古いバックアップではバージョン固有の手動手順が必要になる場合があります。復元ワークフローは v2.5.0 で変更されました。

新しい復旧先では、データベースの復元準備が整う前に、Immich が空のスキーマに対して通常のマイグレーションを実行しないようにしてください。デプロイ方法によってアプリケーションと PostgreSQL を同時に起動する場合は、バージョンに適した復元機能を使用し、インポート前にサーバーが競合する状態を作成しないようにします。

データベースが自動的に正常な状態にならない場合は、まずその問題を解決して停止してください。再起動を繰り返している、ディスク容量が不足している、または互換性のないストレージ構成を使用している復元先に、同じバックアップを何度も再適用しないでください。クリーンで安定した復元先は前提条件であり、脇道のトラブルシューティングではありません。

-15% OFF

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

Single board computer zimaboard2

ダンプは一度だけ復元し、最初のエラーで停止する

選択したダンプを準備済みのデータベースに復元し、出力全体を保存します。ダンプ形式に適したデータベースツールとフラグを使用し、エラーが発生した場合に復元が明確に失敗するようにしてください。部分的にインポートされたスキーマが起動してしまう状態を残してはいけません。

使用可能な移行一式には、アセット、PostgreSQL の状態、それらを再接続する設定が必要です。完全な Immich バックアップ一式には、アップロード済みアセット、サポート対象のデータベースバックアップ、デプロイ設定が含まれ、復元テストによって一式が機能することを確認します。復元先を1つの復旧時点に合わせられるよう、これらの要素をまとめて管理してください。

インポートが正常に完了したら、Immich アプリケーションを起動し、初回起動を注意深く監視します。既存のアカウントを受け入れず、新しい最初の管理者を作成するよう画面に求められた場合は、停止してください。これは、復元したデータベースを Immich が使用していないことを強く示しています。その空の状態に写真を再アップロードし始めないでください。

データベースの状態、メディアパス、新規書き込みを検証する

既存のアカウントでログインし、古い日付から最近の日付までタイムラインをいくつか確認します。存在していたことが分かっているオリジナル画像を複数開き、アルバムやお気に入りを確認し、アプリケーションがデータベースの行を表示するだけでなく、基盤となるファイルを解決できることを確認してください。

復元時には、データベースの状態、アプリケーションファイル、設定、アップロードデータが一致している必要があります。PostgreSQL が起動するかどうかだけでなく、受け入れ基準として整合性のあるデータベースコンテナのバックアップを使用してください。

最後に、使い捨ての写真を1枚アップロードし、通常の処理が完了するまで待ちます。Immich の再起動とホストの再起動後も保持されることを確認してから、アプリケーションを通じて削除してください。アカウント、既存のアセット、新規書き込みがすべて正常に動作したら、バージョンアップの前に復旧状態の新しいバックアップを作成します。正常でない場合は、被害を拡大させるのではなく、保存しておいた障害の証拠または以前の既知の正常なバックアップに戻してください。