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