コンテナの更新に失敗した後にJellyfinを復元する方法
コンテナの更新に失敗した後は、ランタイムを置き換えたり、ロールバックしたり、再作成したりする前に、永続的な状態を保護してJellyfinを復旧します。
更新の失敗は、イメージの問題、環境変数の変更、デバイスマッピングの喪失、ボリューム設定のミス、アプリケーションの移行問題などが原因で発生します。失敗した状態を保存し、どのレイヤーが変更されたのかを特定してください。ランタイムに問題があるのか、データ自体に問題があるのかが分かるまでは、設定ディレクトリに手を加えないことが最も安全です。
別のイメージを取得する前に失敗した状態を固定する
自動更新と再起動ループを無効にして、試行するたびにログ、イメージタグ、アプリケーションの状態が変わらないようにします。実際に適用されているコンテナ定義と、最初に発生した致命的なエラーを保存してください。
変更前のJellyfinバックアップがすでにあれば、失敗したアップグレードを簡単に元に戻せます。バックアップがない場合、ランタイムの障害が状態復旧の問題に発展する可能性があります。
イメージダイジェスト、マウント、デバイス、環境変数、ネットワークモード、最近のログを記録します。復旧対象の特定が完了するまでは、クリーンアップやプルーンのコマンドを実行しないでください。
何かを再作成する前に設定とデータベースを保護する
交換可能なイメージは、永続的なJellyfinのデータベース、設定、メタデータ、プラグインから分離してください。古いバイナリや新しいバイナリで再びその状態を開く前に、読み取り専用のコピーまたはスナップショットを作成します。
Jellyfinの設定バックアップにより、メディアライブラリ本体とは別に、ユーザーアカウント、ライブラリ設定、視聴履歴、メタデータを保護できます。
永続パスを別の場所にコピーし、所有者情報を保持します。コンテナの永続化境界が正しいのは、クリーンなランタイムが空のサーバーを作成せずに再接続できる場合だけです。
失敗した最小レイヤーを復元する
同じ状態とマウントで古いイメージが動作するなら、問題はライブラリではなく更新経路にあります。両方のバージョンで失敗する場合は、イメージの切り替えを繰り返さず、データや権限を個別に調査してください。
バージョン固有のJellyfin起動失敗は、一般的なストレージやネットワークの変更とは切り分ける必要があります。
コピーした状態一式に対して、ロールバックまたは正常動作が確認されたイメージを1つだけテストします。データベースの唯一のコピーに対して、移行を何度も強制しないでください。
自動化を再開する前に、識別情報、ライブラリ、1件の再生を確認する
コンテナが「実行中」になっただけでは、完全に復元されたとはいえません。想定したユーザー、ライブラリ、視聴状態、パス、再生動作が戻っていることを確認してください。スキャンや連携する自動化機能によって新たな書き込みが発生する可能性があるため、検証中は一時停止しておきます。
適切な復元テストでは、ファイルの抽出に成功したことだけを根拠にせず、復旧後のアプリケーションの動作を検証します。
サーバーの識別情報、1つのライブラリの参照、1回のダイレクト再生、使用している場合は1回のトランスコード、そして1回の再起動を確認します。その後で初めて、スケジュール済みスキャンと自動更新を再び有効にしてください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
