モバイルOSがアプリを一時停止したり、転送失敗によって次の予定バッチが実行されなかったりすると、スマートフォンの写真バックアップはバックグラウンドで停止します。
セルフホスト型の写真アプリには、無制限のバックグラウンド実行が許可されているわけではありません。iOSとAndroidは、権限、バッテリー状態、ネットワーク状況、最近の使用状況、システムリソースの逼迫度に基づいて、アプリをいつ起動できるかを判断します。また、サポートされていないファイル、期限切れのログイン情報、到達できないサーバー、先にダウンロードが必要なクラウドのみのオリジナルファイルなどが原因で、バックアップ処理が停止することもあります。アプリがまったくスケジュールされていないのか、開始後に停止するのか、同じファイルで繰り返し失敗するのかを切り分けてください。
アプリを開いたままバックアップが動作するか確認する
スマートフォンを通常のWi-Fiに接続し、アプリを前面に表示したまま、保留中の件数、処理中のファイル名、転送速度、サーバーログを確認します。これにより、バックグラウンドスケジュールの問題を切り分ける前に、認証、サーバーへの到達性、ストレージ、アルバム選択が機能しているか確認できます。
Immichユーザーからは、バックアップ設定を有効にしていても、アプリを離れるとアップロードが直ちに停止するという報告があります。特徴的な症状は、アプリを前面に表示している間はアップロードできるのに、バックグラウンドでは進まないことです。
アプリを開いた状態でもバックアップに失敗する場合は、サーバーURL、証明書、ログイン情報、ストレージ、ファイル固有のエラーを引き続き確認してください。アプリを開いている間は正常に進む場合、OSのスケジュールや制限をテストする間は、これらの設定を変更しないでください。
バックグラウンド権限とシステムレベルの更新設定を確認する
iOSでは、「Appのバックグラウンド更新」、写真ライブラリへのアクセス、必要に応じてローカルネットワークへのアクセス、アプリが使用する場合は通知、そして「低電力モード」を確認します。Androidでは、バッテリー最適化、バックグラウンドデータ、バッテリー使用量の無制限設定、さらにメーカー独自のアプリスリープ対象リストがないか確認してください。
ImmichのiOSに関する報告では、システム設定ですでに「Appのバックグラウンド更新」が有効になっているにもかかわらず、アプリが繰り返し無効だと判定していました。この事例は、アプリとOSの状態が一致しない場合があることを示しています。
関連する権限は、管理されたリセットとして一度だけ切り替え、アプリを再度開いて設定が認識されていることを確認します。バッテリー保護をシステム全体で無効にしないでください。プラットフォーム上必要な場合に限り、写真バックアップアプリだけを対象外にします。
通常のモバイルスケジュールと停止したジョブを切り分ける
バックグラウンド処理は状況に応じて実行されるため、画面が消えた直後に開始するとは限りません。充電後、Wi-Fiへの再接続後、またはアプリを一時的に再度開いた後にバックアップが再開するかを記録してください。
Androidユーザーからは、バッテリー最適化や制限を無効にしていてもバックグラウンド同期に失敗するという報告があります。これは、権限があるだけではスケジュール実行が機能している証明にならないことを示しています。
通常のJPEGファイルを数枚入れた小さなテストアルバムを使用します。それらが最終的にバックグラウンドでアップロードされる場合、システムスケジューラーは機能しています。その場合、ライブラリ全体の失敗原因は、ファイルサイズ、ファイル形式、ネットワーク接続時間、またはキューの状態である可能性が高くなります。
1つの失敗ファイルがバッチを停止させていないか確認する
バックアップの詳細画面を開き、繰り返し失敗している最初のファイル名を特定します。拡張子、サイズ、保存場所、編集状態、そしてスマートフォンがダウンロードなしでオリジナルを開けるかどうかを記録してください。
Immichのある問題報告では、サポートされていない.picファイルに遭遇した際、スキップして処理を続けるのではなく、バックアップが停止していました。重要な失敗原因は、1つのサポート対象外ファイルがキューをブロックしたことです。
そのファイルを選択中のバックアップアルバムから移動するか、サポートされている形式に書き出してから、再試行します。別の場所に存在し、残りのキューが完了したことを確認するまでは、オリジナルを削除しないでください。
遅いネットワークや中断されるネットワーク状況をテストする
スマートフォンがWi-Fiとモバイル通信を切り替えていないか、アクセスポイント間を移動していないか、VPNまたはリバースプロキシへの接続が失われていないか、大きな動画のアップロード中に画面がロックされていないか確認します。小さな写真と、保留中で最も大きい動画を比較してください。
低速接続がタイムアウトした後にバックグラウンドアップロードが停止し、アプリを再起動するまで再開しないという報告があります。該当するパターンは、タイムアウトによってバックグラウンド処理が終了することです。
まずは安定したローカルWi-Fiで、サーバーのローカルアドレスを使用してテストし、その後、通常のリモートホスト名経由でテストします。ローカルではバックアップできるのにリモートでは停止する場合、プロキシのアップロード制限、アイドルタイムアウト、TLS、モバイルネットワークへの切り替えを確認してください。
クラウドのみのオリジナルファイルとスマートフォンのストレージ最適化を考慮する
ストレージを最適化する設定を使用しているスマートフォンでは、表示されているサムネイルが、端末内に保存されていないオリジナルファイルを示している場合があります。バックアップアプリは、オリジナルファイルをクラウドからダウンロードしてから、ホームサーバーへアップロードしなければなりません。
Immichのディスカッションでは、ストレージを最適化したiOSの大規模なライブラリで、重複チェックとアップロードの前に数万枚の写真をダウンロードする必要があった事例が説明されています。これにより、クラウドからのダウンロード依存が発生し、バックグラウンドスケジュールでは処理を維持できない可能性があります。
最初の移行中は、十分な空き容量を確保したうえで、スマートフォンを安定したWi-Fiに接続して充電してください。公式のクラウドエクスポートをサーバー上で直接インポートし、過去のライブラリを確認した後は、新しいファイルだけをスマートフォンからバックアップする方法も検討してください。
古いと確認できたバックアップ状態だけをリセットする
サーバーアドレスを保存し、認証情報を確認してから、サインアウトして再度サインインしてください。アップロードキューの消去やアプリデータの削除は、アプリがサポートしている復旧手順があり、かつサーバーにオリジナルファイルが検証済みの状態で保存されている場合に限って実行します。
iPhoneの写真をホームサーバーにバックアップするためのZimaSpaceガイドでは、スマートフォンやクラウドからオリジナルを削除する前に、アップロードが完了したことを確認する必要があるという基本原則を説明しています。
アプリを開いたままにしなくても新しいテスト写真がアップロードされ、中断した転送が再開され、サポートされていないファイルがキューをブロックせず、充電中、Wi-Fiの切り替え、スマートフォンの再起動、アプリの更新後もバックグラウンドの進行が安定していれば、問題は解決しています。
サポートとヒント
もっと読む

Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか?
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。

Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか?
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。

リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか?
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。

