Immichのバックアップで不整合な状態が取得されるのを防ぐ方法

エヴァ・ウォン

IceWhale author

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

How to Prevent Immich Backups From Capturing Inconsistent State - Zima Store Online

一貫性のないImmichバックアップを防ぐには、データベースとメディアを1つの復旧単位として扱い、取得順序と書き込み処理を意図的に管理します。

バックアップ対象のすべてのファイルが含まれていても、取得されていないアセットをデータベースが参照していたり、メディアのコピーがカタログと異なる時点のものだったりすると、復元に失敗する可能性があります。まず一貫性の境界を定義し、停止方式または調整済みの稼働中方式を選択して、結果を分離環境で検証してください。

バックアップをスケジュールする前に復旧単位を定義する

サービスを再作成するために必要なPostgreSQLデータベース、アップロード済みメディア、プロフィールデータ、デプロイ設定、環境変数、シークレット、カスタムストレージパスを一覧化します。生成されたサムネイル、エンコード済み動画、モデルファイルについては、復旧ポリシーで保護するのか再生成するのかに応じて個別に分類します。

ZimaSpaceによるImmichの稼働中バックアップと停止バックアップの比較では、基本的な一貫性の選択について説明しています。この予防ワークフローでは、さらに一歩進めます。どちらの方法を選ぶ場合でも、どのデータベースがどのメディアコピーに対応するのかを推測せずに復元できる、文書化された時点を作成する必要があります。

バックアップ範囲の横に復元順序を記載します。計画が「写真を復元する」とだけ示し、写真をユーザーやアルバムに再接続するためのデータベースダンプ、設定、認証情報、ストレージマッピングを指定していないなら、最初のスケジュール実行前からバックアップ定義は不完全です。

最も単純な境界で問題ない場合は停止状態で取得する

短時間のメンテナンス時間を許容できる小規模な家庭環境では、アップロードを一時停止し、ライブラリの状態を書き込むアプリケーションサービスを停止します。データベースをバックアップし、メディアと設定を取得した後、スナップショットまたはコピーの時刻と完了結果が明確になってから再起動します。

アプリケーションを停止したからといって、誤ったパスが自動的に正しくなるわけではありません。データベースのエクスポートが成功したこと、意図したメディアのルートが含まれていること、バックアップ先が復旧対象の稼働中データから独立していることを確認します。後の復元で正確な世代を特定できるよう、開始時刻と終了時刻を記録してください。

取得中にアプリケーションの書き込みが発生せず、テスト復元で想定したユーザー、アセット数、アルバム、サンプルとして選んだオリジナルファイルが戻れば、この方法は合格です。停止時間が家庭で許容できる時間を常に超える場合は、ファイルコピーの途中でアップロードを密かに再開させるのではなく、調整済みの稼働中方式に移行します。

稼働中バックアップでは、既知の順序でデータベースとファイルを取得する

Immichを利用可能な状態に保つ必要がある場合は、稼働中のPostgreSQLデータディレクトリを通常のファイルとしてコピーするのではなく、データベースネイティブの一貫性のあるダンプを作成します。その後、文書化した順序でメディアツリーを取得またはスナップショットし、バックアップ時間帯に発生したアップロードを追跡します。

実践的なImmichデータベースのバックアップ手順では、データベースを認識した方式を紹介しています。コマンドやコンテナ名はデプロイ方法によって異なるため、応用できる原則は、データベースファイルの稼働中再帰コピーを信用するのではなく、PostgreSQLに一貫性のあるバックアップを作成させることです。

復元したデータベースが、バックアップに一度も含まれていないメディアを指す状態を残さない順序を優先します。ファイルシステムのコピーに、データベースがまだ認識していない追加ファイルが含まれていても、参照先のオリジナルが存在しないデータベースレコードより安全に調整できます。境界をまたいだアップロードはすべて記録してください。

Featured

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

ZimaCube2

アトミック性を前提にせず、ファイルシステムのスナップショットとデータベースフックを連携させる

ファイルシステムのスナップショットはボリュームを短時間で取得できるため有用ですが、それだけで別々に変化する2つのシステムがトランザクション的に一貫するわけではありません。データベースとメディアが異なるデータセットやデバイスにある場合は、スナップショット前後のフックを定義し、バックアップログでタイミングを確認できるようにします。

バックアップソフトウェアとBtrfsのスナップショットフックを組み合わせた2026年の例は、スナップショットのオーケストレーションに明示的なアプリケーションまたはデータベースの境界が必要な理由を示しています。この考え方を取得の調整に活用し、ファイルシステムのコマンドを別のレイアウトにそのままコピーして使わないでください。

スナップショットツールがデータベースとメディアの時点を調整できない場合は、アトミックな復旧を主張するのではなく、論理データベースダンプとメディアバックアップに切り替えます。高速な取得でも一貫したアプリケーション状態を復元できることが復元訓練で証明されている場合に限り、複雑さを受け入れてください。

バックアップスケジュールに復元テストを組み込む

バックアップジョブが成功したことは、取得が完了した証拠にすぎません。定期的に最近の世代を1つ選び、分離したホスト名の下で復元し、想定したストレージを接続して、ユーザー、代表的なオリジナルファイル、アルバム、権限、検索動作、復元インスタンスから新たに作成したデータベースバックアップを検証します。

PostgreSQLのバックアップと復元計画に関する復旧概要では、ダンプ作成を終点と見なすのではなく、復元の検証と復旧目標を重視しています。同じ考え方を、Immich全体の復旧単位にも適用してください。

データベースの復元には成功したのにファイルが欠落している場合、ユーザーや関連付けなしでメディアだけ開ける場合、または失敗したホストにのみ保存されたシークレットに復旧が依存している場合は、バックアップポリシーを不合格とします。バックアップ頻度を増やす前に、範囲、順序、保持期間、独立性を修正してください。一貫性のないコピーを増やしても、信頼できる復旧ポイントにはなりません。