Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの信頼性がクリーンなデプロイより低くなった場合は、Jellyfinを再構築します。ただし、開始前に永続データを保全し、検証してください。
マウントや権限のエラーなど、原因が特定でき、元に戻せる場合は修復のほうが適しています。イメージの履歴、パッケージ、場当たり的な編集、把握できていない設定のずれによって、修正するたびに別の変数が増える場合は、クリーンなランタイムの再構築が適しています。判断の境界は、どの層が失敗したのかを説明でき、残す状態を証明できるかどうかです。
既知の依存関係だけを修復する
マウントの欠落、誤ったUID、期限切れの証明書、または1つの壊れたプラグインであれば、正常なサーバー全体を再作成するより、通常はその場で修復するほうが低コストです。根本原因がすでに切り分けられている場合、再構築によって移行リスクが増します。
USEメソッドでは、ハードウェアやアーキテクチャを変更する前に、リソースまたはエラーの境界で診断することを推奨しています。
再現可能な1つの障害を修正し、元のワークフローを再テストします。データベースの状態に触れずに同じ症状が解消するなら、再構築は不要だったということです。
主な不確定要素がランタイムの変化なら再構築する
長期間稼働しているホストには、パッケージの変更、手動編集、古い環境変数、変化するタグから再作成されたコンテナが蓄積することがあります。宣言的に構成されたクリーンなランタイムのほうが、別のパッチを重ねるより監査しやすい場合があります。
サービス定義と永続ボリュームを明示すれば、クリーンな再構築を予測可能なものにできます。
現在の定義をエクスポートし、永続パスを特定して、コピーした状態一式を使ってクリーンなランタイムを作成します。ランタイムを置き換える間も、永続アプリデータの境界は変更してはいけません。
データを破壊して再構築しない
アプリケーションが壊れたからといってデータベースを削除するのは、ランタイムの再構築ではなく、状態のリセットです。破損が証明され、復旧計画がある場合を除き、ユーザー、視聴状態、メタデータ、設定を保持してください。
変更前のバックアップがあれば、ロールバックと再構築の分かれ目になることがあります。あるアップグレードからの復旧事例では、新バージョンが使用できないほど遅くなる前にバックアップを利用できたことが重要でした。
失敗した状態をバックアップし、何を破棄できるか判断する前にデータベースの整合性をテストします。置き換えたインスタンスの検証が完了するまで、元の証拠を保持してください。
クリーンな復元を受け入れテストとして使う
再構築の最も確かな証拠は、文書化されていないホスト側の調整なしに、既知の状態とメディアへ再接続できる新規インストールです。それが機能すれば、古いランタイムを安心して廃止できます。
テスト済みの復旧計画では、「ファイルをコピーした」だけで終わらせず、復元後にサービスが実際に利用できることを確認します。
ユーザー、ライブラリ数、視聴履歴、1つのダイレクトプレイ、1つのトランスコード、スケジュールされたタスク、再起動を検証します。再構築で必要だった手動手順はすべて記録してください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinはバックグラウンドジョブ用にどのくらいの空き容量を確保すべきですか？
Jellyfinに適した一律の空き容量率はありません。永続的な増加と一時的なピークを別々に測定し、その両方を上回る余裕を確保してください。
