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