アップグレード中にJellyfinの設定が失われるのを防ぐ方法
アプリケーションの状態と交換可能なランタイムを2つの独立した復旧対象として扱うことで、アップグレード中のJellyfin設定の消失を防げます。
パッケージレベルではアップグレードに成功していても、マウントの変更、ユーザーID、デバイスマッピング、または移行によって、Jellyfinが初期状態のように見えることがあります。予防策は抽象的に「バックアップを取る」ことではありません。状態が正確にどこに保存されているかを把握し、一貫した方法で取得し、実行中の定義を記録し、復元できることを証明することです。
アップグレード前に実際の永続パスを把握する
コンテナ内に表示されるパスが、バックアップ対象のホストパスだと決めつけないでください。データベース、設定、メタデータ、プラグインの状態が実際に保存されているバインドマウントまたは名前付きボリュームを確認します。
ボリューム定義とサービス境界がデプロイ設定で明示されていれば、コンテナストレージは移植性を維持できます。
永続マウントごとに、ホストパス、コンテナパス、所有者、ファイルシステムを書き留めます。状態の保存場所を確実に特定できない場合は、アップグレードを延期してください。
変更前に一貫性のあるコピーを取得する
最も役立つ復旧ポイントは、新しいバージョンがデータベースを変更する前に取得したものです。書き込み中に取得したファイルコピーは、サービスを停止して取得したバックアップや、一貫性のあるスナップショットよりも信頼性が低くなる場合があります。
Jellyfin設定の個別バックアップを作成すれば、再作成が難しい状態を保持しながら、大容量のメディアは独自の保護経路で管理できます。
バックアップを作成してライブ設定デバイスの外部に保存し、タイムスタンプとバージョンを記録します。永続的なアプリデータのレイアウトを採用すれば、イメージ自体をコピーせずに状態をバックアップできます。
データと同じようにランタイム定義も慎重に記録する
データベースのバックアップが完全でも、再作成するコンテナ定義に設定がなければ、ハードウェアアクセラレーション、ポート、DNS、デバイス、権限は復元できません。Composeまたはプラットフォーム設定を復旧セットの一部として扱ってください。
安定したサービスIDでコンテナを実行するには、アップグレードやホストファイルシステムをまたいだ予測可能なUIDとGIDのマッピングが必要です。
有効なデプロイ定義を、シークレットを除いた状態でエクスポートまたはコミットします。ロールバックが記憶に頼らずに済むよう、イメージダイジェストとデバイスマッピングを記録してください。
古いバージョンを削除する前に復旧経路をテストする
クリーンアップは、新しいバージョンが再起動を乗り切り、バックアップを見つけて開けることを確認してから行います。ロールバックを一度もリハーサルしていない場合、古いイメージやスナップショットを削除すると、最も低コストな復旧手段が失われます。
テスト済みの復元経路があれば、バックアップは想定上の復旧手段ではなく、実際に使用可能なアプリケーション状態を再構築できるものになります。
ユーザー、ライブラリ、メタデータ、1回の再生、1回の再起動を検証します。新しいバージョンで想定された移行と通常のバックグラウンド処理が完了するまで、アップグレード前の復旧セットを保持してください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
